On Fri, Mar 05, 2010 at 02:06:01PM -0500, RD Thrush wrote: > I'm surprised by the behavior of conditionals involving variables set in > /etc/mk.conf. For example, the audio/jack Makefile has these lines: > .ifdef DEBUG > CONFIGURE_ARGS += --enable-debug > .endif > > With DEBUG=-g in /etc/mk.conf, CONFIGURE_ARGS does *not* have the > "--enable-debug" string. > > Here's a short transcript that illustrates the problem: > x2: 8010>grep ^DEBUG /etc/mk.conf > DEBUG=-g > x2: 8011>(cd /usr/ports/audio/jack/ && make dump-vars)|grep CONFIGURE_ARGS > audio/jack.CONFIGURE_ARGS=--enable-shared --with-default-tmpdir=/var/tmp > --disable-portaudio --disable-optimize --prefix='/usr/local' > --sysconfdir='/etc' --mandir='/usr/local/man' --infodir='/usr/local/info' > x2: 8012>(cd /usr/ports/audio/jack/ && make DEBUG=-g dump-vars)|grep > CONFIGURE_ARGS > audio/jack.CONFIGURE_ARGS=--enable-shared --with-default-tmpdir=/var/tmp > --disable-portaudio --disable-optimize --enable-debug --prefix='/usr/local' > --sysconfdir='/etc' --mandir='/usr/local/man' --infodir='/usr/local/info' > > I'm probably misunderstanding some make nuances here... I did find that > putting > the above lines after the ".include <bsd.port.mk>" line did make it work the > way > I expected. Is there another/better way to evaluate mk.conf variables?
> FWIW, the following ports seem to use something similar: > audio/jack/Makefile > graphics/ffmpeg/Makefile > mail/mutt/Makefile.inc > net/pidgin/Makefile > net/pmacct/Makefile > print/ghostscript/gnu/Makefile > print/libspectre/Makefile > sysutils/gamin/Makefile > www/cherokee/Makefile > x11/gnome/scan/Makefile > x11/pinot/Makefile Nothing surprising here. mk.conf is part of the framework, it's read during bsd.port.mk parsing, not before. Doing conditional shit in ports Makefiles like this is dubious at best. This is FLAVORS stuff, since it changes the port actually built, and this is how it should be handled. There are limitations inherent to the tools being used, namely make. make must work in a certain way. BSD extensions such as conditionals have (more or less) defined semantics. A simple rule is that things are lazy when they can, and not lazy when there's no choice. You don't know how many headaches I got when revamping the ports framework. There's a logic to the madness, though. Astute readers will notice that, these days, bsd.port.mk does things in a fairly strict order: variables first, then tests, then targets. It does this not just to be "clean", but because it's the only way to obtain sane behavior. It's probably no accident that I ended up being responsible both for OpenBSD's bsd.port.mk AND make(1)...
