On Sep 28, 2014, at 2:41 AM, Joshua Root wrote: > 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+.
You mean using the macports llvm-gcc42 port instead of the gcc49 port? Sure, we could that. It is a much smaller package. >> 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. I'm not sure I know how to do that. I have no experience with these packages' build systems or with imake, and although I can write a basic Makefile, I haven't ever written anything using autotools or cmake or similar. If the developers of those programs want to switch to those systems, that would be great, but I don't consider it my job to rewrite their configuration system for them. But I'm hopeful that I'm able to accomplish writing a xmkmf portgroup that would work. _______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
