"Perry E. Metzger" <perry@piermont.com> writes:

> A lot of the time, I use the same arguments to build.sh to set
> defaults over and over again -- things that I do not want in my
> /etc/mk.conf file or which cannot be set in an mk.conf file.
> 
> I am thinking of adding an /etc/build.conf file to the system that
> would get slurped in by build.sh if it existed -- this file could
> export a bunch of variables to control build.sh behavior. (The change
> is two lines.)

I hate global configuration files for tools. They're a hidden
dependancy on system state, and they tend to bite me when
another user uses the system or I want to do a "plain" build.

The build.sh program has no particular connection to the machine it's
running on; consider a source tree on a shared filesystem in a
development lab, for example.

Please don't do this. Write your own wrapper script and keep it
somewhere convenient for you. If you're feeling especially ambitious,
maybe make build.sh take an option to read a config file somewhere,
and then your wrapper script or alias can be very short.

I realize that there is prior art, in the form of /etc/mk.conf, but I
consider /etc/mk.conf to be 100% a bug, not a feature.

        - Nathan