[gentoo-dev] eselect-compiler updates and unmasking

[gentoo-dev] eselect-compiler updates and unmasking

[Jeremy Huddleston]

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 this past week testing it out,  
and I think it's ready to be removed from package.mask sometime soon  
(next week).  Before that happens, I'd like to get some feedback from  
a broader test base, so if you have some time and aren't using  
eselect-compiler yet, I'd appreciate your testing.  All you need to  
do is add the following to /etc/portage/package.unmask:

app-admin/eselect-conmpiler
sys-devel/gcc-config

then just update gcc-config:
$ emerge -uv --oneshot sys-devel/gcc-config

gcc-config is just a wrapper which takes the same syntax as the older  
gcc-configs and makes the appropriate call to eselect-compiler.

Please report any bugs you find in bugzilla and assign them directly  
to me (eradicator@gentoo.org).

Also, if you've been using eselect-compiler, you may have an issue  
where your profiles don't get removed from /etc/eselect/compiler when  
you unmerge gcc.  This problem is fixed now for future installs, but  
you'll have to manually remove the file when you unmerge any gcc that  
is on your system now.

Thanks,
Jeremy

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] eselect-compiler updates and unmasking

[Donnie Berkholz]

[-- Attachment #1: Type: text/plain, Size: 972 bytes --]

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 this past week testing it out, and I
> think it's ready to be removed from package.mask sometime soon (next
> week).  Before that happens, I'd like to get some feedback from a
> broader test base, so if you have some time and aren't using
> eselect-compiler yet, I'd appreciate your testing.  All you need to do
> is add the following to /etc/portage/package.unmask:

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.

Thanks,
Donnie


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [gentoo-dev] eselect-compiler updates and unmasking

[George Shapovalov]

Saturday, 3. June 2006 06:33, Donnie Berkholz Ви написали:
> Jeremy Huddleston wrote:
> 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.
>
> Thanks,
> Donnie

Well, incidentally I was working on "toolchainasing" gnat (a gcc based Ada 
compiler, basically just another frontend) and pestered toolchain people on 
irc regarding similar matters. Basically it came down to: toolchain.eclass 
and eselect-compiler are not for stuff not in gcc, so I had to create my own 
ones (gnatbuild.eclass and eselect-gnat), a bit simpler versions actually :). 
I could not inherit toolchain.eclass either, only copy the relevant parts of 
it..

A due notice: this was discussed already like half a year ago (although when I 
announced progress here on -dev no comments followed), so if the things have 
chaged since then I will be interested to know too..

George


-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: eselect-compiler updates and unmasking

[Duncan]

Donnie Berkholz <spyderous@gentoo.org> posted 44811136.2070109@gentoo.org,
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

Re: [gentoo-dev] eselect-compiler updates and unmasking

[Gamesgrid Poker]

> Couple of questions:
>
> 1) Can it handle non-gcc compilers? If so, how?

It is possible, but I'm not sure if icc is installed in a way that  
makes it convenient.  All the binaries will need to be lumped in a  
directory by themselves (like we do with gcc).  You'll have to create  
your own profile in /etc/eselect/compiler.

> 2) Can it handle different languages being set to different compilers?
> For example, use Intel's Fortran compiler but GCC for everything else.

No, this isn't something I considered a high priority.  I was more  
interested in tackling the issues road-blocking multilib, but this is  
something that would be a nice feature down the road.

> If neither of those are possible now, I would like to look into  
> fixing this.
>
> Thanks,
> Donnie

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] eselect-compiler updates and unmasking

[Jeremy Huddleston]

> Well, incidentally I was working on "toolchainasing" gnat (a gcc  
> based Ada
> compiler, basically just another frontend) and pestered toolchain  
> people on
> irc regarding similar matters. Basically it came down to:  
> toolchain.eclass
> and eselect-compiler are not for stuff not in gcc, so I had to  
> create my own
> ones (gnatbuild.eclass and eselect-gnat), a bit simpler versions  
> actually :).
> I could not inherit toolchain.eclass either, only copy the relevant  
> parts of
> it..
>
> A due notice: this was discussed already like half a year ago  
> (although when I
> announced progress here on -dev no comments followed), so if the  
> things have
> chaged since then I will be interested to know too..

Well, I'm not against that support being in eselect-compiler, and in  
fact I think it'd be nice... It's just not a priority on my list, so  
if you'd like to contribute changes which allow support for what you  
want without needlessly complicating things for those who don't want  
to use these advanced features, then I'm more than willing to  
incorporate them.

--Jeremy
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] eselect-compiler updates and unmasking

[Jeremy Huddleston]

On Jun 2, 2006, at 21:33 , Donnie Berkholz wrote:

> Couple of questions:
>
> 1) Can it handle non-gcc compilers? If so, how?

It is possible, but I'm not sure if icc is installed in a way that  
makes it convenient.  All the binaries will need to be lumped in a  
directory by themselves (like we do with gcc).  You'll have to create  
your own profile in /etc/eselect/compiler.

> 2) Can it handle different languages being set to different compilers?
> For example, use Intel's Fortran compiler but GCC for everything else.
>

No, this isn't something I considered a high priority.  I was more  
interested in tackling the issues road-blocking multilib, but this is  
something that would be a nice feature down the road.


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] eselect-compiler updates and unmasking

[Ned Ludd]

Why are you hijacking tools not written by you, declaring 
them as 2.0 and breaking the expected behaviors of them?

Please don't do that ever again.


On Fri, 2006-06-02 at 21:24 -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 this past week testing it out,  
> and I think it's ready to be removed from package.mask sometime soon  
> (next week).  Before that happens, I'd like to get some feedback from  
> a broader test base, so if you have some time and aren't using  
> eselect-compiler yet, I'd appreciate your testing.  All you need to  
> do is add the following to /etc/portage/package.unmask:
> 
> app-admin/eselect-conmpiler
> sys-devel/gcc-config
> 
> then just update gcc-config:
> $ emerge -uv --oneshot sys-devel/gcc-config
> 
> gcc-config is just a wrapper which takes the same syntax as the older  
> gcc-configs and makes the appropriate call to eselect-compiler.
> 
> Please report any bugs you find in bugzilla and assign them directly  
> to me (eradicator@gentoo.org).
> 
> Also, if you've been using eselect-compiler, you may have an issue  
> where your profiles don't get removed from /etc/eselect/compiler when  
> you unmerge gcc.  This problem is fixed now for future installs, but  
> you'll have to manually remove the file when you unmerge any gcc that  
> is on your system now.
> 
> Thanks,
> Jeremy
> 
-- 
Ned Ludd <solar@gentoo.org>
Gentoo Linux

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] eselect-compiler updates and unmasking

[Jeremy Huddleston]

Uhm, what is this all about?  If you have suggestions, make them, but  
don't come out of the gate in a huff talking about unsubstantiated  
breakage.  That's about the least constructive way to get heard.

The wrapper provided in gcc-config-2.0 provides the exact same  
interface to the user as gcc-config-1.x, so how is that breaking  
expected behavior?  If anything, it's providing expected behavior to  
users who want it and don't care about migrating over to eselect.   
Additionally, If you check through the ChangeLog, you'll see that I  
did actively worked on gcc-config-1.x last year prior to my starting  
eselect-compiler.  That's how I came to realize its limitations and  
_need_ for replacement on multilib systems.  A similar wrapper is  
needed for binutils as has been discussed multiple times on  
toolchain@, and at amd64 and ppc64 dev meetings on IRC.

Additionally, eselect-compiler has been discussed multiple times on  
the toolchain and gentoo-dev lists over the past year (main threads  
started 2005-08-09, 2005-09-17, 2005.10.02), and you didn't once  
raise an objection until now.  I'd say you missed the 10 month window  
I gave you, but if you do have suggestions, I'd be more than happy to  
hear them.

Even more so, I left eselect-compiler in package.mask for a _very_  
long time as I didn't have much time to devote to its development  
over the past school year.  During that time, very few issues were  
raised despite it being used by many testers and developers.  This  
past month, I worked out all but one of the known bugs (the one  
remaining is just specific to the wine package on amd64) and got more  
testers to give it a final beating before finally unmasking it.  If  
anything, this has been an extremely conservative development process  
because of the nature of this package.

--Jeremy

On Jun 6, 2006, at 04:28 , Ned Ludd wrote:

> Why are you hijacking tools not written by you, declaring
> them as 2.0 and breaking the expected behaviors of them?
>
> Please don't do that ever again.
>
>
> On Fri, 2006-06-02 at 21:24 -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 this past week testing it out,
>> and I think it's ready to be removed from package.mask sometime soon
>> (next week).  Before that happens, I'd like to get some feedback from
>> a broader test base, so if you have some time and aren't using
>> eselect-compiler yet, I'd appreciate your testing.  All you need to
>> do is add the following to /etc/portage/package.unmask:
>>
>> app-admin/eselect-conmpiler
>> sys-devel/gcc-config
>>
>> then just update gcc-config:
>> $ emerge -uv --oneshot sys-devel/gcc-config
>>
>> gcc-config is just a wrapper which takes the same syntax as the older
>> gcc-configs and makes the appropriate call to eselect-compiler.
>>
>> Please report any bugs you find in bugzilla and assign them directly
>> to me (eradicator@gentoo.org).
>>
>> Also, if you've been using eselect-compiler, you may have an issue
>> where your profiles don't get removed from /etc/eselect/compiler when
>> you unmerge gcc.  This problem is fixed now for future installs, but
>> you'll have to manually remove the file when you unmerge any gcc that
>> is on your system now.
>>
>> Thanks,
>> Jeremy
>>
> -- 
> Ned Ludd <solar@gentoo.org>
> Gentoo Linux
>
> -- 
> gentoo-dev@gentoo.org mailing list
>

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] eselect-compiler updates and unmasking

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 421 bytes --]

On Tuesday 06 June 2006 18:39, Jeremy Huddleston wrote:
> Uhm, what is this all about?  If you have suggestions, make them, but
> don't come out of the gate in a huff talking about unsubstantiated
> breakage.  That's about the least constructive way to get heard.

i guess his point is, you're the only guy supporting eselect-compiler ... if 
you arent going to be around to support it, then dont unmask it
-mike

[-- Attachment #2: Type: application/pgp-signature, Size: 827 bytes --]

Re: [gentoo-dev] eselect-compiler updates and unmasking

[Jeremy Huddleston]

On Jun 7, 2006, at 02:47 , Mike Frysinger wrote:
> On Tuesday 06 June 2006 18:39, Jeremy Huddleston wrote:
>> Uhm, what is this all about?  If you have suggestions, make them, but
>> don't come out of the gate in a huff talking about unsubstantiated
>> breakage.  That's about the least constructive way to get heard.
>
> i guess his point is, you're the only guy supporting eselect- 
> compiler ... if
> you arent going to be around to support it, then dont unmask it
> -mike

Yeah, I couldn't agree more.  That's part of the reason why I hadn't  
unmasked it until now.

--Jeremy

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] eselect-compiler updates and unmasking

[Donnie Berkholz]

[-- Attachment #1: Type: text/plain, Size: 937 bytes --]

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 this past week testing it out, and I
> think it's ready to be removed from package.mask sometime soon (next
> week).  Before that happens, I'd like to get some feedback from a
> broader test base, so if you have some time and aren't using
> eselect-compiler yet, I'd appreciate your testing.  All you need to do
> is add the following to /etc/portage/package.unmask:

This aliases g77 to gfortran and gfortran to g77. They are entirely
different compilers and do not accept all the same options. This is
incredibly broken behavior, it masks issues in a number of packages and
creates new issues in many others. Please fix it.

Thanks,
Donnie


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [gentoo-dev] eselect-compiler updates and unmasking

[Donnie Berkholz]

[-- Attachment #1: Type: text/plain, Size: 452 bytes --]

Donnie Berkholz wrote:
> This aliases g77 to gfortran and gfortran to g77. They are entirely
> different compilers and do not accept all the same options. This is
> incredibly broken behavior, it masks issues in a number of packages and
> creates new issues in many others. Please fix it.

It also doesn't run env-update, so the library paths aren't updated. In
the past, all that was necessary was to source /etc/profile.

Thanks,
Donnie


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [gentoo-dev] eselect-compiler updates and unmasking

[Kumba]

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 this past week testing it out, and I 
> think it's ready to be removed from package.mask sometime soon (next 
> week).  Before that happens, I'd like to get some feedback from a 
> broader test base, so if you have some time and aren't using 
> eselect-compiler yet, I'd appreciate your testing.  All you need to do 
> is add the following to /etc/portage/package.unmask:
> 
> app-admin/eselect-conmpiler
> sys-devel/gcc-config
> 
> then just update gcc-config:
> $ emerge -uv --oneshot sys-devel/gcc-config
> 
> gcc-config is just a wrapper which takes the same syntax as the older 
> gcc-configs and makes the appropriate call to eselect-compiler.
> 
> Please report any bugs you find in bugzilla and assign them directly to 
> me (eradicator@gentoo.org).
> 
> Also, if you've been using eselect-compiler, you may have an issue where 
> your profiles don't get removed from /etc/eselect/compiler when you 
> unmerge gcc.  This problem is fixed now for future installs, but you'll 
> have to manually remove the file when you unmerge any gcc that is on 
> your system now.
> 
> Thanks,
> Jeremy


Just a heads up: if anyone runs crossdev (even with -p), then finds a broken 
gcc-config, the reason lies in Bug #136140.


In a similar vein, will this eselect tool eventually supplant the functionality 
of binutils-config as well (and thus need its own wrapper script)?


--Kumba

-- 
Gentoo/MIPS Team Lead
Gentoo Foundation Board of Trustees

"Such is oft the course of deeds that move the wheels of the world: small hands 
do them because they must, while the eyes of the great are elsewhere."  --Elrond
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] eselect-compiler updates and unmasking

[Danny van Dyk]

Hi Kumba,

> In a similar vein, will this eselect tool eventually supplant the
> functionality of binutils-config as well (and thus need its own
> wrapper script)?

Have a look at eselect binutils please, which is shipped with 
app-admin/eselect.

Danny
-- 
Danny van Dyk <kugelfang@gentoo.org>
Gentoo/AMD64 Project, Gentoo Scientific Project
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] eselect-compiler updates and unmasking

[Diego 'Flameeyes' Pettenò]

[-- Attachment #1: Type: text/plain, Size: 365 bytes --]

On Friday 09 June 2006 10:15, Danny van Dyk wrote:
> Have a look at eselect binutils please, which is shipped with
> app-admin/eselect.
It's sub-optimal compared to eselect compiler, x86_64 ld does not work with 
i686.

-- 
Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] eselect-compiler updates and unmasking

[Danny van Dyk]

Hi Diego,

> It's sub-optimal compared to eselect compiler, x86_64 ld does not
> work with i686.
eselect binutils should be as capable as binutils-config. AFAIK the
stated behaviour is no regression. If it is a regression, please file a
bug against it. If it isn't, file a bug for an enhancement request. I'm
quite positive we can get it going. :-)

Danny
-- 
Danny van Dyk <kugelfang@gentoo.org>
Gentoo/AMD64 Project, Gentoo Scientific Project
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] eselect-compiler updates and unmasking

[Jeremy Huddleston]

Ah, you're right, there should be an env-update in there.  Thanks for  
the report.

As for sourcing /etc/profile, you don't need to do that with eselect- 
compiler because your $PATH doesn't change like it did with gcc- 
config-1.x.

--Jeremy

On Jun 8, 2006, at 11:27 , Donnie Berkholz wrote:

> Donnie Berkholz wrote:
>> This aliases g77 to gfortran and gfortran to g77. They are entirely
>> different compilers and do not accept all the same options. This is
>> incredibly broken behavior, it masks issues in a number of  
>> packages and
>> creates new issues in many others. Please fix it.
>
> It also doesn't run env-update, so the library paths aren't  
> updated. In
> the past, all that was necessary was to source /etc/profile.
>
> Thanks,
> Donnie
>

-- 
gentoo-dev@gentoo.org mailing list