On 2014-9-28 16:55 , Ryan Schmidt wrote: > > On Sep 27, 2014, at 11:37 PM, Joshua Root wrote: >> On 2014-9-28 12:15 , Ryan Schmidt wrote: >>> In the process I plan to create an xmkmf portgroup to replace the use_xmkmf >>> keyword in base. >> >> Why? > > It would match how we handle other build systems like xcodebuild and cmake. > It is inconsistent that MacPorts base contains special support for imake, and > especially since imake is obsolete, it makes sense to me to move it out of > base into a portgroup so it doesn't clutter up base. > > https://trac.macports.org/ticket/42547 is mostly not helpful, but does point > out that the hardcoded value of IMAKECPP set by base is a problem here > because we need to override it for Xcode 5 and there's currently no way to do > so while using "use_xmkmf yes" because base sets it directly in > configure_main. > > Moving this code to a portgroup would make it possible for us to fix this > problem and any other problems that might come up later without having to > produce a new MacPorts release. > > >>> My proposal is to have this portgroup depend on the latest stable gcc port >>> (currently gcc49) and have it use its cpp in IMAKECPP when the Xcode >>> version is 5 or greater. I tried this with one port already and was able to >>> build it on Yosemite beta. >> >> What's wrong with adding the dependency to the imake port on the >> affected platforms? > > "Affected platforms" is Xcode 5 and later, which we don't have a clean way to > model. We can check $xcodeversion, yes, but consider a case where a Mavericks > user installs the imake port while using Xcode 4, and therefore doesn't get > the gcc dependency because it's not needed, and later upgrades to Xcode 5, > and now needs the gcc dependency but won't get it unless they rebuild imake, > which they won't know to do.
So you could at least use llvm-gcc42 on 10.8 and 10.9 then, and gcc49 on 10.10+. > There's a bunch of other stuff needed to build properly with imake, even > above and beyond what's currently in base. We're missing all the things that > are usually missing when one doesn't autotools -- using the right compiler, > using arch flags, having a working universal variant, supporting the > requested cxx_stdlib. Code to support all of this can go into the new > portgroup, where it's not an inconvenience for the gcc dependency to go so > that every time the user builds a port with imake, the gcc dependency can be > added if the version of Xcode installed at that moment needs it. If I were going there, I wouldn't start here. If you want the programs to build right, put your effort into moving them off of imake. Most of them aren't very big. - Josh _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
