Configure & build environment flags

[Ryan Schmidt]

On Jun 23, 2007, at 18:48, Paul Guyot wrote:

> On Jun 24, 2007, at 7:00 AM, Ryan Schmidt wrote:
>
>> On Jun 23, 2007, at 16:27, Juan Manuel Palacios wrote:
>>
>>> 	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- 
>>> {append,delete}?
>>>
>>> 	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.
>>
>> I also recently noticed the lack of build.cppflags-append and  
>> asked the list about it and got no response.
>>
>> http://lists.macosforge.org/pipermail/macports-dev/2007-May/ 
>> 001774.html
>>
>> I wasn't aware configure.env was deprecated. It's still used and  
>> required by many ports. I thought we just deprecated using  
>> configure.env for setting LDFLAGS and CPPFLAGS. Is that all you  
>> meant?
>
> I don't think we deprecated configure.env and that there is any  
> plan to do so. There is some code in base/ that parses flags in  
> configure.env, and this is the bit that might go away, maybe with a  
> warning, once a grep would have revealed that no port still uses  
> configure.env for *FLAGS.
>
> The rationale behind configure.*flags was that it was the easiest  
> solution to solve several problems at once and to provide features  
> we wanted. Setting those flags is quite a frequent operation and  
> parsing them from configure.env is error-prone and problematic, for  
> example it is difficult to figure out the declarative value of each  
> flag, if the flag was inherited, was there because of a variant or  
> was there in the base portfile. Now that we process flags  
> separately, we provide options that are more declarative and we can  
> handle a reasonable default for universal builds while providing a  
> way to implement a specific variant for that, we provide a  
> reasonable default for the flags including the over-spread -I$ 
> {prefix}/include and -L${prefix}/lib, thus simplifying and having  
> portfiles using those flags properly (most of the flags were set in  
> an effectless manner), and we also now compile stuff with a  
> default, reasonable optimization flag (-O2, I know many people here  
> would prefer -Os, or believe Apple says so), while the past  
> behavior was such that many software built with MacPorts were not  
> optimized while they would have been optimized if built manually --  
> because if you don't provide any CFLAG to autoconf' generated  
> configure, it uses the default value including -O2 when using gcc.
>
> I don't see any similar rationale for build flags. I believe build  
> flags being really required is quite rare, and that we would break  
> ports if we provided a default for build flags. We do not *need*  
> all the logic that exists for configure flags. Providing that as  
> part of a complete framework that would unify the syntax might make  
> the work of port maintainers easier, but this will certainly add  
> some confusion (should this flag be in configure or in build  
> flags?) and drive them to use build flags where they are in fact  
> not required, or where they would conflict with configure flags.

I don't know about all that. All I know is that the whois port needs  
it. The whois port does not use configure. And in order to find the  
gettext headers and libraries, the portfile says:

build.env \
         CFLAGS="-DENABLE_NLS -I${prefix}/include" \
         LDFLAGS="-L${prefix}/lib -lintl"

I had changed this at one point (r25698) to:

build.cflags-append -DENABLE_NLS
build.ldflags-append -lintl

because I assumed that would work. It didn't. So, the rationale for  
having build.*flags-(append|delete) is that it is consistent with  
configure.*flags-(append|delete) and thus makes life easier on port  
authors.

As to all you've written about flag inheritance and other related  
issues, I don't know about any of that. Though in the case of whois,  
at least, since there is no configure stage, I think it's irrelevant.