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
next prev 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.