recursive 'make config'?

Jon Noack noackjr at alumni.rice.edu
Tue Apr 20 14:20:24 PDT 2004


On 4/20/2004 2:46 PM, Matthew Seaman wrote:
> On Tue, Apr 20, 2004 at 02:15:19PM -0500, Jon Noack wrote:
>> I love the 'make config' option. Is there a way to recursively
>> 'make config' before installing a port with a lot of dependencies
>> (similar to the way sysutils/portupgrade can recursively fetch with
>> -RF)? If I want to install kde, for example, I'd prefer to
>> configure options for each dependent port before installing. In
>> other words, I don't want to set "BATCH=yes". However, without
>> "BATCH=yes" I have to check the progress occasionally to configure
>> some port because the build process stopped. I know this is only a
>> big deal on the first install (because the options are saved), but
>> it's rather annoying to start a kde compile before you go to bed
>> and wake up with only a few ports installed...
> 
> You can't do a recursive make config like that I'm afraid.  What you
> can do is set the various configuration options used by make(1) before
> starting the compilation job, so that it doesn't stop to ask questions
> halfway through.  There's actually quite a number of ways you can do
> that:
> 
>     i) Globally in /etc/make.conf -- variables set here will apply to
>        all ports you compile.
> 
>    ii) Setting the variable in the environment before starting the
>        compilation.  Again this applies to all compilations, but only
>        certain variables can be set this way.  Many will be overridden
>        by settings in Makefiles or make.conf.
> 
>   iii) Globally in the 'Environment' section of
>        /usr/local/etc/pkgtools.conf -- of course this only works if
>        you're a portupgrade(1) user.  Same caveats as for (ii) apply
> 
>    iv) Locally to a port by creating a Makefile.local in the port
>        directory and putting the settings within that.  There are
>        actually several subsiduary makefile names that will be
>        automatically included like this: see /usr/ports/Mk/bsd.port/mk
>        for details.  Note however that 'Makefile.local' is the name
>        intended for human overrides of the default settings, whereas
>        'Makefile.inc' and '../Makefile.inc' can be machine generated
>        as part of the port's configuration, or it can be a permanent
>        file commited as part of the ports.
> 
>     v) Locally to a port (or a series of ports matching a glob
>        expression) in the MAKE_ARGS section of pkgtools.conf
> 
>    vi) Locally to a port if it uses the OPTIONS variable within it's
>        Makefile.  In these cases, just run 'make config' one time, and
>        the settings will be stored in /var/db/ports: you'll only get
>        the configuration dialog coming up if the port is modified to
>        use some new options.
> 
> Option vii) is (of course) to set the options on the make(1) command
> line, as you build the port, which I include for completeness' sake
> only as it doesn't help you run your big build job unattended.
> 
> Most people will use a combination of (i), (v) and (vi) -- for those
> ports where it applies.  You will still have to scan through all of
> the dependency ports that you will be installing, read their Makefiles
> and decide what options (if any) you wish to set.  You can get some
> lists of the dependencies by running:
> 
>     % make pretty-print-build-depends-list
>     % make pretty-print-run-depends-list 
> 
> from the directory of the top level port you wish to install.
> 
> 	Cheers,
> 
> 	Matthew

Wow -- thanks for the comprehensive response.  I'm a member of the (i) 
and (vi) club.  What I was hoping to avoid was the scan through all the 
ports.  For kde this is probably around 100 ports (no bloat jokes, 
please).  That's just too much time.  As a result, I'll continue my 
current "lazy allocation" of options.  I keep a backup of /etc/make.conf 
and the contents of /var/db/ports, which should help kick things off the 
next time I need to reinstall or install on another machine.

Thanks,
Jon



More information about the freebsd-questions mailing list