Getting the entire configure.cflags variable

Ryan Schmidt ryandesign at
Sat Oct 4 02:16:15 PDT 2014

On Oct 4, 2014, at 3:47 AM, Joshua Root wrote:
> On 2014-10-4 11:09 , Ryan Schmidt wrote:
>> On Oct 3, 2014, at 4:47 PM, Joshua Root wrote:
>>> On 2014-10-4 07:04 , Ryan Schmidt wrote:
>>>> "-arch" flags may or may not be doable. Joshua previously thought this was not fixable. 
>>> Depends what you mean by "this" and "fixable". Certainly it's impossible
>>> for any variable that can be read at any point to always reflect the
>>> existence of a variant that may not have been defined yet.
>> Right, precisely that is the difficult bit. But what about this: we already have the variable "universal_variant". Ports can set "universal_variant no" to disable the standard universal variant, or set "universal_variant yes" to have it added. We could trace that variable to change the -arch flags in the various *flags variables.
> That doesn't really buy us much, does it? The flags still wouldn't
> necessarily contain their final values before universal_variant is set.

In a portfile I can always use "if {[variant_isset universal]}" to determine if the universal variant is set. I was assuming the code I'm proposing adding to base to add the -arch flags to configure.cflags et al would do the same.

> Getting back to the original question of the thread, there would be no
> problem providing a way to see what it looks like the eventual CFLAGS
> would contain, given the information that is currently known. What we
> can't do is know how the input variables are going to change later in
> the portfile.

The original question was about being able to write:

configure.args-append CFLAGS="${configure.cflags}"

I think even today we already understand that when we reference a variable like that, we're evaluating the variable at that point, and not getting any change that might be made to the variable later.

In fact in the petsc port this is already being done in a pre-configure block so any changes to the variable later in the portfile will be observed.

More information about the macports-dev mailing list