RFC: Support for future compilers in base

[Ryan Schmidt]

On Feb 15, 2013, at 02: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.

That's a great idea! Thanks.


> I've taken a first pass at portconfigure.tcl and here is a patch.  Comments?  Concerns?

I have not tried it but I read it and it looks good to me. I say commit it, with the change Rainer pointed out:


On Feb 15, 2013, at 03:58, Rainer Müller wrote:

> One minor stylistic comment, when using regexp and you don't care about
> the whole match, it's convention in the Tcl community to use -> as
> variable name:
> 
> regexp {macports-clang-(.*)\.(.*)} ${configure.compiler} -> major minor

+1


I also get the distinct feeling these could be simplified:

> +    if {[string first "macports-gcc" $compiler] == 0 ||
> +        [string first "dragonegg-" $compiler] == 0} {
> +        return no
> +    } else {
> +        return yes
>      }

Can't this be:

    return [string first "macports-gcc" $compiler] == 0 ||
        [string first "dragonegg-" $compiler] == 0


> +proc portconfigure::compiler_is_port {compiler} {
> +    if {[portconfigure::compiler_port_name ${compiler}] == ""} {
> +        return no
> +    } else {
> +        return yes
> +    }
> +}

Can't this be:

proc portconfigure::compiler_is_port {compiler} {
    return [portconfigure::compiler_port_name ${compiler}] == ""
}

I haven't actually tested this code but I'm sure a language like Tcl must support such a construct. But if you want to commit it as you sent it (but with Rainer's change) we can always refine it later.


On Feb 15, 2013, at 15:06, Sean Farley wrote:

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

The patch is good; it both simplifies and future-proofs what we have in base now. Obviously we cannot predict what new compilers might be released in the future, and we'll have to handle those then, if we want to make those compilers easily accessible to ports then. Of course nothing prevents ports from manually setting configure.cc et al to any compiler they choose.


> What about making this a port group?

-1, it's an improvement of / refinement of what's already in base, and it should stay in base.


> Or maybe making this a better
> system of object-oriented-ness (as much as would be allowed in Tcl)?

-1, AFAIK we don't use object-oriented Tcl much (at all?) in base today; no need to introduce yet more complexity.


On Feb 15, 2013, at 15:29, Jeremy Huddleston Sequoia wrote:

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

Sorry. :) I kind of like Tcl in a weird way. Feel free to send me your Tcl questions or frustrations.