RFC: Support for future compilers in base
Sean Farley
sean at macports.org
Fri Feb 15 13:06:40 PST 2013
Jeremy Huddleston Sequoia writes:
> On Feb 15, 2013, at 12:18 PM, Sean Farley <sean at macports.org> wrote:
>
>>
>> Rainer Müller writes:
>>
>>> On 2013-02-15 09:10, Jeremy Huddleston Sequoia wrote:
>>>> I'd like to update base trunk such that future versions of clang, dragonegg, and gcc "just work", so we don't need to wait for newer versions of base to depend on newer compilers.
>>>>
>>>> I've taken a first pass at portconfigure.tcl and here is a patch. Comments? Concerns?
>>>
>>> Fine with me.
>>>
>>> This change makes sense as the features supported by the gcc and clang
>>> compilers shipped in ports are almost homogenous at the moment; in the
>>> past there were differences as not all gcc4* shipped gfortran or gcj.
>>> However, I don't expect the situation to change in the near future.
>>
>> Clang doesn't provide fortran but all gcc ports do. How is that almost
>> homogenous?
>
> Did you actually look at the patch? It doesn't treat clang the same as it does gcc. It treats all gcc versions the same as all other gcc versions; it treats all clang versions the same as all other clang versions; and it treats all dragonegg versions the same as it treats all other dragonegg versions...
To be honest, Jeremy, the patch is a bad hack, at best. It relies on the
compiler name and does horrible regex matching. What if there's a new
compiler that comes out? For example, let's say Intel releases a free
version for the mac or maybe the Open64 compiler gets a complete port to
the mac? Those would still require an update to base.
What about making this a port group? Or maybe making this a better
system of object-oriented-ness (as much as would be allowed in Tcl)?
>> That's a huge difference when building mpi-dependent ports.
>
> Which is not really affected by this…
Sure, your patch doesn't make it worse but it also does nothing to
alleviate the burden of having a port with a fortran + mpi
requirement. This seems like a good opportunity to address these issues.
More information about the macports-dev
mailing list