All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Richards <mark.richards@massmicro.com>
To: openembedded-devel@lists.openembedded.org
Subject: Re: gcc Recipes
Date: Wed, 31 Mar 2010 12:12:16 -0400	[thread overview]
Message-ID: <4BB37460.3000906@massmicro.com> (raw)
In-Reply-To: <1270034881.1681.965.camel@rex>

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





  parent reply	other threads:[~2010-03-31 16:37 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-31 11:28 gcc Recipes Richard Purdie
2010-03-31 11:45 ` Frans Meulenbroeks
2010-03-31 12:10   ` Phil Blundell
2010-03-31 13:00   ` Richard Purdie
2010-03-31 16:12 ` Mark Richards [this message]
2010-03-31 17:25 ` Khem Raj
2010-03-31 20:20   ` Richard Purdie

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4BB37460.3000906@massmicro.com \
    --to=mark.richards@massmicro.com \
    --cc=openembedded-devel@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.