svn commit: r39468 - head/en_US.ISO8859-1/books/handbook/ports

Benjamin Kaduk kaduk at MIT.EDU
Wed Aug 29 17:40:00 UTC 2012


On Wed, 29 Aug 2012, Glen Barber wrote:

>>> +
>>> +	  <para>When installing a port, using only <command>make
>>> +	      <maketarget>install</maketarget></command> from the
>>> +	    beginning means there will potentially be many waiting
>>> +	    periods between user interaction as the default behaviour
>>> +	    is to prompt the user for options.  When there are many
>>> +	    dependencies, this sometimes makes building a single port
>>> +	    a huge hassle.  To avoid this, first run <command>make
>>> +	      <maketarget>config-recursive</maketarget></command> to
>>> +	    do the configuration in one batch.  Then run
>>
>> Is this actually true these days?  I seem to recall that (at least
>> pre-optionsng), if you changed port options so as to add new dependencies,
>> the new dependencies were not included in the config-recursive step,
>> requiring that 'make config-recursive' was run in a loop until it had
>> nothing more to configure.
>>
>
> Unfortunately, this is still true.
>
> Another edge-case is if a dependency were removed by an option selection
> (i.e., removing the WITH_APACHE option in lang/php5), the dependent port
> will continue to prompt for options even though it is no longer needed.

Well, the failure mode for asking about more options than are needed seems 
less bad than having to make another pass of config-recursive.
I think my point was that we should probably document that if options are 
(de)selected, config-recursive should be run again, until the software is 
fixed.

>
> I've actually been looking into the ugly bits on how this can be
> avoided.  I think it would be highly useful for users in cases like
> this, and those using Ports Tinderbox for package building.  But, it
> seems to be non-trivial...

Off the top of my head, it does seem a bit challenging, yes.  Thanks for 
looking into it -- $(WORK) is soaking up a lot of time for me, of late.

-Ben


More information about the svn-doc-all mailing list