Configure & build environment flags

[Juan Manuel Palacios]

On Jun 23, 2007, at 7:48 PM, Paul Guyot wrote:

>>
>> 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.


	Right, I incorrectly extrapolated the intention of your  
configure.*flags-{append,delete} work to the overall deprecation of  
configure.env declarations, but I can certainly see many, many  
examples in which environment variables other than *FLAGS need to be  
passed.

	Now, on current usage of configure.env (given your new environment  
parser), are Portfile authors meant to use configure.env- 
{append,delete} to {add,delete} something to the default environment  
MacPorts provides out o the box (-O2 and others)? Or are plain  
configure.env declarations still OK? (that is, do they or do they not  
override what we do to the environment behind the scenes?)

> 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.


	All this I understand, but...

>
>
> 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.


	What if there's a port out there with, for example, a broken autoconf  
based build system that does not cascade its configuration flags down  
properly to the generated Makefiles? In this case, wouldn't passing  
them to the build environment help? If so and the case being rare as  
you say, do you consider a single build.env declaration in the  
relevant Portfile to be good enough to handle the case? I ask the  
question 'cause I've seen some Portfiles that pass stuff like compiler  
macros plus the standard *FLAGS in build.env and not in configure.env.

>
>
> Paul
>

	Regards,....


-jmpp