On Feb 15, 2013, at 1:06 PM, Sean Farley <[email protected]> wrote: > > Jeremy Huddleston Sequoia writes: > >> On Feb 15, 2013, at 12:18 PM, Sean Farley <[email protected]> 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
