Re: [gentoo-dev] sys-devel/gcc::mgorny up for testing

2014-12-11 Thread Joshua Kinard
On 12/09/2014 11:21, Michał Górny wrote:
 Dnia 2014-12-08, o godz. 09:56:11
 Alexis Ballier aball...@gentoo.org napisał(a):
 
 On Sun, 7 Dec 2014 11:37:57 +0100
 Michał Górny mgo...@gentoo.org wrote:

 1. No cross-compilation support. If the project proves being a success
 it will be readded at some point. However, I will likely fork glibc
 first and work on a sane crossdev alternative.

 Could you please elaborate on this ?
 How and why this broke, what is wrong in glibc, what would be a sane
 crossdev alternative and how crossdev is not.
 
 1. eblits are broken in glibc. Another case of incorrect interpretation
 of code sharing with love for breaking stable ebuilds. Plus I'd love to
 add multilib flags to it but we'll likely doing that to main glibc as
 well soon, if eblits don't get into our way.

Originally, eblits were supposed to be ways of sharing common blocks of code
between ebuilds in a specific package, but not anything that would warrant a
new eclass (local package eclasses, kinda?).  They never really took off for
reasons lost to time.  I use them in mips-sources, but version them so that if
I change an eblit, it gets a new version and the old version is removed only
when there are no more consumers.

The idea of eblits itself isn't bad, but probably could use some re-thinking
and/or re-implementation.  Especially if a decent amount of kilobytes can be
shaved off a given package's directory.


 2. crossdev is broken because it creates semi-random, unmaintained
 ebuilds in randomly chosen overlay, those ebuilds relying on
 toolchain.eclass behavior.

I would argue this isn't necessarily broken.  crossdev produces working
cross-toolchains and is a valuable tool for anyone running multiple arches,
especially slower arches.  How it produces said working cross-toolchains is an
implementation detail.  Don't be so hasty as to throw the baby out with the
bathwater.

-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
4096R/D25D95E3 2011-03-28

The past tempts us, the present confuses us, the future frightens us.  And our
lives slip away, moment by moment, lost in that vast, terrible in-between.

--Emperor Turhan, Centauri Republic



Re: [gentoo-dev] sys-devel/gcc::mgorny up for testing

2014-12-09 Thread Tomas Mozes

On 2014-12-07 11:37, Michał Górny wrote:

Hello, developers and users.

As some of you know, the toolchain packages in Gentoo suffer from
lack-of-sanity issues and their maintainers are completely unwilling to
improve things. I have finally decided to start working on a fork of
the sys-devel/gcc ebuilds, and I have some bits ready for initial
testing in 'mgorny' repo, so I would like to know your opinion.


Before you start, the shortcomings are:

1. No cross-compilation support. If the project proves being a success
it will be readded at some point. However, I will likely fork glibc
first and work on a sane crossdev alternative.

2. No gcj support. Since the ebuild has been forked out of
toolchain.eclass, and the gcj support suffers a lot of issues there, I
decided there's no point in copying the code. Not sure if anybody
actually uses it, and if it is actually useful for anything but will
probably get reintroduced one day [above 'if' applies too].

3. No bootstrapping, fallbacks and possible some other random feature
support. The goal was pretty much to get gcc compiling first, and avoid
awful lot of effort if things prove to have no future.

4. Hardened is not tested. I think I have copied all the needed code
and fixed some stuff but I have no clue if it still works ;).


Now, the major changes are:

1. Most of the insanity removed. No more toolchain.eclass. The ebuild
has just the code for the current gcc version. You can read it and know
what it does, you don't have to parse a few dozen version conditionals,
runtime conditionals and random crap code that doesn't do anything in
some gcc versions. In fact, I think I removed most of the no-op code.
And now you can actually change something in the ebuild without caring
for gcc3.4, or without breaking stuff for stable ebuilds.

2. USE flags are supposed to work. I've replaced the cases when they
were silently ignored with REQUIRED_USE. I've also removed the silent
removals when they didn't work -- so if your current toolchain is
broken, things may actually fail instead of giving your different gcc
than you wanted. Probably deserves explanatory pkg_pretend() at some
point, with messages like 'disable USE=-foo because your toolchain is
broken'.

3. Things simplified where they could have been simplified. For
example, I removed the big gcc executable moving function and replaced
it with --enable-version-specific-runtime-libs. It was enabled in
toolchain.eclass with a comment 'If we enable it on non-Darwin we screw
up the behaviour this eclass relies on.' So yep, precious cargo cult --
why enable something that would require you to remove your useless
complex function?!

4. Added gx86-multilib love. Now you have abi_* flags to control
the compiler runtime. Of course, since gcc is a pile of random modules
not fit for one another it has different code for different targets. In
particular, on mips you can't do two ABIs -- either single one
(non-multilib) or all three of them (--enable-multilib).

5. Added multilib gcc wrappers. Long story short, multilib gcc now
shows up in gcc-config alike crossdev -- but unlike i686 crossdev, it
doesn't screw up your system! Of course, the final implementation may
differ since it's an early idea but it works. Now distcc happily builds
stuff for your x86 clients.

6. Added missing dependencies. Yep, USE flags now, say, pull in doxygen
rather than silently skipping doc build when it's not installed...

7. Disabled bootstrap by default (and in fact completely for now). It
is not *that* useful, and means time savings (and distcc support):

 Thu Nov  6 20:39:31 2014  sys-devel/gcc-4.9.2
   merge time: 1 hour, 56 minutes and 43 seconds.

 Sun Dec  7 10:46:08 2014  sys-devel/gcc-4.9.2-r100
   merge time: 34 minutes and 55 seconds.


If you're interested in testing it, 'layman -a mgorny' and enjoy. I'd
appreciate any bug reports, except for those covering things i've
already listed as missing :). Any further comments will be very helpful
in deciding on the way forward.

If there is a real interest in my fork, I will probably move it to gx86
as sys-devel/gcc-mgorny. I will also be happy to work on replacing
the new versions of original sys-devel/gcc completely. With QA process
against toolchain.eclass if necessary.


Thanks, I've tried this on ~amd64. It builds in 10 minutes (wow!), 
tested to build some core stuff with it:

kernel 3.17, glibc, coreutils, openssl, ssh...

All seems to work fine. I'll try to recompile the whole machine with it.

After emerge, there are these notices:
 * QA Notice: command not found:
 *
 *  /var/tmp/portage/sys-devel/gcc-4.9.2-r100/temp/environment: line 
3110: pax-mark: command not found
 *  /var/tmp/portage/sys-devel/gcc-4.9.2-r100/temp/environment: line 
3111: pax-mark: command not found


# emerge -pvq gcc
[ebuild   R   ] sys-devel/gcc-4.9.2-r100  USE=cxx fortran nls nptl 
openmp pie sanitize (-altivec) -doc (-fixed-point) -go -graphite 
(-hardened) (-libssp) -objc -objc++ 

Re: [gentoo-dev] sys-devel/gcc::mgorny up for testing

2014-12-09 Thread Michał Górny
Dnia 2014-12-09, o godz. 14:23:21
Tomas Mozes tomas.mo...@shmu.sk napisał(a):

 On 2014-12-07 11:37, Michał Górny wrote:
  Hello, developers and users.
  
  As some of you know, the toolchain packages in Gentoo suffer from
  lack-of-sanity issues and their maintainers are completely unwilling to
  improve things. I have finally decided to start working on a fork of
  the sys-devel/gcc ebuilds, and I have some bits ready for initial
  testing in 'mgorny' repo, so I would like to know your opinion.
  
  
  Before you start, the shortcomings are:
  
  1. No cross-compilation support. If the project proves being a success
  it will be readded at some point. However, I will likely fork glibc
  first and work on a sane crossdev alternative.
  
  2. No gcj support. Since the ebuild has been forked out of
  toolchain.eclass, and the gcj support suffers a lot of issues there, I
  decided there's no point in copying the code. Not sure if anybody
  actually uses it, and if it is actually useful for anything but will
  probably get reintroduced one day [above 'if' applies too].
  
  3. No bootstrapping, fallbacks and possible some other random feature
  support. The goal was pretty much to get gcc compiling first, and avoid
  awful lot of effort if things prove to have no future.
  
  4. Hardened is not tested. I think I have copied all the needed code
  and fixed some stuff but I have no clue if it still works ;).
  
  
  Now, the major changes are:
  
  1. Most of the insanity removed. No more toolchain.eclass. The ebuild
  has just the code for the current gcc version. You can read it and know
  what it does, you don't have to parse a few dozen version conditionals,
  runtime conditionals and random crap code that doesn't do anything in
  some gcc versions. In fact, I think I removed most of the no-op code.
  And now you can actually change something in the ebuild without caring
  for gcc3.4, or without breaking stuff for stable ebuilds.
  
  2. USE flags are supposed to work. I've replaced the cases when they
  were silently ignored with REQUIRED_USE. I've also removed the silent
  removals when they didn't work -- so if your current toolchain is
  broken, things may actually fail instead of giving your different gcc
  than you wanted. Probably deserves explanatory pkg_pretend() at some
  point, with messages like 'disable USE=-foo because your toolchain is
  broken'.
  
  3. Things simplified where they could have been simplified. For
  example, I removed the big gcc executable moving function and replaced
  it with --enable-version-specific-runtime-libs. It was enabled in
  toolchain.eclass with a comment 'If we enable it on non-Darwin we screw
  up the behaviour this eclass relies on.' So yep, precious cargo cult --
  why enable something that would require you to remove your useless
  complex function?!
  
  4. Added gx86-multilib love. Now you have abi_* flags to control
  the compiler runtime. Of course, since gcc is a pile of random modules
  not fit for one another it has different code for different targets. In
  particular, on mips you can't do two ABIs -- either single one
  (non-multilib) or all three of them (--enable-multilib).
  
  5. Added multilib gcc wrappers. Long story short, multilib gcc now
  shows up in gcc-config alike crossdev -- but unlike i686 crossdev, it
  doesn't screw up your system! Of course, the final implementation may
  differ since it's an early idea but it works. Now distcc happily builds
  stuff for your x86 clients.
  
  6. Added missing dependencies. Yep, USE flags now, say, pull in doxygen
  rather than silently skipping doc build when it's not installed...
  
  7. Disabled bootstrap by default (and in fact completely for now). It
  is not *that* useful, and means time savings (and distcc support):
  
   Thu Nov  6 20:39:31 2014  sys-devel/gcc-4.9.2
 merge time: 1 hour, 56 minutes and 43 seconds.
  
   Sun Dec  7 10:46:08 2014  sys-devel/gcc-4.9.2-r100
 merge time: 34 minutes and 55 seconds.
  
  
  If you're interested in testing it, 'layman -a mgorny' and enjoy. I'd
  appreciate any bug reports, except for those covering things i've
  already listed as missing :). Any further comments will be very helpful
  in deciding on the way forward.
  
  If there is a real interest in my fork, I will probably move it to gx86
  as sys-devel/gcc-mgorny. I will also be happy to work on replacing
  the new versions of original sys-devel/gcc completely. With QA process
  against toolchain.eclass if necessary.
 
 Thanks, I've tried this on ~amd64. It builds in 10 minutes (wow!), 
 tested to build some core stuff with it:
 kernel 3.17, glibc, coreutils, openssl, ssh...
 
 All seems to work fine. I'll try to recompile the whole machine with it.
 
 After emerge, there are these notices:
   * QA Notice: command not found:
   *
   *  /var/tmp/portage/sys-devel/gcc-4.9.2-r100/temp/environment: line 
 3110: pax-mark: command not found
   *  

Re: [gentoo-dev] sys-devel/gcc::mgorny up for testing

2014-12-09 Thread Michał Górny
Dnia 2014-12-08, o godz. 09:56:11
Alexis Ballier aball...@gentoo.org napisał(a):

 On Sun, 7 Dec 2014 11:37:57 +0100
 Michał Górny mgo...@gentoo.org wrote:
 
  1. No cross-compilation support. If the project proves being a success
  it will be readded at some point. However, I will likely fork glibc
  first and work on a sane crossdev alternative.
 
 Could you please elaborate on this ?
 How and why this broke, what is wrong in glibc, what would be a sane
 crossdev alternative and how crossdev is not.

1. eblits are broken in glibc. Another case of incorrect interpretation
of code sharing with love for breaking stable ebuilds. Plus I'd love to
add multilib flags to it but we'll likely doing that to main glibc as
well soon, if eblits don't get into our way.

2. crossdev is broken because it creates semi-random, unmaintained
ebuilds in randomly chosen overlay, those ebuilds relying on
toolchain.eclass behavior.

3. I don't have any real alternative design yet. However, one 
of the first ideas of changing crossdev is to replace copying ebuilds
with symlinking gcc ebuild directory. This will at least ensure proper
sync between real ebuilds and cross-ebuilds.

-- 
Best regards,
Michał Górny


pgpxIrlqF6nnb.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] sys-devel/gcc::mgorny up for testing

2014-12-09 Thread Michał Górny
Dnia 2014-12-08, o godz. 07:27:51
Anthony G. Basile bluen...@gentoo.org napisał(a):

 On 12/07/14 08:18, Michał Górny wrote:
  I will also be happy to work on replacing
  the new versions of original sys-devel/gcc completely. With QA process
  against toolchain.eclass if necessary.
 
  Let's get the list of QA issues so I at least can work towards a
  toolchain-r1.eclass if you're not interested in going that way.  Also, I
  take the QA issues seriously, but threatening a QA intervention against
  toolchain and then acting by forking is heavy handed.  QA actions
  against the current codebase is understandable.
 
  So to sum, I'd like to see the QA issues (and others) address in the
  current approache and toolchain.eclass.  Since we can make mistakes and
  since toolchain is fragile, I suggest a toolchain-r1.eclass where we can
  test (just change the inheritance in gcc ebuilds for testing) and
  finally, when we're happy, do the switcheroo.
  First QA issue: toolchain.eclass is intrusive and makes ebuilds hard to
  understand and track. If you can remove it and make gcc into proper
  ebuilds that can get revision-level changes, we can discuss.
 
 
 Hey! why don't I join QA so I can also fix eclasses that I find 
 intrusive.  Let's not make QA the final refuge of those who want to 
 push through their preferences.

Yes, that's exactly what occurred to me! Then I joined QA.

But seriously saying, I didn't mean forcing anything on anyone myself.
I meant starting proper QA process which could eventually hopefully
result in QA prohibiting the use of current eclass in future ebuilds,
and or referring to the Council about switching the default gcc
provider. Of course, that's only the worst scenario.

 To proceed forward, you have bugs open against toolchain.eclass. The 
 practice is to submit the patches to this list for review.  If after 
 awards you have community support, commit despite the maintainer's 
 objections.  Having obtained community support, you will have much more 
 legitimacy against reverts.  I can't speak for the whole council, but I 
 would support you under such circumstances.  I cannot support a position 
 where QA simply asserts itself.  When/if an appeal percolates up to the 
 council, I will side with the maintainer under the argument that the 
 commit to the eclass was not sufficiently reviewed.

As I already said, the main issue simply can't be fixed this way. It's
not that much *bugs in code in toolchain.eclass* but *what's in
toolchain.eclass*. If we think of eclasses as libraries, then your
library provides main() function. With conditionals for 14 consecutive
releases of your program. And you already told people to link random
stuff to it, and rely on every internal API detail.

-- 
Best regards,
Michał Górny


pgpCY7C6hAMlb.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] sys-devel/gcc::mgorny up for testing

2014-12-09 Thread Alexander Tsoy
В Tue, 9 Dec 2014 17:21:22 +0100
Michał Górny mgo...@gentoo.org пишет:

 Dnia 2014-12-08, o godz. 09:56:11
 Alexis Ballier aball...@gentoo.org napisał(a):
 
  On Sun, 7 Dec 2014 11:37:57 +0100
  Michał Górny mgo...@gentoo.org wrote:
  
   1. No cross-compilation support. If the project proves being a success
   it will be readded at some point. However, I will likely fork glibc
   first and work on a sane crossdev alternative.
  
  Could you please elaborate on this ?
  How and why this broke, what is wrong in glibc, what would be a sane
  crossdev alternative and how crossdev is not.
 
 1. eblits are broken in glibc. Another case of incorrect interpretation
 of code sharing with love for breaking stable ebuilds. Plus I'd love to
 add multilib flags to it but we'll likely doing that to main glibc as
 well soon, if eblits don't get into our way.

Yeah. Stable glibc ebuild gets broken from time to time after changes
in eblits.

 
 2. crossdev is broken because it creates semi-random, unmaintained
 ebuilds in randomly chosen overlay, those ebuilds relying on
 toolchain.eclass behavior.
 
 3. I don't have any real alternative design yet. However, one 
 of the first ideas of changing crossdev is to replace copying ebuilds
 with symlinking gcc ebuild directory. This will at least ensure proper
 sync between real ebuilds and cross-ebuilds.
 

crossdev already works that way for a long time (see -oO option in
help):

$ ls -l /var/cache/portage/repos/crossdev/cross-armv6j-hardfloat-linux-gnueabi/
total 0
lrwxrwxrwx 1 portage portage 42 Oct 23 22:24 binutils - 
/var/cache/portage/tree/sys-devel/binutils
lrwxrwxrwx 1 portage portage 37 Oct 23 22:24 gcc - 
/var/cache/portage/tree/sys-devel/gcc
lrwxrwxrwx 1 portage portage 37 Oct 23 22:24 gdb - 
/var/cache/portage/tree/sys-devel/gdb
lrwxrwxrwx 1 portage portage 38 Oct 23 22:24 glibc - 
/var/cache/portage/tree/sys-libs/glibc
lrwxrwxrwx 1 portage portage 48 Oct 23 22:24 linux-headers - 
/var/cache/portage/tree/sys-kernel/linux-headers

-- 
Alexander Tsoy



Re: [gentoo-dev] sys-devel/gcc::mgorny up for testing

2014-12-09 Thread Alexis Ballier
On Tue, 9 Dec 2014 17:21:22 +0100
Michał Górny mgo...@gentoo.org wrote:

 Dnia 2014-12-08, o godz. 09:56:11
 Alexis Ballier aball...@gentoo.org napisał(a):
 
  On Sun, 7 Dec 2014 11:37:57 +0100
  Michał Górny mgo...@gentoo.org wrote:
  
   1. No cross-compilation support. If the project proves being a
   success it will be readded at some point. However, I will likely
   fork glibc first and work on a sane crossdev alternative.
  
  Could you please elaborate on this ?
  How and why this broke, what is wrong in glibc, what would be a
  sane crossdev alternative and how crossdev is not.
 
 1. eblits are broken in glibc. Another case of incorrect
 interpretation of code sharing with love for breaking stable ebuilds.

its a local toolchain.eclass yes

 Plus I'd love to add multilib flags to it but we'll likely doing that
 to main glibc as well soon, if eblits don't get into our way.

keep in mind that, thanks to implicit system deps, you'll have to
use.force what your toolchain is supposed to be able to produce.

also, you'll probably face much more problems with bootstrapping
than the cosmetics of eblits: get a gcc that can compile .o for your
abi is easy, but you do not have the libc yet so can't link anything
unless you use nodefaultlibs alike switches

 2. crossdev is broken because it creates semi-random, unmaintained
 ebuilds in randomly chosen overlay, those ebuilds relying on
 toolchain.eclass behavior.

it symlinks the dirs these days, so its not unmaintained

toolchain.eclass behavior you're referring to is probably the category
parsing to get CTARGET; this is very likely used in all other libc
ebuilds so you'll have to fix them too; not mentioning the ability to
update your cross toolchains with 'emerge world' that you cant do if
you dont feed CTARGET in some way.


 3. I don't have any real alternative design yet. However, one 
 of the first ideas of changing crossdev is to replace copying ebuilds
 with symlinking gcc ebuild directory. This will at least ensure proper
 sync between real ebuilds and cross-ebuilds.


as said above, this is the case here

Alexis.



Re: [gentoo-dev] sys-devel/gcc::mgorny up for testing

2014-12-08 Thread Alexis Ballier
On Sun, 7 Dec 2014 11:37:57 +0100
Michał Górny mgo...@gentoo.org wrote:

 1. No cross-compilation support. If the project proves being a success
 it will be readded at some point. However, I will likely fork glibc
 first and work on a sane crossdev alternative.

Could you please elaborate on this ?
How and why this broke, what is wrong in glibc, what would be a sane
crossdev alternative and how crossdev is not.

Alexis.



Re: [gentoo-dev] sys-devel/gcc::mgorny up for testing

2014-12-08 Thread Anthony G. Basile

On 12/07/14 08:18, Michał Górny wrote:

I will also be happy to work on replacing
the new versions of original sys-devel/gcc completely. With QA process
against toolchain.eclass if necessary.


Let's get the list of QA issues so I at least can work towards a
toolchain-r1.eclass if you're not interested in going that way.  Also, I
take the QA issues seriously, but threatening a QA intervention against
toolchain and then acting by forking is heavy handed.  QA actions
against the current codebase is understandable.

So to sum, I'd like to see the QA issues (and others) address in the
current approache and toolchain.eclass.  Since we can make mistakes and
since toolchain is fragile, I suggest a toolchain-r1.eclass where we can
test (just change the inheritance in gcc ebuilds for testing) and
finally, when we're happy, do the switcheroo.

First QA issue: toolchain.eclass is intrusive and makes ebuilds hard to
understand and track. If you can remove it and make gcc into proper
ebuilds that can get revision-level changes, we can discuss.



Hey! why don't I join QA so I can also fix eclasses that I find 
intrusive.  Let's not make QA the final refuge of those who want to 
push through their preferences.


To proceed forward, you have bugs open against toolchain.eclass. The 
practice is to submit the patches to this list for review.  If after 
awards you have community support, commit despite the maintainer's 
objections.  Having obtained community support, you will have much more 
legitimacy against reverts.  I can't speak for the whole council, but I 
would support you under such circumstances.  I cannot support a position 
where QA simply asserts itself.  When/if an appeal percolates up to the 
council, I will side with the maintainer under the argument that the 
commit to the eclass was not sufficiently reviewed.


--
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA




Re: [gentoo-dev] sys-devel/gcc::mgorny up for testing

2014-12-08 Thread Rich Freeman
On Mon, Dec 8, 2014 at 7:27 AM, Anthony G. Basile bluen...@gentoo.org wrote:
 On 12/07/14 08:18, Michał Górny wrote:

 I will also be happy to work on replacing
 the new versions of original sys-devel/gcc completely. With QA process
 against toolchain.eclass if necessary.

 Let's get the list of QA issues so I at least can work towards a
 toolchain-r1.eclass if you're not interested in going that way.  Also, I
 take the QA issues seriously, but threatening a QA intervention against
 toolchain and then acting by forking is heavy handed.  QA actions
 against the current codebase is understandable.

 So to sum, I'd like to see the QA issues (and others) address in the
 current approache and toolchain.eclass.  Since we can make mistakes and
 since toolchain is fragile, I suggest a toolchain-r1.eclass where we can
 test (just change the inheritance in gcc ebuilds for testing) and
 finally, when we're happy, do the switcheroo.

 First QA issue: toolchain.eclass is intrusive and makes ebuilds hard to
 understand and track. If you can remove it and make gcc into proper
 ebuilds that can get revision-level changes, we can discuss.


 Hey! why don't I join QA so I can also fix eclasses that I find
 intrusive.  Let's not make QA the final refuge of those who want to push
 through their preferences.

 To proceed forward, you have bugs open against toolchain.eclass. The
 practice is to submit the patches to this list for review.  If after awards
 you have community support, commit despite the maintainer's objections.
 Having obtained community support, you will have much more legitimacy
 against reverts.  I can't speak for the whole council, but I would support
 you under such circumstances.  I cannot support a position where QA simply
 asserts itself.  When/if an appeal percolates up to the council, I will side
 with the maintainer under the argument that the commit to the eclass was not
 sufficiently reviewed.


++ regarding how QA should operate.

I have no issues with him forking the ebuild and doing things his own
way though.

--
Rich



Re: [gentoo-dev] sys-devel/gcc::mgorny up for testing

2014-12-08 Thread Anthony G. Basile

On 12/07/14 17:41, William Hubbs wrote:

On Sun, Dec 07, 2014 at 08:32:57AM -0500, Rich Freeman wrote:

On Sun, Dec 7, 2014 at 8:05 AM, Anthony G. Basile
bas...@opensource.dyc.edu wrote:

On 12/07/14 05:37, Michał Górny wrote:

If you're interested in testing it, 'layman -a mgorny' and enjoy. I'd
appreciate any bug reports, except for those covering things i've
already listed as missing :). Any further comments will be very helpful
in deciding on the way forward.

Removing the eclass is a bad idea:

0) This reduces code reusability.  The eclass is used by sys-devel/kgcc64 in
the tree and (at least) the hardened-dev::musl overlay outside.

Well, other packages could keep using the eclass.

I think that eclasses tend to get abused in situations like these.  It
is one thing if you have 300 ebuilds that are all maintained together
like there are with kde and logic really is shared in common between
them.

However, this eclass is only used by a few packages, the shared code
isn't across stuff installed in parallel but across stuff that changes
over time.  This is done without upstream support for the most part,
so it becomes a growing collection of workarounds.  When eclasses
start following different code paths every time a package that uses
them is versioned, it makes a lot more sense to either version the
eclass every time or move the code to the ebuild.

This makes sense to me as well, let's work twoard getting rid of
toolchain.eclass.


Hardened has used the eclass in its overlay and continues to use it.  We 
do not wish to get rid of it.


@hardened, we should discuss this at our next meeting.


1) Those version specific conditionals that you don't like give a
history/comparison of gcc versions.  It is not cruft.  It encodes what
versions allow what features.  Moving to the ebuilds makes this history much
harder to read.  Think of a diff -Naur when producing a patch.  I like the
current eclass approach.

Why do we need a history/comparison of gcc written in shell script?
Wouldn't a text file or webpage be a better way to document this?
Wouldn't upstream be the place to document this?

This seems a bit like saying that we don't need the EAPI/PMS guide or
even PMS itself because anybody can just read the portage source code
and figure out how it works.

If you need a list of what features are supported in what versions of
gcc, wouldn't it make more sense to create a wiki page somewhere?

I thinkk this makes more sense as well. Historical reasons don't work
for me by them selves as a reason to justify keeping old code,
especially when it is to support versions of packages that are no longer
really supported upstream.


I'm not sure what you mean by old code which is no longer really 
supported upstream.  gcc is built using gcc.  We should have a window 
on gcc versions which goes backwards and forwards a couple of versions, 
so I can build 4.8 with 4.7 or 4.6 and vice versa.  And build 4.6 with 
4.5 or 4.4, etc.  There is an entire chain there. Keeping the detailed 
decisions in an eclass of what features were on/off for each version 
makes sense so we can conveniently track that chain.  When I say I want 
to keep history, that's what I'm talking about.  In hardened we went 
through a pains taking process of making sure the first hardened gcc-4 
versions (4.4 I believe) was buildable by the previous one, and that it 
could build itself and could rebuild itself both adding and remove 
hardening etc.  (BTW by we I mean Magnus who deserves all the kudos.  
I just helped with testing and told him what broke.)


If you want to simplify code, then let's bump all the gcc ebuilds to 
EAPI 4 or above and refactor the phase functions and remove all the EAPI 
checks.  But removing all instances of tc_version_is_* is not a good idea.





If there is a real interest in my fork, I will probably move it to gx86
as sys-devel/gcc-mgorny.


I don't think we should proceed this way.  The way I'd like to proceed is to
introduce a new toolchain-r1.eclass which addresses at least your QA issues
below.  If I understood Ryan's plan with the eclass, it was to simply
refactor the phase functions to modernize things but keep backwards compat.
When toolchain-r1.eclass is mature, then we switch the inherit.  I'd like to
keep gcc-2* and gcc-3* around.  We could consider cleaning up those ebuilds
to work with EAPI=4 or 5 with the new eclass or just leave them with the old
eclass.

Why do you want to keep these outdated and not supported versions of gcc
around? Have you tried building a modern system with gcc-2 or gcc-3? I
haven't but I'm sure it would fail horribly.


But not certain embedded systems or other scenarios.  gcc-3 for instance 
did hardening differently than 4.  While I'm not as interested in gcc-2, 
I don't want to see gcc-3 dumped.  Even minor leaps like 4.7 to 4.8 
introduced deep changes like requiring c++. Its easy to say, why do we 
need this? when one forgets that evolution, or was never familiar with it.


This 

Re: [gentoo-dev] sys-devel/gcc::mgorny up for testing

2014-12-08 Thread Anthony G. Basile

On 12/08/14 07:32, Rich Freeman wrote:

On Mon, Dec 8, 2014 at 7:27 AM, Anthony G. Basile bluen...@gentoo.org wrote:

On 12/07/14 08:18, Michał Górny wrote:

I will also be happy to work on replacing
the new versions of original sys-devel/gcc completely. With QA process
against toolchain.eclass if necessary.


Let's get the list of QA issues so I at least can work towards a
toolchain-r1.eclass if you're not interested in going that way.  Also, I
take the QA issues seriously, but threatening a QA intervention against
toolchain and then acting by forking is heavy handed.  QA actions
against the current codebase is understandable.

So to sum, I'd like to see the QA issues (and others) address in the
current approache and toolchain.eclass.  Since we can make mistakes and
since toolchain is fragile, I suggest a toolchain-r1.eclass where we can
test (just change the inheritance in gcc ebuilds for testing) and
finally, when we're happy, do the switcheroo.

First QA issue: toolchain.eclass is intrusive and makes ebuilds hard to
understand and track. If you can remove it and make gcc into proper
ebuilds that can get revision-level changes, we can discuss.


Hey! why don't I join QA so I can also fix eclasses that I find
intrusive.  Let's not make QA the final refuge of those who want to push
through their preferences.

To proceed forward, you have bugs open against toolchain.eclass. The
practice is to submit the patches to this list for review.  If after awards
you have community support, commit despite the maintainer's objections.
Having obtained community support, you will have much more legitimacy
against reverts.  I can't speak for the whole council, but I would support
you under such circumstances.  I cannot support a position where QA simply
asserts itself.  When/if an appeal percolates up to the council, I will side
with the maintainer under the argument that the commit to the eclass was not
sufficiently reviewed.


++ regarding how QA should operate.

I have no issues with him forking the ebuild and doing things his own
way though.

--
Rich



Forking code does not address the QA issues currently against 
toolchain.eclass.  The two issues are orthogonal and I don't think I 
connected them in my emails.  I disagree with forking but have no right 
to obstruct it and would not.  In that respect, I'm simply voicing my 
opinion as a dev.   However regarding how QA should operate, I am 
operating with the guidelines of gentoo self-governance.


--
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA




Re: [gentoo-dev] sys-devel/gcc::mgorny up for testing

2014-12-08 Thread Rich Freeman
On Mon, Dec 8, 2014 at 9:00 AM, Anthony G. Basile bluen...@gentoo.org wrote:

 Forking code does not address the QA issues currently against
 toolchain.eclass.  The two issues are orthogonal and I don't think I
 connected them in my emails.  I disagree with forking but have no right to
 obstruct it and would not.  In that respect, I'm simply voicing my opinion
 as a dev.   However regarding how QA should operate, I am operating with the
 guidelines of gentoo self-governance.


++

Honestly, I don't think internal forks are terribly helpful either in
the long run.  Sometimes they seem to be needed at some point to at
least push things along, but obviously it would be better to focus on
one package.  I just don't want to be critical of those who want to
fork things, as they usually have very legitimate concerns and at
least by forking they're producing something new that people can play
with and test, which can help us cross the gap from where we are to
where we want to be.

A big reason there are forks is that sometimes people just get fed up
with trying to work with people and would prefer to go do something
even if it basically means re-inventing the wheel.

I was thinking about this earlier today after being somewhat
frustrated with a completely different FOSS issue.  The nature of
Gentoo tends to draw a lot of people who want to achieve their vision
of technical perfection.  This makes it really hard for all of us to
work together.  I'll admit that there are times I get sick of some of
the debates on the lists/etc, and I'm sure everybody on all sides of
every issue tends to feel the same way.  We keep coming back because
we think there is something here worth fighting for, and sometimes
even worth compromising for.

Forks can be a way to try out new things, and turning theoretical
arguments into practical comparisons.  Sure, they can also be
incredible wastes of time, but so is just about anything that any of
us do for fun.  I think that creating something new is far more
productive than arguing on lists, even if in the end the work gets
abandoned (though this is rarely the case - usually something gets
re-appropriated which is the whole point of FOSS).  Forks are also a
great way to get new blood into an arcane subject - making incremental
changes on a mature codebase is often a lot harder than making
incremental changes on a new codebase that likely leaves out 50% of
the corner cases.

If we don't have friendly internal competition, it will just make it
that much harder to stay relevant.  Let's just try to keep it
friendly.  :)

--
Rich



Re: [gentoo-dev] sys-devel/gcc::mgorny up for testing

2014-12-08 Thread Matt Turner
On Sun, Dec 7, 2014 at 5:05 AM, Anthony G. Basile
bas...@opensource.dyc.edu wrote:
 0) This reduces code reusability.  The eclass is used by sys-devel/kgcc64 in
 the tree and (at least) the hardened-dev::musl overlay outside.

Yes, but while your claim that it reduces reusability is true, I think
that's potentially a good thing.

With all of the logic encoded in that huge eclass, any modifications
to it change the code any version of the gcc ebuild executes,
including stable versions that you're not thinking about at the time.

eclasses are pretty great for sharing code akin to a library, but when
*all* of your ebuild's logic is in the eclass, well, that's not really
the intended use case as far as I can tell.

glibc does the same thing with eblits.

I think I remember Ciaran making the same argument in the past, but
much better said than mine.



Re: [gentoo-dev] sys-devel/gcc::mgorny up for testing

2014-12-08 Thread Rich Freeman
On Mon, Dec 8, 2014 at 12:08 PM, Matt Turner matts...@gentoo.org wrote:
 eclasses are pretty great for sharing code akin to a library, but when
 *all* of your ebuild's logic is in the eclass, well, that's not really
 the intended use case as far as I can tell.

It works well in cases like KDE where you have 300 ebuilds that all
just set a few environment variables and then genuinely share common
code for everything else.  Also, major updates only come once every
few years, which helps keep the eclass from becoming a rat's nest.  I
think it is better to just version an eclass instead of having a mess
of conditionals based on version, but then we'd have 300 revisions of
toolchain.eclass (which is probably a good hint that we're doing it
wrong).

A library is a good analogy of how to avoid all of this.  Each
function does one thing well, and you call them as you need them, and
you don't tweak their APIs 10 times per year.  And if you find you're
never using a function more than once after doing this, then you don't
need a library in the first place.

--
Rich



[gentoo-dev] sys-devel/gcc::mgorny up for testing

2014-12-07 Thread Michał Górny
Hello, developers and users.

As some of you know, the toolchain packages in Gentoo suffer from
lack-of-sanity issues and their maintainers are completely unwilling to
improve things. I have finally decided to start working on a fork of
the sys-devel/gcc ebuilds, and I have some bits ready for initial
testing in 'mgorny' repo, so I would like to know your opinion.


Before you start, the shortcomings are:

1. No cross-compilation support. If the project proves being a success
it will be readded at some point. However, I will likely fork glibc
first and work on a sane crossdev alternative.

2. No gcj support. Since the ebuild has been forked out of
toolchain.eclass, and the gcj support suffers a lot of issues there, I
decided there's no point in copying the code. Not sure if anybody
actually uses it, and if it is actually useful for anything but will
probably get reintroduced one day [above 'if' applies too].

3. No bootstrapping, fallbacks and possible some other random feature
support. The goal was pretty much to get gcc compiling first, and avoid
awful lot of effort if things prove to have no future.

4. Hardened is not tested. I think I have copied all the needed code
and fixed some stuff but I have no clue if it still works ;).


Now, the major changes are:

1. Most of the insanity removed. No more toolchain.eclass. The ebuild
has just the code for the current gcc version. You can read it and know
what it does, you don't have to parse a few dozen version conditionals,
runtime conditionals and random crap code that doesn't do anything in
some gcc versions. In fact, I think I removed most of the no-op code.
And now you can actually change something in the ebuild without caring
for gcc3.4, or without breaking stuff for stable ebuilds.

2. USE flags are supposed to work. I've replaced the cases when they
were silently ignored with REQUIRED_USE. I've also removed the silent
removals when they didn't work -- so if your current toolchain is
broken, things may actually fail instead of giving your different gcc
than you wanted. Probably deserves explanatory pkg_pretend() at some
point, with messages like 'disable USE=-foo because your toolchain is
broken'.

3. Things simplified where they could have been simplified. For
example, I removed the big gcc executable moving function and replaced
it with --enable-version-specific-runtime-libs. It was enabled in
toolchain.eclass with a comment 'If we enable it on non-Darwin we screw
up the behaviour this eclass relies on.' So yep, precious cargo cult --
why enable something that would require you to remove your useless
complex function?!

4. Added gx86-multilib love. Now you have abi_* flags to control
the compiler runtime. Of course, since gcc is a pile of random modules
not fit for one another it has different code for different targets. In
particular, on mips you can't do two ABIs -- either single one
(non-multilib) or all three of them (--enable-multilib).

5. Added multilib gcc wrappers. Long story short, multilib gcc now
shows up in gcc-config alike crossdev -- but unlike i686 crossdev, it
doesn't screw up your system! Of course, the final implementation may
differ since it's an early idea but it works. Now distcc happily builds
stuff for your x86 clients.

6. Added missing dependencies. Yep, USE flags now, say, pull in doxygen
rather than silently skipping doc build when it's not installed...

7. Disabled bootstrap by default (and in fact completely for now). It
is not *that* useful, and means time savings (and distcc support):

 Thu Nov  6 20:39:31 2014  sys-devel/gcc-4.9.2
   merge time: 1 hour, 56 minutes and 43 seconds.

 Sun Dec  7 10:46:08 2014  sys-devel/gcc-4.9.2-r100
   merge time: 34 minutes and 55 seconds.


If you're interested in testing it, 'layman -a mgorny' and enjoy. I'd
appreciate any bug reports, except for those covering things i've
already listed as missing :). Any further comments will be very helpful
in deciding on the way forward.

If there is a real interest in my fork, I will probably move it to gx86
as sys-devel/gcc-mgorny. I will also be happy to work on replacing
the new versions of original sys-devel/gcc completely. With QA process
against toolchain.eclass if necessary.

-- 
Best regards,
Michał Górny


pgpmJHeoXvp15.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] sys-devel/gcc::mgorny up for testing

2014-12-07 Thread Daniel Campbell
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/07/2014 04:37 AM, Michał Górny wrote:
 Hello, developers and users.
 
 As some of you know, the toolchain packages in Gentoo suffer from 
 lack-of-sanity issues and their maintainers are completely 
 unwilling to improve things. I have finally decided to start 
 working on a fork of the sys-devel/gcc ebuilds, and I have some 
 bits ready for initial testing in 'mgorny' repo, so I would like
 to know your opinion.
 
 
 Before you start, the shortcomings are:
 
 1. No cross-compilation support. If the project proves being a 
 success it will be readded at some point. However, I will likely 
 fork glibc first and work on a sane crossdev alternative.
 
 2. No gcj support. Since the ebuild has been forked out of 
 toolchain.eclass, and the gcj support suffers a lot of issues 
 there, I decided there's no point in copying the code. Not sure if 
 anybody actually uses it, and if it is actually useful for
 anything but will probably get reintroduced one day [above 'if'
 applies too].
 
 3. No bootstrapping, fallbacks and possible some other random 
 feature support. The goal was pretty much to get gcc compiling 
 first, and avoid awful lot of effort if things prove to have no 
 future.
 
 4. Hardened is not tested. I think I have copied all the needed 
 code and fixed some stuff but I have no clue if it still works ;).
 
 
 Now, the major changes are:
 
 1. Most of the insanity removed. No more toolchain.eclass. The 
 ebuild has just the code for the current gcc version. You can read 
 it and know what it does, you don't have to parse a few dozen 
 version conditionals, runtime conditionals and random crap code 
 that doesn't do anything in some gcc versions. In fact, I think I 
 removed most of the no-op code. And now you can actually change 
 something in the ebuild without caring for gcc3.4, or without 
 breaking stuff for stable ebuilds.
 
 2. USE flags are supposed to work. I've replaced the cases when 
 they were silently ignored with REQUIRED_USE. I've also removed
 the silent removals when they didn't work -- so if your current 
 toolchain is broken, things may actually fail instead of giving 
 your different gcc than you wanted. Probably deserves explanatory 
 pkg_pretend() at some point, with messages like 'disable USE=-foo 
 because your toolchain is broken'.
 
 3. Things simplified where they could have been simplified. For 
 example, I removed the big gcc executable moving function and 
 replaced it with --enable-version-specific-runtime-libs. It was 
 enabled in toolchain.eclass with a comment 'If we enable it on 
 non-Darwin we screw up the behaviour this eclass relies on.' So 
 yep, precious cargo cult -- why enable something that would
 require you to remove your useless complex function?!
 
 4. Added gx86-multilib love. Now you have abi_* flags to control 
 the compiler runtime. Of course, since gcc is a pile of random 
 modules not fit for one another it has different code for
 different targets. In particular, on mips you can't do two ABIs --
 either single one (non-multilib) or all three of them 
 (--enable-multilib).
 
 5. Added multilib gcc wrappers. Long story short, multilib gcc now
  shows up in gcc-config alike crossdev -- but unlike i686
 crossdev, it doesn't screw up your system! Of course, the final 
 implementation may differ since it's an early idea but it works. 
 Now distcc happily builds stuff for your x86 clients.
 
 6. Added missing dependencies. Yep, USE flags now, say, pull in 
 doxygen rather than silently skipping doc build when it's not 
 installed...
 
 7. Disabled bootstrap by default (and in fact completely for now). 
 It is not *that* useful, and means time savings (and distcc 
 support):
 
 Thu Nov  6 20:39:31 2014  sys-devel/gcc-4.9.2 merge time: 1 
 hour, 56 minutes and 43 seconds.
 
 Sun Dec  7 10:46:08 2014  sys-devel/gcc-4.9.2-r100 merge time: 
 34 minutes and 55 seconds.
 
 
 If you're interested in testing it, 'layman -a mgorny' and enjoy. 
 I'd appreciate any bug reports, except for those covering things 
 i've already listed as missing :). Any further comments will be 
 very helpful in deciding on the way forward.
 
 If there is a real interest in my fork, I will probably move it to 
 gx86 as sys-devel/gcc-mgorny. I will also be happy to work on 
 replacing the new versions of original sys-devel/gcc completely. 
 With QA process against toolchain.eclass if necessary.
 

As a user, what would adopting this do? For instance I run ~amd64
multilib and have had quite a time dealing with the recent multilib
changes (specifically with Humble Bundle games). Would you recommend
helping you test this simplified and/or cleaned up toolchain on one's
primary system, or is it better off for more specific systems that
don't need to be as versatile as a multi-purpose desktop machine?

Regardless, it seems really ambitious and I hope positive change comes
about for the toolchain.
-BEGIN PGP SIGNATURE-
Version: 

Re: [gentoo-dev] sys-devel/gcc::mgorny up for testing

2014-12-07 Thread Michał Górny
Dnia 2014-12-07, o godz. 04:43:05
Daniel Campbell cont...@sporkbox.us napisał(a):

  If you're interested in testing it, 'layman -a mgorny' and enjoy. 
  I'd appreciate any bug reports, except for those covering things 
  i've already listed as missing :). Any further comments will be 
  very helpful in deciding on the way forward.
  
  If there is a real interest in my fork, I will probably move it to 
  gx86 as sys-devel/gcc-mgorny. I will also be happy to work on 
  replacing the new versions of original sys-devel/gcc completely. 
  With QA process against toolchain.eclass if necessary.
 
 As a user, what would adopting this do? For instance I run ~amd64
 multilib and have had quite a time dealing with the recent multilib
 changes (specifically with Humble Bundle games). Would you recommend
 helping you test this simplified and/or cleaned up toolchain on one's
 primary system, or is it better off for more specific systems that
 don't need to be as versatile as a multi-purpose desktop machine?

I wouldn't run it on production system, or when you need crossdev with
4.9.2. If you're on Hardened or some less common system, I wouldn't try
it as the primary compiler. Also, best if you have a backup gcc or
binary package you can downgrade to (quickpkg --include-configs=y gcc).

That said, I'm running it on all my ~amd64 and ~x86 systems and it
works. I've rebuilt all packages on my devbox using it and nothing
(new) failed. However, I didn't try building it using gcc-4.8.


-- 
Best regards,
Michał Górny


pgpweEuQ2mrd0.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] sys-devel/gcc::mgorny up for testing

2014-12-07 Thread Anthony G. Basile

On 12/07/14 05:37, Michał Górny wrote:


If you're interested in testing it, 'layman -a mgorny' and enjoy. I'd
appreciate any bug reports, except for those covering things i've
already listed as missing :). Any further comments will be very helpful
in deciding on the way forward.


Removing the eclass is a bad idea:

0) This reduces code reusability.  The eclass is used by 
sys-devel/kgcc64 in the tree and (at least) the hardened-dev::musl 
overlay outside.


1) Those version specific conditionals that you don't like give a 
history/comparison of gcc versions.  It is not cruft.  It encodes what 
versions allow what features.  Moving to the ebuilds makes this history 
much harder to read.  Think of a diff -Naur when producing a patch.  I 
like the current eclass approach.


2) Getting this to work with hardened and cross compiling and 
musl/uclibc is going to need re-writing far beyond the eclass.  The gain 
is in my opinion not worth it given what I suggest below:




If there is a real interest in my fork, I will probably move it to gx86
as sys-devel/gcc-mgorny.


I don't think we should proceed this way.  The way I'd like to proceed 
is to introduce a new toolchain-r1.eclass which addresses at least your 
QA issues below.  If I understood Ryan's plan with the eclass, it was to 
simply refactor the phase functions to modernize things but keep 
backwards compat.  When toolchain-r1.eclass is mature, then we switch 
the inherit.  I'd like to keep gcc-2* and gcc-3* around.  We could 
consider cleaning up those ebuilds to work with EAPI=4 or 5 with the new 
eclass or just leave them with the old eclass.


Also, no to the name sys-devel/gcc-mgorny.  I very much appreciate the 
excellent hard work you've done on eclasses, but the reason this is 
happening is because of patches that toolchain lead is not accepting. 
Anyhow, most of the work with gcc (in my opinion) is with the patches 
against gcc itself which are housed in ~vapier, ~rhill and ~zorry.  When 
you don't accept my patches to gcc-mgorny, shall I add gcc-basile to the 
tree?


I will also be happy to work on replacing

the new versions of original sys-devel/gcc completely. With QA process
against toolchain.eclass if necessary.



Let's get the list of QA issues so I at least can work towards a 
toolchain-r1.eclass if you're not interested in going that way.  Also, I 
take the QA issues seriously, but threatening a QA intervention against 
toolchain and then acting by forking is heavy handed.  QA actions 
against the current codebase is understandable.


So to sum, I'd like to see the QA issues (and others) address in the 
current approache and toolchain.eclass.  Since we can make mistakes and 
since toolchain is fragile, I suggest a toolchain-r1.eclass where we can 
test (just change the inheritance in gcc ebuilds for testing) and 
finally, when we're happy, do the switcheroo.



--
Anthony G. Basile, Ph. D.
Chair of Information Technology
D'Youville College
Buffalo, NY 14201
(716) 829-8197



Re: [gentoo-dev] sys-devel/gcc::mgorny up for testing

2014-12-07 Thread Michał Górny
Dnia 2014-12-07, o godz. 08:05:59
Anthony G. Basile bas...@opensource.dyc.edu napisał(a):

 On 12/07/14 05:37, Michał Górny wrote:
 
  If you're interested in testing it, 'layman -a mgorny' and enjoy. I'd
  appreciate any bug reports, except for those covering things i've
  already listed as missing :). Any further comments will be very helpful
  in deciding on the way forward.
 
 Removing the eclass is a bad idea:
 
 0) This reduces code reusability.  The eclass is used by 
 sys-devel/kgcc64 in the tree and (at least) the hardened-dev::musl 
 overlay outside.

kgcc64 is no longer necessary given --enable-targets in gcc.
And the eclass code is not really reusable, it's too damn complex
and too tightly-coupled to be.

 1) Those version specific conditionals that you don't like give a 
 history/comparison of gcc versions.  It is not cruft.  It encodes what 
 versions allow what features.  Moving to the ebuilds makes this history 
 much harder to read.  Think of a diff -Naur when producing a patch.  I 
 like the current eclass approach.

And why should I care about what gcc3.4 had? I'd rather have a properly
working gcc4.[89] ebuild I could understand. Without code that no
longer does anything but you can't see it because you are blinded by
stupid conditionals and eclass complexity.

  If there is a real interest in my fork, I will probably move it to gx86
  as sys-devel/gcc-mgorny.
 
 I don't think we should proceed this way.  The way I'd like to proceed 
 is to introduce a new toolchain-r1.eclass which addresses at least your 
 QA issues below.  If I understood Ryan's plan with the eclass, it was to 
 simply refactor the phase functions to modernize things but keep 
 backwards compat.  When toolchain-r1.eclass is mature, then we switch 
 the inherit.  I'd like to keep gcc-2* and gcc-3* around.  We could 
 consider cleaning up those ebuilds to work with EAPI=4 or 5 with the new 
 eclass or just leave them with the old eclass.

And we create a new eclass every time the old one proves being
unmaintainable to the point nobody is willing to work on it? That's
a workaround, not a solution to the problem.

 Also, no to the name sys-devel/gcc-mgorny.  I very much appreciate the 
 excellent hard work you've done on eclasses, but the reason this is 
 happening is because of patches that toolchain lead is not accepting. 
 Anyhow, most of the work with gcc (in my opinion) is with the patches 
 against gcc itself which are housed in ~vapier, ~rhill and ~zorry.  When 
 you don't accept my patches to gcc-mgorny, shall I add gcc-basile to the 
 tree?

Naming is the least of the problems. As far as I am concerned, it can
be 'gcc-sanity-restored' or whatever.

  I will also be happy to work on replacing
  the new versions of original sys-devel/gcc completely. With QA process
  against toolchain.eclass if necessary.
 
 
 Let's get the list of QA issues so I at least can work towards a 
 toolchain-r1.eclass if you're not interested in going that way.  Also, I 
 take the QA issues seriously, but threatening a QA intervention against 
 toolchain and then acting by forking is heavy handed.  QA actions 
 against the current codebase is understandable.
 
 So to sum, I'd like to see the QA issues (and others) address in the 
 current approache and toolchain.eclass.  Since we can make mistakes and 
 since toolchain is fragile, I suggest a toolchain-r1.eclass where we can 
 test (just change the inheritance in gcc ebuilds for testing) and 
 finally, when we're happy, do the switcheroo.

First QA issue: toolchain.eclass is intrusive and makes ebuilds hard to
understand and track. If you can remove it and make gcc into proper
ebuilds that can get revision-level changes, we can discuss.

-- 
Best regards,
Michał Górny


pgpKvo5EUZxOY.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] sys-devel/gcc::mgorny up for testing

2014-12-07 Thread Rich Freeman
On Sun, Dec 7, 2014 at 8:05 AM, Anthony G. Basile
bas...@opensource.dyc.edu wrote:
 On 12/07/14 05:37, Michał Górny wrote:

 If you're interested in testing it, 'layman -a mgorny' and enjoy. I'd
 appreciate any bug reports, except for those covering things i've
 already listed as missing :). Any further comments will be very helpful
 in deciding on the way forward.

 Removing the eclass is a bad idea:

 0) This reduces code reusability.  The eclass is used by sys-devel/kgcc64 in
 the tree and (at least) the hardened-dev::musl overlay outside.

Well, other packages could keep using the eclass.

I think that eclasses tend to get abused in situations like these.  It
is one thing if you have 300 ebuilds that are all maintained together
like there are with kde and logic really is shared in common between
them.

However, this eclass is only used by a few packages, the shared code
isn't across stuff installed in parallel but across stuff that changes
over time.  This is done without upstream support for the most part,
so it becomes a growing collection of workarounds.  When eclasses
start following different code paths every time a package that uses
them is versioned, it makes a lot more sense to either version the
eclass every time or move the code to the ebuild.


 1) Those version specific conditionals that you don't like give a
 history/comparison of gcc versions.  It is not cruft.  It encodes what
 versions allow what features.  Moving to the ebuilds makes this history much
 harder to read.  Think of a diff -Naur when producing a patch.  I like the
 current eclass approach.

Why do we need a history/comparison of gcc written in shell script?
Wouldn't a text file or webpage be a better way to document this?
Wouldn't upstream be the place to document this?

This seems a bit like saying that we don't need the EAPI/PMS guide or
even PMS itself because anybody can just read the portage source code
and figure out how it works.

If you need a list of what features are supported in what versions of
gcc, wouldn't it make more sense to create a wiki page somewhere?


 If there is a real interest in my fork, I will probably move it to gx86
 as sys-devel/gcc-mgorny.


 I don't think we should proceed this way.  The way I'd like to proceed is to
 introduce a new toolchain-r1.eclass which addresses at least your QA issues
 below.  If I understood Ryan's plan with the eclass, it was to simply
 refactor the phase functions to modernize things but keep backwards compat.
 When toolchain-r1.eclass is mature, then we switch the inherit.  I'd like to
 keep gcc-2* and gcc-3* around.  We could consider cleaning up those ebuilds
 to work with EAPI=4 or 5 with the new eclass or just leave them with the old
 eclass.

 Also, no to the name sys-devel/gcc-mgorny.  I very much appreciate the
 excellent hard work you've done on eclasses, but the reason this is
 happening is because of patches that toolchain lead is not accepting.
 Anyhow, most of the work with gcc (in my opinion) is with the patches
 against gcc itself which are housed in ~vapier, ~rhill and ~zorry.  When you
 don't accept my patches to gcc-mgorny, shall I add gcc-basile to the tree?

Well, that would be in keeping with GLEP 39, which seems to encourage
everybody to fork each other's packages.  :)

It seems like there is a fundamental disagreement here over the right
way to refactor all this code.  Honestly, the fact that nobody seems
to even want to look at the toolchain suggests to me that
simplification is probably worthwhile.


 I will also be happy to work on replacing

 the new versions of original sys-devel/gcc completely. With QA process
 against toolchain.eclass if necessary.


 Let's get the list of QA issues so I at least can work towards a
 toolchain-r1.eclass if you're not interested in going that way.  Also, I
 take the QA issues seriously, but threatening a QA intervention against
 toolchain and then acting by forking is heavy handed.  QA actions against
 the current codebase is understandable.

Agree somewhat.

Forking is perfectly fine - a complete non-issue.  Trying to exclude
the other branch in the name of QA is something we need to be careful
about and consider on the merits.  If somebody wants to add yet
another gcc implementation to the tree and it is really lousy, I don't
really have a problem with it if it builds and doesn't contain
security issues, etc.  I think people sometimes try to make QA into
something that it isn't.  In the same way there is nothing wrong with
the existing gcc implementation being completely unmaintainable and
obsolete as long as it builds and doesn't contain security issues.

I think the real issue we run into in these kinds of cases is
namespace.  If I want to add my own competing ebuild for chromium I
can't call it chromium.

--
Rich



Re: [gentoo-dev] sys-devel/gcc::mgorny up for testing

2014-12-07 Thread William Hubbs
On Sun, Dec 07, 2014 at 08:32:57AM -0500, Rich Freeman wrote:
 On Sun, Dec 7, 2014 at 8:05 AM, Anthony G. Basile
 bas...@opensource.dyc.edu wrote:
  On 12/07/14 05:37, Michał Górny wrote:
 
  If you're interested in testing it, 'layman -a mgorny' and enjoy. I'd
  appreciate any bug reports, except for those covering things i've
  already listed as missing :). Any further comments will be very helpful
  in deciding on the way forward.
 
  Removing the eclass is a bad idea:
 
  0) This reduces code reusability.  The eclass is used by sys-devel/kgcc64 in
  the tree and (at least) the hardened-dev::musl overlay outside.
 
 Well, other packages could keep using the eclass.
 
 I think that eclasses tend to get abused in situations like these.  It
 is one thing if you have 300 ebuilds that are all maintained together
 like there are with kde and logic really is shared in common between
 them.
 
 However, this eclass is only used by a few packages, the shared code
 isn't across stuff installed in parallel but across stuff that changes
 over time.  This is done without upstream support for the most part,
 so it becomes a growing collection of workarounds.  When eclasses
 start following different code paths every time a package that uses
 them is versioned, it makes a lot more sense to either version the
 eclass every time or move the code to the ebuild.

This makes sense to me as well, let's work twoard getting rid of
toolchain.eclass.

 
 
  1) Those version specific conditionals that you don't like give a
  history/comparison of gcc versions.  It is not cruft.  It encodes what
  versions allow what features.  Moving to the ebuilds makes this history much
  harder to read.  Think of a diff -Naur when producing a patch.  I like the
  current eclass approach.
 
 Why do we need a history/comparison of gcc written in shell script?
 Wouldn't a text file or webpage be a better way to document this?
 Wouldn't upstream be the place to document this?
 
 This seems a bit like saying that we don't need the EAPI/PMS guide or
 even PMS itself because anybody can just read the portage source code
 and figure out how it works.
 
 If you need a list of what features are supported in what versions of
 gcc, wouldn't it make more sense to create a wiki page somewhere?

I thinkk this makes more sense as well. Historical reasons don't work
for me by them selves as a reason to justify keeping old code,
especially when it is to support versions of packages that are no longer
really supported upstream.

 
 
  If there is a real interest in my fork, I will probably move it to gx86
  as sys-devel/gcc-mgorny.
 
 
  I don't think we should proceed this way.  The way I'd like to proceed is to
  introduce a new toolchain-r1.eclass which addresses at least your QA issues
  below.  If I understood Ryan's plan with the eclass, it was to simply
  refactor the phase functions to modernize things but keep backwards compat.
  When toolchain-r1.eclass is mature, then we switch the inherit.  I'd like to
  keep gcc-2* and gcc-3* around.  We could consider cleaning up those ebuilds
  to work with EAPI=4 or 5 with the new eclass or just leave them with the old
  eclass.

Why do you want to keep these outdated and not supported versions of gcc
around? Have you tried building a modern system with gcc-2 or gcc-3? I
haven't but I'm sure it would fail horribly.

 
  Also, no to the name sys-devel/gcc-mgorny.  I very much appreciate the
  excellent hard work you've done on eclasses, but the reason this is
  happening is because of patches that toolchain lead is not accepting.
  Anyhow, most of the work with gcc (in my opinion) is with the patches
  against gcc itself which are housed in ~vapier, ~rhill and ~zorry.  When you
  don't accept my patches to gcc-mgorny, shall I add gcc-basile to the tree?
 
 Well, that would be in keeping with GLEP 39, which seems to encourage
 everybody to fork each other's packages.  :)
 
 It seems like there is a fundamental disagreement here over the right
 way to refactor all this code.  Honestly, the fact that nobody seems
 to even want to look at the toolchain suggests to me that
 simplification is probably worthwhile.
 
 I tend to agree here too; let's get rid of the old versions of things
 where we can and simplify.

William



signature.asc
Description: Digital signature