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- {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. Regards,... -jmpp
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?
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. Paul
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.
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
Citando Ryan Schmidt :
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.
Isn't it simpler in this case to use reinplace in the Portfile to update the LDFLAGS and CFLAGS lines in the Makefile? It more or less means uncommenting the FreeBSD stuff and replacing usr by opt and adding the -DSTUFF. And it is what the normal user would do to compile this manually. As there already are reinplace in whois' Portfile (that set prefix and tell to install in destroot), that seems the simpler solution. Am I wrong on that? Emmanuel
participants (4)
-
Emmanuel Hainry
-
Juan Manuel Palacios
-
Paul Guyot
-
Ryan Schmidt