Donnie Berkholz <[EMAIL PROTECTED]> posted [EMAIL PROTECTED],
excerpted below, on  Fri, 02 Jun 2006 21:33:58 -0700:

> Jeremy Huddleston wrote:
>> I finally had a few free cycles, so I fixed up the eselect-compiler
>> ebuild to better handle the transition from gcc-config and updated
>> toolchain.eclass to better work with multilib.  I've had a bunch of help
>> from the amd64 devs/testers/users[]
> Couple of questions:
> 1) Can it handle non-gcc compilers? If so, how?
> 2) Can it handle different languages being set to different compilers?
> For example, use Intel's Fortran compiler but GCC for everything else.
> If neither of those are possible now, I would like to look into fixing this.

I've been one of the testing users...

Taking into account George's reply, it's not now directly possible, but the
infrastructure is now there, and could be built upon with appropriate
eclasses, to be inherited by the ebuild for your compiler of choice (or by
manually tweaking the config files in /etc/eselect/compiler), at least for
(1) non-gcc compilers. A lot of the support for gcc is actually in
toolchain.eclass, but George mentions other compilers should use separate
eclasses.  (That part I'm just repeating from his post.)

Different languages going to different compilers is somewhat more
problematic.  One could switch the whole compiler set to merge just the
single package in the other language, then switch back, but there's no
current provision for directing different languages to different places at
the same time, and adding that would be to my understanding complex enough
to be a project for eselect-compiler-3.x.

I just remembered a bug I think I filed on portage last year (yes,
#108393), that's related and AFAIK still needs resolution...

It's only a potential blocker for distcc users, of which I'm not one, so I
haven't the foggiest if it's serious enough to hold up unmasking of
eselect-compiler or not.  I know the portage warning referenced in comment
#9 is still there with portage-2.1-rc4 (and obviously, gcc-config is
installed, but portage is looking in the old gcc-config location, see the
bug for discussion):

$emerge --info
!!! Relying on the shell to locate gcc, this may break
!!! DISTCC, installing gcc-config and setting your current gcc
!!! profile will fix this
Portage 2.1_rc4 [snip]

eradicator is already CCed and has commented on the bug, but what
discussions have occurred beyond that, or anything beyond what's on the
bug and in the portage warning related to distcc, I don't know.  I did
just cc lisa (distcc maintainer) on the bug, so we'll see.  I have a
feeling distcc users wouldn't be very happy if unmasking this broke them.

Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- mailing list

Reply via email to