| 1 |
On Tue, 9 Apr 2013 18:07:28 -0600 |
| 2 |
Ryan Hill <dirtyepic@g.o> wrote: |
| 3 |
|
| 4 |
> On Tue, 9 Apr 2013 22:24:16 +0200 |
| 5 |
> Michał Górny <mgorny@g.o> wrote: |
| 6 |
> |
| 7 |
> > On Tue, 9 Apr 2013 15:24:10 -0400 |
| 8 |
> > Mike Frysinger <vapier@g.o> wrote: |
| 9 |
> > |
| 10 |
> > > On Tuesday 09 April 2013 01:57:47 Michał Górny wrote: |
| 11 |
> > > > On Mon, 8 Apr 2013 23:20:28 -0600 Ryan Hill wrote: |
| 12 |
> > > > > If someone else wants to try and improve the situation, please feel |
| 13 |
> > > > > free. |
| 14 |
> > > > |
| 15 |
> > > > Just to be sure -- would you be ok if we tried to inline some |
| 16 |
> > > > of the eclass code into the ebuilds (future versions/revbumps)? |
| 17 |
> > > |
| 18 |
> > > not really. you can still build gcc-2.95 and newer with the current code, |
| 19 |
> > > but the amount of "tc_version_is_at_least" is fairly low. from time to |
| 20 |
> > > time, people also create their own gcc ebuild forks which use this eclass |
| 21 |
> > > either because it's a completely different code base, orit has some serious |
| 22 |
> > > patches that we aren't interested in carrying, or people want to |
| 23 |
> > > experiment. current examples: kgcc64 msp430 gcc-apple. we've had other |
| 24 |
> > > embedded works in the past, as well as hardened ones. |
| 25 |
> > |
| 26 |
> > Then please don't create a fake feeling like you're going to accept |
| 27 |
> > help to improve the situation. |
| 28 |
> |
| 29 |
> These are things the eclass has to support and the restraints we have to work |
| 30 |
> under. Don't throw a snit if you don't like the problem space. |
| 31 |
|
| 32 |
My point is that if you'll put everything into the eclass you're never |
| 33 |
going to improve it. It will be just going from one mess into another, |
| 34 |
and the ebuilds should never go stable if they don't even have their |
| 35 |
own phase functions. |
| 36 |
|
| 37 |
-- |
| 38 |
Best regards, |
| 39 |
Michał Górny |
Archives