cmake and gobject_introspection portgroups together cause invalid CC archflags

[drkp (Dan Ports)]

As part of updating poppler (see #54808 and ​https://github.com/macports/macports-ports/pull/1975), I've noticed that g-ir-scanner is trying to invoke clang with invalid archflags because CC is being set in build.args to an invalid argument:

:info:build Command failed:  cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_github.com_macports-ports_graphics_poppler/poppler/work/poppler-0.65.0" && /usr/bin/make -j8 -w all CC="/usr/bin/clang {-arch x86_64}" VERBOSE=ON

I _think_ this is being caused by an interaction between the cmake-1.1 and gobject_introspection-1.0 portgroups, since gobject_introspection-1.0 adds the requisite archflags to build.args for g-ir-scanner's use, and the cmake portgroup is doing some manipulation of the archflags that I don't really understand.

Note that this isn't a problem for universal builds, except when muniversal is used, since gobject_introspection-1.0 doesn't set CC for those.

I've cc'd some of the people involved with the gobject_introspection and cmake portgroups since I'm not sure which one the problem is with.

[RJVB (René Bertin)]

I don't understand anything of the whole gobject introspection thing myself. However, I'm tempted to say that the culprit here is whoever set CC to something containing the arch flag and fails to avoid adding curly braces while doing that.

This is a bit of a tricky business; I've never yet figured out how to set variables such that you don't get those braces when you expand them.

[RJVB (René Bertin)]

You could try a few things in gobject_introspection-1.0.tcl, starting with just port build poppler

Replace

build.args-append       CC="${configure.cc} ${configure.cc_archflags}"

with

build.args-append       CC="${configure.cc} [join ${configure.cc_archflags}]"

or even

build.args-append       CC="[join [concat [option configure.cc] [option configure.cc_archflags]]"

If the build step succeeds with either, make the equivalent change to the destroot.args-append line in the PortGroup and try to finalise the install.

Both approaches are used in the CMake 1.1 PG to avoid getting curly braces in the intended result; I cannot remember why I had (or decided) to use the more complex second one.

[drkp (Dan Ports)]

In f4a310c857d83ab9477111f15cbb018ca07d5962/macports-ports (master):

gobject_introspection portgroup: fix for cmake compatibility

This lets the portgroup handle braces in configure.cc_archflags, which
seem to be introduced by the cmake portgroup. Probably the real
problem is that the braces are being added in the first place, but
this is a reasonable stopgap measure.

See #56637

[drkp (Dan Ports)]

I added a join in the gobject_introspection portgroup to handle the braces, but it sounds like the real problem is that the braces are showing up in the first place, and I'm not sure why that's happening.

[jmroot (Joshua Root)]

In 2b01c294374b9582abeaeb048aa3415c82ba1988/macports-ports (master):

cmake portgroups: avoid overquoting archflags

Fixes: #56637

[RJVB (René Bertin)]

Replying to drkp:

sounds like the real problem is that the braces are showing up in the first place, and I'm not sure why that's happening.

Yes, as I said above

I've never yet figured out how to set variables such that you don't get those braces when you expand them

but I think it's probably a side-effect of how Tcl handles strings vs. lists and how MacPorts uses those, attempting to use them interchangeably, hiding the differences etc. The existence of a dedicated term (overquoting) would tend to support that hypothesis, I'd say :)

EDIT: the braces aren't introduced by the CMake PG, not directly at least. It introduces an extra level of indirection or a type change (probably unavoidably). Direct introduction of those braces would have led to immediate issues elsewhere, which is also why the CMake PG itself makes liberal use of the join command.

[jmroot (Joshua Root)]

If you append a list to a list as a single element then it gets extra quoting. So yes, the cmake portgroup did introduce the braces.

[RJVB (René Bertin)]

Except that's not what the PG does (I think). Instead it does

    set cmake._archflag_vars {cc_archflags cxx_archflags ld_archflags objc_archflags objcxx_archflags \
        universal_cflags universal_cxxflags universal_ldflags universal_objcflags universal_objcxxflags}
# ...
    post-configure {
        # Although cmake wants us not to set -arch flags ourselves when we run cmake,
        # ports might have need to access these variables at other times.
        foreach archflag_var ${cmake._archflag_vars} {
            global cmake._saved_${archflag_var}
            configure.${archflag_var} [set cmake._saved_${archflag_var}]
        }

after saving the flags in the pre-configure with

        foreach archflag_var ${cmake._archflag_vars} {
            global cmake._saved_${archflag_var}
            set cmake._saved_${archflag_var} [option configure.${archflag_var}]
        }

I think I didn't write the saving part is, only the restore. Is there another way either could be done which avoids the overquoting?

[jmroot (Joshua Root)]

Yes, I just did it in the commit referenced above. When you set an option, each argument becomes a list element. Passing a list as one argument thus adds more quoting. Splitting the list into separate args with {*} avoids it.

[RJVB (René Bertin)]

I'd have sworn that the 1st time I looked the fix was using 'join' in the introspection PG...

Yay for code obfuscation ... is this safe for options that are not lists?