configure.cflags and -arch flags
Ryan Schmidt
ryandesign at macports.org
Fri Jun 24 16:31:02 PDT 2011
On Jun 24, 2011, at 17:02, Joshua Root wrote:
> On 2011-6-25 07:44 , Ryan Schmidt wrote:
>> I am curious if there is a good reason why variables like configure.cflags don't contain the -arch flags. During the standard configure phase, MacPorts does put the -arch flags into e.g. the CFLAGS environment variable, but if you use e.g. configure.cflags yourself to fix ports that don't use a standard configure phase, the -arch flags are missing, and must be handled separately, both for single-arch and universal cases. This kind of conditional code is tedious, and Toby thinks this didn't used to be required:
>>
>> https://trac.macports.org/ticket/29847#comment:6
>
> You can't know whether a universal variant exists until you finish
> parsing the portfile.
But variables like configure.cflags are evaluated lazily. They're not set until they're accessed for the first time. What if, by the time configure.cflags were first accessed, the universal variant had been declared? Wouldn't that provide enough opportunity for base to add the right -arch flags?
# Make sure universal variant exists
variant universal {}
# Now use variables whose values depend on whether universal exists
post-patch {
reinplace "s|@CFLAGS@|${configure.cflags}|g" ${worksrcpath}/Makefile
}
On a related note, it would be convenient if there were a variable that could be accessed that contained all the arch flags, regardless of whether we're building universal or single-arch. That would eliminate the need for this construct currently being used in many ports:
if {[variant_isset universal]} {
set archflags ${configure.universal_cflags}
} else {
set archflags ${configure.cc_archflags}
}
Even more related, another variable would be helpful, namely a Tcl list containing all the archs being used. Currently ports have to add logic to decide whether to use build_arch or universal_archs or universal_archs_to_use and it would be nice if there were a single variable that always did the right thing.
More information about the macports-dev
mailing list