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] http://bugs.gentoo.org/show_bug.cgi?id=108393 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. =8^( -- 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 -- gentoo-dev@gentoo.org mailing list
