#39918: serf1: re-enable universal variant ---------------------------+--------------------- Reporter: ryandesign@… | Owner: blair@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.2.0 Resolution: | Keywords: Port: serf1 | ---------------------------+--------------------- Description changed by ryandesign@…: Old description:

r108691 updated serf1 to 1.3.0 and switched to its scons build system, which brought with it `use_configure no`, which removes the universal variant, thereby dooming all ports depending on serf1 to non- universality. Please reinstates the universal variant.

At minimum, you'll need to add this line before the first time you invoke the `get_canonical_archflags` proc:

{{{ variant universal {} }}}

However that alone does not appear to be sufficient. The port tries to communicate the archflags to the build system via the ARCHFLAGS environment variable, but grepping the serf source for ARCHFLAGS does not reveal any hits, so I'm not sure whether this is intended to work. (Is this a standard scons environment variable?)

My own opinion is that the scons build system is difficult to use, especially in MacPorts. That might be partially remedied by the creation of a scons portgroup to abstract away some of the implementation details.

New description: r108691 updated serf1 to 1.3.0 and switched to its scons build system, which brought with it `use_configure no`, which removes the universal variant, thereby dooming all ports depending on serf1 to non-universality. Please reinstate the universal variant. At minimum, you'll need to add this line before the first time you invoke the `get_canonical_archflags` proc: {{{ variant universal {} }}} However that alone does not appear to be sufficient. The port tries to communicate the archflags to the build system via the ARCHFLAGS environment variable, but grepping the serf source for ARCHFLAGS does not reveal any hits, so I'm not sure whether this is intended to work. (Is this a standard scons environment variable?) My own opinion is that the scons build system is difficult to use, especially in MacPorts. That might be partially remedied by the creation of a scons portgroup to abstract away some of the implementation details. -- -- Ticket URL: <https://trac.macports.org/ticket/39918#comment:1> MacPorts <http://www.macports.org/> Ports system for OS X

#39918: serf1: re-enable universal variant ---------------------------+--------------------- Reporter: ryandesign@… | Owner: blair@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.2.0 Resolution: | Keywords: Port: serf1 | ---------------------------+--------------------- Comment (by ryandesign@…): Yes, my primary system defaults to universal builds. But it's trivial for you to try it out too; just run "sudo port install serf1 +universal" and MacPorts will universalize dependencies as necessary. -- Ticket URL: <https://trac.macports.org/ticket/39918#comment:3> MacPorts <http://www.macports.org/> Ports system for OS X

#39918: serf1: re-enable universal variant ---------------------------+--------------------- Reporter: ryandesign@… | Owner: blair@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.2.0 Resolution: | Keywords: Port: serf1 | ---------------------------+--------------------- Comment (by egall@…): Fink actually also had some issues with serf1 and scons ignoring arch flags... let me see if I can find how they solved it again... -- Ticket URL: <https://trac.macports.org/ticket/39918#comment:6> MacPorts <http://www.macports.org/> Ports system for OS X

#39918: serf1: re-enable universal variant ---------------------------+--------------------- Reporter: ryandesign@… | Owner: blair@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.2.0 Resolution: | Keywords: Port: serf1 | ---------------------------+--------------------- Comment (by leo@…): Portfile probably contains a few errors: - ARCHFLAGS not required to build serf; - CFLAGS is not defined properly; - Assembly serf requires LINKFLAGS; - serf SConstruct can use environment variables, it requires command-line arguments; For add build variant universal should fix the Portfile: {{{ variant universal { build.args CC=${configure.cc} \ CFLAGS=[string map {" " ","} "${configure.universal_cflags}"] \ CPPFLAGS=[string map {" " ","} "${configure.universal_cppflags}"] \ LINKFLAGS=[string map {" " ","} "${configure.universal_ldflags}"] } build.cmd ${prefix}/bin/scons build.args CC=${configure.cc} \ CFLAGS=[string map {" " ","} "${configure.cflags}"] \ CPPFLAGS=[string map {" " ","} "${configure.cppflags}"] \ LINKFLAGS=[string map {" " ","} "${configure.ldflags}"] }}} -- Sorry for my best English -- Ticket URL: <https://trac.macports.org/ticket/39918#comment:10> MacPorts <http://www.macports.org/> Ports system for OS X

#39918: serf1: re-enable universal variant ---------------------------+--------------------- Reporter: ryandesign@… | Owner: blair@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.2.0 Resolution: | Keywords: Port: serf1 | ---------------------------+--------------------- Comment (by leo@…): Replying to [comment:11 ryandesign@…]:

That's assuming it's correct to concatenate these flags with commas instead of spaces. I've never seen that before and it seems weird to me. But we've already established that scons is needlessly weird.

Not scons, but serf-1.3.0/SConstruct :) See function RawListVariable() at serf-1.3.0/SConstruct:40 -- Ticket URL: <https://trac.macports.org/ticket/39918#comment:12> MacPorts <http://www.macports.org/> Ports system for OS X

#39918: serf1: re-enable universal variant ---------------------------+--------------------- Reporter: ryandesign@… | Owner: blair@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.2.0 Resolution: | Keywords: Port: serf1 | ---------------------------+--------------------- Comment (by blair@…): So is the following correct, incorporating all the feedback? {{{ variant universal {} build.cmd ${prefix}/bin/scons build.args CC=${configure.cc} \ CPPFLAGS=[join "${configure.cppflags}" ,] \ CFLAGS=[join "${configure.cflags},[get_canonical_archflags cc]" ,] \ LINKFLAGS=[join "${configure.ldflags},[get_canonical_archflags ld]" ,] }}} Ryan, feel free to commit any changes you want. -- Ticket URL: <https://trac.macports.org/ticket/39918#comment:14> MacPorts <http://www.macports.org/> Ports system for OS X

#39918: serf1: re-enable universal variant ---------------------------+--------------------- Reporter: ryandesign@… | Owner: blair@… Type: defect | Status: closed Priority: Normal | Milestone: Component: ports | Version: 2.2.0 Resolution: fixed | Keywords: Port: serf1 | ---------------------------+--------------------- Changes (by ryandesign@…): * status: new => closed * resolution: => fixed Comment: It appears to work. Committed in r108804. No, other ports should not need any changes. -- Ticket URL: <https://trac.macports.org/ticket/39918#comment:17> MacPorts <http://www.macports.org/> Ports system for OS X

#39918: serf1: re-enable universal variant ---------------------------+--------------------- Reporter: ryandesign@… | Owner: blair@… Type: defect | Status: closed Priority: Normal | Milestone: Component: ports | Version: 2.2.0 Resolution: fixed | Keywords: Port: serf1 | ---------------------------+--------------------- Comment (by ryandesign@…): Replying to [comment:18 blair@…]:

So the pre-fixed version would, say, only have x86_64 bits

Right, whatever was specified for build_arch in the user's macports.conf.

while the universal build would have x86_64 and i386?

Right, whatever was specified for universal_archs in the user's macports.conf.

But how could Subversion link the i386 version against libserf-1.dylib when it only contains x86_64? Or it only cares about the symbols and the symbols are there for both arches?

It could not. MacPorts knows this and checks that the architectures match before allowing a build. If a user had tried to install or upgrade subversion +universal, MacPorts would have exited with an error explaining that it could not be done because dependency serf1 did not have a universal variant. And now it does so now it should work again. -- Ticket URL: <https://trac.macports.org/ticket/39918#comment:19> MacPorts <http://www.macports.org/> Ports system for OS X