Trunk breaks ports using llvm-gcc without automatically adding a dependency on macports-llvm-gcc

[mf2k (Frank Schima)]

I was running my normal updates and mysql5 5.1.68 fails due to the following configure error:

:info:configure checking for C compiler default output file name... 
:info:configure configure: error: in `/opt/local/var/macports/build/_opt_mports_trunk_dports_databases_mysql5/mysql5/work/mysql-5.1.68':
:info:configure configure: error: C compiler cannot create executables
:info:configure See `config.log' for more details.

I can assure you that I have Xcode 4.6 installed correctly with the latest command line tools. Because everything else works fine. I have had mysql5 installed the whole time and never had a problem until this version.

[ryandesign (Ryan Carsten Schmidt)]

r102800

[ryandesign (Ryan Carsten Schmidt)]

It should only happen if you're running trunk. See ​https://lists.macosforge.org/pipermail/macports-dev/2013-January/021855.html

[neverpanic (Clemens Lang)]

I really think instead of starting to add a block like this into ports, we should revert the change causing this until we have proper automatic dependencies on llvm-gcc42 implemented in base.

[ryandesign (Ryan Carsten Schmidt)]

For reference, the ticket about automatic compiler dependencies is #32542.

[mf2k (Frank Schima)]

I am indeed running trunk. Sorry for not setting the version correctly.

[mf2k (Frank Schima)]

Nitpick: ports are space separated, not comma separated.

[jeremyhu (Jeremy Huddleston Sequoia)]

Anyone using trunk is capable of installing llvm-gcc42 on their own.

Duplicate of #32542

[neverpanic (Clemens Lang)]

Not anyone on trunk knows llvm-gcc42 needs to be installed. This ticket is the best advocate for that.

I'm planning to revert your change if you don't do it and nobody fixes the automatic dependencies. It's a hassle for me and apparently also other MacPorts developers.

[ryandesign (Ryan Carsten Schmidt)]

Don't revert it; if anything, just change it to match Xcode 4.7 and newer instead of 4.6 and newer.

[jeremyhu (Jeremy Huddleston Sequoia)]

Leaving it as 4.6 allows developers to see what will happen when the next version of XCode is released, so developers have time to react. Changing it to 4.7 will just result in developers being complacent and having a fit when the next XCode version comes out and *users* start complaining.

If you want to be coddled and don't want to actually fix bugs, you can use the 2.1 branch. If you want to actually find and fix bugs before they impact our users, use trunk.

[neverpanic (Clemens Lang)]

Replying to jeremyhu@…:

Leaving it as 4.6 allows developers to see what will happen when the next version of XCode is released, so developers have time to react.

TBH, we haven't cared about future Xcode updates previously, I don't see why we're handling this one different. Go ahead and implement a deprecation warning along with suggestions on how to make the port future proof, if you want, but breaking stuff completely is not a good way to handle this, IMO.

At the moment all we have is breakage of otherwise well-working ports and no clear strategy on how to fix the breakage (other than in trunk, where it was not fixed so far). Are you suggesting we should add the hack ryan commited above to all affected ports? That doesn't sound like a good solution to me.

If you want to be coddled and don't want to actually fix bugs, you can use the 2.1 branch. If you want to actually find and fix bugs before they impact our users, use trunk.

It might have escaped your attention, but I am actually doing development work of MacPorts base on trunk and I am actually fixing bugs. See the Changelog. Pointing people to bugs without having a proper way to solve them sounds useless to me, though. It's annoying.

[jeremyhu (Jeremy Huddleston Sequoia)]

Replying to cal@…:

Replying to jeremyhu@…:

Leaving it as 4.6 allows developers to see what will happen when the next version of XCode is released, so developers have time to react.

TBH, we haven't cared about future Xcode updates previously, I don't see why we're handling this one different.

Maybe you haven't, but I certainly started making sure projects built with clang well before we moved to it being default. This has been a long time coming.

Go ahead and implement a deprecation warning along with suggestions on how to make the port future proof, if you want, but breaking stuff completely is not a good way to handle this, IMO.

I'm not sure what you mean by that. llvm-gcc is going away as a fallback option in the next XCode release whether we are ready for it or not.

At the moment all we have is breakage of otherwise well-working ports and no clear strategy on how to fix the breakage (other than in trunk, where it was not fixed so far). Are you suggesting we should add the hack ryan commited above to all affected ports? That doesn't sound like a good solution to me.

No, I don't want to add that block to all the ports. base needs to have #32542 fixed before the next version of XCode is released. In the mean time, you can manually 'sudo port -v install llvm-gcc42'

If you want to be coddled and don't want to actually fix bugs, you can use the 2.1 branch. If you want to actually find and fix bugs before they impact our users, use trunk.

It might have escaped your attention, but I am actually doing development work of MacPorts base on trunk and I am actually fixing bugs. See the Changelog. Pointing people to bugs without having a proper way to solve them sounds useless to me, though. It's annoying.

I'm not saying you need to be coddled. You obviously noticed that it was a missing dependency. I'm saying that in general if a developer just wants to work on a small set of ports and not find/fix larger issues, they should use the release branch. If you use trunk, you are essentially opting in to finding issues like this and being ok implementing simple workarounds 'sudo port -v install llvm-gcc42' until the underlying issue is fixed.

[neverpanic (Clemens Lang)]

Since trunk now automatically adds the required dependencies and #32542 is fixed, the blocks commited to mysql5{,1} have been removed and this can be closed.