Configure & build environment flags

Juan Manuel Palacios jmpp at
Sat Jun 23 14:27:45 PDT 2007

	Hello Paul!

	I'm curious about why we provide facilities to alter the configure  
environment in many ways but practically none to alter the build  
environment. I know that in the ideal case (a properly written build  
system for any given software package) the configure environment  
should either cascade down to the build one (Makefiles inheriting and  
passing the same env flags that were given during the configure stage,  
for instance) or its results should be reflected there (the setting of  
some variable in generated Makefiles), but we all know there are quite  
a handful of broken build systems in which neither of these two is  
true. Therefore some Portfiles have the need of passing some (if not  
the same) flags to the environment during build (build.env) as they do  
in the configure stage.

	So, onto my specific questions, is there any reason why we don't  
provide the build.xxflags-{append,delete} equivalents that we do for  
configure.xxflags-{append,delete}? How these would work (inheriting  
values, replicating them, overriding them,...) I'm not entirely sure,  
but you can easily spot Portfiles out there using build.env construct  
that may tread on what's set through the configure.xxflags if not used  
carefully. Also, if we're deprecating configure.env, shouldn't we be  
doing the same for build.env? And lastly, again on the deprecation of  
configure.env, what's our stand with respect to {configure,build}.env- 

	I would completely understand if you told me none of these things  
have been implemented yet 'cause simply you've had "no time" ;-) But I  
was wondering if there were intead any type of technical decisions  
behind the lack of a build environment tweaking facility.



More information about the macports-dev mailing list