imake

[Ryan Schmidt]

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.