gcc Recipes

gcc Recipes

[Richard Purdie]

I've just been looking over OE's gcc recipes and they really depress
me :(. People touch them just enough to tweak their specific problem
with no real thought going into the overall architecture and its a
sprawling mess. I tackled some of this a while back. Sadly its just
getting worse again.

I've spent some time looking at them trying to identify what I consider
to be the main sources of ugliness and how we can try and improve the
situation. I think it might help to set a high level goal for the gcc
recipes which would be:

   All configuration for a given gcc version should be contained 
   within the high level version specific .inc file(gcc-X.Y.Z.inc).

We'd therefore be frowning on version specific hacks in say the cross
recipes only.

It would follow that there would be a clear set of include files and a
clear include structure and that almost all of the variant gcc recipes
(gcc-cross-initial, gcc-cross-intermediate, gcc-cross-kernel,
gcc-cross-sdk, gcc) would be boilerplate includes.

Note that information about flags for the cross builds can be included
in the main common version specific include file.

To illustrate the kind of thing I mean, have a look at this commit:

http://git.openembedded.net/cgit.cgi/openembedded/commit/?h=rpurdie/work-in-progress&id=35481122d7e484fb740ad9440fb4c70cb01de48f

The nice thing about this is all of a sudden we have all the flags in
the same place and it becomes obvious if something is wrong. There are a
few things that raise an eyebrow there. It also becomes easier to
abstract some of the gcc-X.Y.Z.inc data into a common include file
(maybe a gcc-4.3.X.inc for example).

Does anyone else fancy helping trying to clean this mess up. I'm happy
to review some cleanup patches?

Cheers,

Richard

Re: gcc Recipes

[Frans Meulenbroeks]

2010/3/31 Richard Purdie <rpurdie@rpsys.net>:
> I've just been looking over OE's gcc recipes and they really depress
> me :(. People touch them just enough to tweak their specific problem
> with no real thought going into the overall architecture and its a
> sprawling mess. I tackled some of this a while back. Sadly its just
> getting worse again.
>
> I've spent some time looking at them trying to identify what I consider
> to be the main sources of ugliness and how we can try and improve the
> situation. I think it might help to set a high level goal for the gcc
> recipes which would be:
>
>   All configuration for a given gcc version should be contained
>   within the high level version specific .inc file(gcc-X.Y.Z.inc).
>
> We'd therefore be frowning on version specific hacks in say the cross
> recipes only.
>
> It would follow that there would be a clear set of include files and a
> clear include structure and that almost all of the variant gcc recipes
> (gcc-cross-initial, gcc-cross-intermediate, gcc-cross-kernel,
> gcc-cross-sdk, gcc) would be boilerplate includes.
>
> Note that information about flags for the cross builds can be included
> in the main common version specific include file.
>
> To illustrate the kind of thing I mean, have a look at this commit:
>
> http://git.openembedded.net/cgit.cgi/openembedded/commit/?h=rpurdie/work-in-progress&id=35481122d7e484fb740ad9440fb4c70cb01de48f
>
> The nice thing about this is all of a sudden we have all the flags in
> the same place and it becomes obvious if something is wrong. There are a
> few things that raise an eyebrow there. It also becomes easier to
> abstract some of the gcc-X.Y.Z.inc data into a common include file
> (maybe a gcc-4.3.X.inc for example).
>
> Does anyone else fancy helping trying to clean this mess up. I'm happy
> to review some cleanup patches?
>
> Cheers,
>
> Richard
>
>

Richard,

I share your feeling of discomfort and depression.
Personally I feel cleaning up should start with removing obsolete &
unneeded versions as it is pointless spending time on improving them.
I've tried to stir up the discussion on cleaning up a few times, and
gave up due to too much negative feedback and little positive
feedback.
But still I wonder what is e.g. the use of recipes like 4.1.1 (which
btw was released in may 2006).

Having said that:
I've looked at your commit. Looks fine to me so a +1 & thumbs up.

Frans.

PS: not sure about all the variants, but it might be nice to be able
to use something like BBCLASSEXTEND="cross".
Don't think my pythonese and knowledge of the gcc build system is good
enough to cook up something though.

Re: gcc Recipes

[Phil Blundell]

On Wed, 2010-03-31 at 13:45 +0200, Frans Meulenbroeks wrote:
> But still I wonder what is e.g. the use of recipes like 4.1.1 (which
> btw was released in may 2006).

Binary compatibility with existing distributions which use that version
of gcc.  This is particularly important for kernel modules where the
exact compiler version needs to match, and it is also something of an
issue for folks using C++.

p.

Re: gcc Recipes

[Richard Purdie]

On Wed, 2010-03-31 at 13:45 +0200, Frans Meulenbroeks wrote:
> I share your feeling of discomfort and depression.
> Personally I feel cleaning up should start with removing obsolete &
> unneeded versions as it is pointless spending time on improving them.
> I've tried to stir up the discussion on cleaning up a few times, and
> gave up due to too much negative feedback and little positive
> feedback.
> But still I wonder what is e.g. the use of recipes like 4.1.1 (which
> btw was released in may 2006).

I don't think removing old versions is going to cut it to be honest as
people are attached to them for various reasons. Having them around
isn't really a problem, I'm more concerned about the general sprawl of
the recipes which makes them hard to understand. Its clear some are more
broken than others.

> Having said that:
> I've looked at your commit. Looks fine to me so a +1 & thumbs up.
>
> PS: not sure about all the variants, but it might be nice to be able
> to use something like BBCLASSEXTEND="cross".
> Don't think my pythonese and knowledge of the gcc build system is good
> enough to cook up something though.

Well, the variants are ugly but before we can thing about doing anything
about them using BBCLASSEXTEND they have to be condensed down to:

require gcc_${PV}.bb
inherit someclass

This is another reason to try and focus the details into one place as
perhaps then we'll be able to achieve something like this. Even if we
don't use BBCLASSEXTEND, making large numbers of the files simple boiler
plate will make it easier to understand.

Cheers,

Richard

Re: gcc Recipes

[Mark Richards]

Richard Purdie , On 3/31/2010 07:28:
> I've just been looking over OE's gcc recipes and they really depress
> me :(. People touch them just enough to tweak their specific problem
> with no real thought going into the overall architecture and its a
> sprawling mess. I tackled some of this a while back. Sadly its just
> getting worse again.
>
>    
I'm prompted to reply, not as I am experienced enough (in the least) to 
help, so sorry about that, but to offer a thought about recipes and OE 
in general.  I hope this thought will apply to this thread.

When starting to use OE I was surprised that it is necessary to tinker 
with recipes at all.  For that matter, I've had to tinker with other 
things as well, which means that every update has a potential to wipe 
out my changes.  Now this is probably just an expression of the fact 
that I am very new to this environment...

In another development system (one I am very fond of) the build process 
checks for the presence of and content of user-created configuration 
files which serve various purposes.  Principally these tell the system 
where it can find additional libraries and source trees to build and 
include in the end-result.  This method protects all the internals from 
mangling, which I think is what I am reading in your description of the 
Recipes as a "sprawling mess".  This then makes the overall system 
dysfunctional downstream and, as you point out, requires fixing to get 
it back into a state that can be understood and worked with properly.  
Now this system I speak of has only 10% of the power of OE, so perhaps 
it is not a fair comparison.  Yet I think a good principle to follow is 
one that provides user-specific hooks that insulate the internals.  One 
should only tinker with the works if it will be consistent with the 
overall design and not break functionality.

/mark

Re: gcc Recipes

[Khem Raj]

On Wed, Mar 31, 2010 at 4:28 AM, Richard Purdie <rpurdie@rpsys.net> wrote:
> I've just been looking over OE's gcc recipes and they really depress
> me :(. People touch them just enough to tweak their specific problem
> with no real thought going into the overall architecture and its a
> sprawling mess. I tackled some of this a while back. Sadly its just
> getting worse again.
>
> I've spent some time looking at them trying to identify what I consider
> to be the main sources of ugliness and how we can try and improve the
> situation. I think it might help to set a high level goal for the gcc
> recipes which would be:
>
>   All configuration for a given gcc version should be contained
>   within the high level version specific .inc file(gcc-X.Y.Z.inc).
>
> We'd therefore be frowning on version specific hacks in say the cross
> recipes only.
>
> It would follow that there would be a clear set of include files and a
> clear include structure and that almost all of the variant gcc recipes
> (gcc-cross-initial, gcc-cross-intermediate, gcc-cross-kernel,
> gcc-cross-sdk, gcc) would be boilerplate includes.
>
> Note that information about flags for the cross builds can be included
> in the main common version specific include file.
>
> To illustrate the kind of thing I mean, have a look at this commit:
>
> http://git.openembedded.net/cgit.cgi/openembedded/commit/?h=rpurdie/work-in-progress&id=35481122d7e484fb740ad9440fb4c70cb01de48f
>

in one place you removed DEPENDS that may not be correct. Because
DEPENDS get overwritten in gcc-cross-initial.inc


diff --git a/recipes/gcc/gcc-cross-initial_4.0.0.bb
b/recipes/gcc/gcc-cross-initial_4.0.0.bb
index 976cd96..1639511 100644
--- a/recipes/gcc/gcc-cross-initial_4.0.0.bb
+++ b/recipes/gcc/gcc-cross-initial_4.0.0.bb
@@ -1,6 +1,2 @@
require gcc-cross_${PV}.bb
require gcc-cross-initial.inc
-
-DEPENDS += "gmp-native mpfr-native"
-
-EXTRA_OECONF += "--disable-multilib --disable-libssp --disable-libmudflap"




> The nice thing about this is all of a sudden we have all the flags in
> the same place and it becomes obvious if something is wrong. There are a
> few things that raise an eyebrow there. It also becomes easier to
> abstract some of the gcc-X.Y.Z.inc data into a common include file
> (maybe a gcc-4.3.X.inc for example).

I this this is a good idea. We could even capture some bugs like in
some recipes we use EXTRA_OECONF_BASE += and in some EXTRA_OECONF_BASE
=

>
> Does anyone else fancy helping trying to clean this mess up. I'm happy
> to review some cleanup patches?

I plan to do some of this restructuring when I am back from my time
off in end of april.

>
> Cheers,
>
> Richard
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: gcc Recipes

[Richard Purdie]

On Wed, 2010-03-31 at 10:25 -0700, Khem Raj wrote:
> On Wed, Mar 31, 2010 at 4:28 AM, Richard Purdie <rpurdie@rpsys.net> wrote:
> > To illustrate the kind of thing I mean, have a look at this commit:
> >
> > http://git.openembedded.net/cgit.cgi/openembedded/commit/?h=rpurdie/work-in-progress&id=35481122d7e484fb740ad9440fb4c70cb01de48f
> >
> 
> in one place you removed DEPENDS that may not be correct. Because
> DEPENDS get overwritten in gcc-cross-initial.inc

Ah, I messed up the commits. That bit should have been in the previous
commit where it makes more sense:

http://git.openembedded.net/cgit.cgi/openembedded/commit/?h=rpurdie/work-in-progress&id=ec04a8b72958e616da55e30ec1d731424d77ed9d

> > The nice thing about this is all of a sudden we have all the flags in
> > the same place and it becomes obvious if something is wrong. There are a
> > few things that raise an eyebrow there. It also becomes easier to
> > abstract some of the gcc-X.Y.Z.inc data into a common include file
> > (maybe a gcc-4.3.X.inc for example).
> 
> I this this is a good idea. We could even capture some bugs like in
> some recipes we use EXTRA_OECONF_BASE += and in some EXTRA_OECONF_BASE
> =

Exactly the kind of thing I'd like to catch!

> > Does anyone else fancy helping trying to clean this mess up. I'm happy
> > to review some cleanup patches?
> 
> I plan to do some of this restructuring when I am back from my time
> off in end of april.

Great, any help would be welcome with this kind of thing :)

Cheers

Richard