RFC: Support for future compilers in base

[Jeremy Huddleston Sequoia]

On Feb 15, 2013, at 1:06 PM, Sean Farley <sean at macports.org> wrote:

> 
> 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.

Yes, and how is that any worse than what is being done already?

> 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.

Yes is would.  This patch is not designed to address *THAT* issue.  It is designed to address gcc49, gcc410, gcc50, dragonegg-3.[456], clang-3.[456], etc.  That's all I care about addressing for now.  If you have an idea for making this even better in the future, be my guest =)

> 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)?

I hate tcl, and it hates me.  If you want to do something like that, please do so, but I'm very limited in what *I* can do based on how much time I (don't) want to devote to tcl.  I'm just trying to make the situation incrementally better than it is now, so I don't need to remember to cherry pick "support clang-3.4" into the base 2.2 branch like we did 3.2 and 3.3 into the base 2.1 branch.

>>> 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.


Be my guest.  I don't use fortran, so so I don't really know about that particular issue.  Do you have a ticket filed?  Problems don't get fixed unless someone cares about fixing the problem ;)

--Jeremy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4145 bytes
Desc: not available
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20130215/2eb5420f/attachment.p7s>