[gentoo-dev] Re: [[e-mail]: Re: [gentoo-core] new USE flag proposal: ccc]

[Aron Griffis]

(moving to gentoo-dev because that's where this thread belongs, and
quoting the entire message just this once to provide context...)

Azarah,

Here are a couple more thoughts: 

1. Maybe the icc ebuild should install wrapper scripts for the icc-CHOST
   form so that it can be used in distcc/cross-compiling.  Also the ccc
   ebuild should do the same.  In fact, it could be a single script with
   multiple symlinks, then setup flags in the script based on name...
   Does this make sense?

2. I think that your PREFERRED_COMPILERS scheme makes sense except that
   it requires the compiler to be a single word.  Now sure, one could
   argue that CC should always be a single word, but people have done
   successful setups with CC="distcc gcc" so I don't think we should
   break that if possible.

I think that it is worthwhile to try to find a good solution to this.
Hopefully we can find one that is elegant enough so that not too much
complexity is added, and it's intuitive for people to use.  Right now
it's a high goal for the alpha team to make ccc a reality, but it cannot
happen unless ccc is automatically selected for the ebuilds on which it
applies.  It's not reasonable to make users run "CC=ccc emerge" to be
able to take advantage of ccc.

I don't have a proposed solution yet in this email, just a couple more
ideas.  But I want to keep this cooking so that we can find a good
solution eventually.

Aron

Azarah wrote:	[Sat Apr 26 2003, 03:21:51PM EDT]
> On Fri, 2003-04-25 at 04:36, Aron Griffis wrote:
>
> > Azarah wrote:[Tue Apr 22 2003, 02:57:11PM EDT]
> > > In theory you should be able to just set CC .... The builds that
> > > do not take this, should be fixed IMHO.
> >
> > Sure, you can set
> >
> >     CC=ccc emerge blah
> >
> > and it should work.  But what we're talking about is setting something
> > so that ebuilds that support ccc will use it, automatically falling back
> > to gcc when the ebuild doesn't support ccc.  That's why it seemed like a
> > USE flag would be appropriate.
> >
> > The problem I can see with a USE flag is that we'd have to clobber CC
> > in the ebuild, for example "use ccc && CC=ccc".  So then the user
> > wouldn't have an easy way to override.
> >
> > So we come back to compiler profiles.  But I don't quite understand how
> > they'll solve this problem.  I don't want to set CC=ccc globally.  I
> > want the ebuilds to know whether they support ccc, and the user can say,
> > "hey, use ccc if you can, otherwise use gcc".
> >
>
> Right.  I do not want to stop change if its for the good, but we should
> also sometimes consider if some complexity is really worth it.  This I
> think IMHO that if we can do it without adding too much complexity,
> sure.
>
> Maybe it could be with something like:
>
> COMPILERS="gcc ccc"
>
> In the ebuild, that say this puppy support both, and then we can have
> something like:
>
> PREFERRED_COMPILERS="ccc gcc"
>
> in make.conf .... portage will then set CC to the compiler from
> PREFERRED_COMPILERS in the order they appear if the ebuild have
> that one in COMPILERS.
>
> A slight snag that comes into ... this could really cause issues with
> distcc/cross-compiling especially if you need the <compiler-front>-CHOST
> type of thing (mostly with distcc when you have diff arch's in the
> cluster).  For example icc do not support the icc-CHOST form, so how
> again we will have to hack portage to disable distcc if icc is used,
> etc.
>
> So this brings me back to my original comment that we should maybe
> consider if this wont add to much complexity and/or hassles.
>
>
> Regards,
>
> --
>
> Martin Schlemmer
> Gentoo Linux Developer, Desktop/System Team Developer
> Cape Town, South Africa
>
>