| 1 |
Donnie Berkholz <spyderous@g.o> posted 44811136.2070109@g.o, |
| 2 |
excerpted below, on Fri, 02 Jun 2006 21:33:58 -0700: |
| 3 |
|
| 4 |
> Jeremy Huddleston wrote: |
| 5 |
>> I finally had a few free cycles, so I fixed up the eselect-compiler |
| 6 |
>> ebuild to better handle the transition from gcc-config and updated |
| 7 |
>> toolchain.eclass to better work with multilib. I've had a bunch of help |
| 8 |
>> from the amd64 devs/testers/users[] |
| 9 |
> |
| 10 |
> Couple of questions: |
| 11 |
> |
| 12 |
> 1) Can it handle non-gcc compilers? If so, how? |
| 13 |
> 2) Can it handle different languages being set to different compilers? |
| 14 |
> For example, use Intel's Fortran compiler but GCC for everything else. |
| 15 |
> |
| 16 |
> If neither of those are possible now, I would like to look into fixing this. |
| 17 |
|
| 18 |
I've been one of the testing users... |
| 19 |
|
| 20 |
Taking into account George's reply, it's not now directly possible, but the |
| 21 |
infrastructure is now there, and could be built upon with appropriate |
| 22 |
eclasses, to be inherited by the ebuild for your compiler of choice (or by |
| 23 |
manually tweaking the config files in /etc/eselect/compiler), at least for |
| 24 |
(1) non-gcc compilers. A lot of the support for gcc is actually in |
| 25 |
toolchain.eclass, but George mentions other compilers should use separate |
| 26 |
eclasses. (That part I'm just repeating from his post.) |
| 27 |
|
| 28 |
Different languages going to different compilers is somewhat more |
| 29 |
problematic. One could switch the whole compiler set to merge just the |
| 30 |
single package in the other language, then switch back, but there's no |
| 31 |
current provision for directing different languages to different places at |
| 32 |
the same time, and adding that would be to my understanding complex enough |
| 33 |
to be a project for eselect-compiler-3.x. |
| 34 |
|
| 35 |
I just remembered a bug I think I filed on portage last year (yes, |
| 36 |
#108393), that's related and AFAIK still needs resolution... |
| 37 |
|
| 38 |
It's only a potential blocker for distcc users, of which I'm not one, so I |
| 39 |
haven't the foggiest if it's serious enough to hold up unmasking of |
| 40 |
eselect-compiler or not. I know the portage warning referenced in comment |
| 41 |
#9 is still there with portage-2.1-rc4 (and obviously, gcc-config is |
| 42 |
installed, but portage is looking in the old gcc-config location, see the |
| 43 |
bug for discussion): |
| 44 |
|
| 45 |
$emerge --info |
| 46 |
!!! Relying on the shell to locate gcc, this may break |
| 47 |
!!! DISTCC, installing gcc-config and setting your current gcc |
| 48 |
!!! profile will fix this |
| 49 |
Portage 2.1_rc4 [snip] |
| 50 |
|
| 51 |
http://bugs.gentoo.org/show_bug.cgi?id=108393 |
| 52 |
|
| 53 |
eradicator is already CCed and has commented on the bug, but what |
| 54 |
discussions have occurred beyond that, or anything beyond what's on the |
| 55 |
bug and in the portage warning related to distcc, I don't know. I did |
| 56 |
just cc lisa (distcc maintainer) on the bug, so we'll see. I have a |
| 57 |
feeling distcc users wouldn't be very happy if unmasking this broke them. |
| 58 |
=8^( |
| 59 |
|
| 60 |
|
| 61 |
|
| 62 |
-- |
| 63 |
Duncan - List replies preferred. No HTML msgs. |
| 64 |
"Every nonfree program has a lord, a master -- |
| 65 |
and if you use the program, he is your master." Richard Stallman |
| 66 |
|
| 67 |
-- |
| 68 |
gentoo-dev@g.o mailing list |
Archives