* slight different confirurations for a package
@ 2009-09-16 17:25 C Michael Sundius
2009-09-17 2:01 ` Philip Balister
2009-09-17 3:46 ` Denys Dmytriyenko
0 siblings, 2 replies; 3+ messages in thread
From: C Michael Sundius @ 2009-09-16 17:25 UTC (permalink / raw)
To: openembedded-devel
I'd like to be able to build several different configurations of the same
package and I'm wondering if the community might have some good input on the
best way to organize this. My project has several images that are built for
various products and customers and hardware. Generally all of the software
is the same save a few key packages. (really even the kernel is constant
across all platforms). and right now I have a different disto.conf file that
corresponds to an image recipe for each platform.
I want to be able to build all of the platforms together within the same out
dir. (so I don't have to rebuild the bulk of the software wasting disk space
and time).
I've thought about defining separate recipes:
(foo-config1.bb, foo-config2.bb)
or simply using a variable to define ${PN} from within the recipe:
PN = ${DISTRO_CONFIG}
I suppose these could work, but I'm wondering if I can create a whole new
directory under work and staging like when I set PACKAGE_ARCH =
${MACHINE_ARCH} for the kernel and drivers.
as I said, right now I have a separate distro/*.conf file for each image
(and thus configuration) I build, really the difference between these is the
configuration of just a few packages all other software is built w/ the same
recipe and configs. Is there a way anyone can think of to consolidate these
so I can build everything without
changing the local.conf (DISTRO variable).
I realize this is a nebulous question, but if anyone has an experience
similar where they have had to organize various builds and found a clean or
better way to build them all for both development and production or you have
some opinions about how you made your decisions to do things one way or
another , I'd love to hear your comments.
Thank you
Mike
^ permalink raw reply [flat|nested] 3+ messages in thread* Re: slight different confirurations for a package
2009-09-16 17:25 slight different confirurations for a package C Michael Sundius
@ 2009-09-17 2:01 ` Philip Balister
2009-09-17 3:46 ` Denys Dmytriyenko
1 sibling, 0 replies; 3+ messages in thread
From: Philip Balister @ 2009-09-17 2:01 UTC (permalink / raw)
To: openembedded-devel
[-- Attachment #1: Type: text/plain, Size: 2379 bytes --]
C Michael Sundius wrote:
> I'd like to be able to build several different configurations of the same
> package and I'm wondering if the community might have some good input on the
> best way to organize this. My project has several images that are built for
> various products and customers and hardware. Generally all of the software
> is the same save a few key packages. (really even the kernel is constant
> across all platforms). and right now I have a different disto.conf file that
> corresponds to an image recipe for each platform.
>
> I want to be able to build all of the platforms together within the same out
> dir. (so I don't have to rebuild the bulk of the software wasting disk space
> and time).
>
> I've thought about defining separate recipes:
> (foo-config1.bb, foo-config2.bb)
> or simply using a variable to define ${PN} from within the recipe:
>
> PN = ${DISTRO_CONFIG}
>
> I suppose these could work, but I'm wondering if I can create a whole new
> directory under work and staging like when I set PACKAGE_ARCH =
> ${MACHINE_ARCH} for the kernel and drivers.
>
> as I said, right now I have a separate distro/*.conf file for each image
> (and thus configuration) I build, really the difference between these is the
> configuration of just a few packages all other software is built w/ the same
> recipe and configs. Is there a way anyone can think of to consolidate these
> so I can build everything without
> changing the local.conf (DISTRO variable).
It seems like you are misunderstanding how to use DISTRO. Basically, set
the common stuff in DISTRO and creat an image.bb file for each image you
need.
In short, if you are creating a new distro/*.conf you are most likely
making a mistake :)
Philip
>
> I realize this is a nebulous question, but if anyone has an experience
> similar where they have had to organize various builds and found a clean or
> better way to build them all for both development and production or you have
> some opinions about how you made your decisions to do things one way or
> another , I'd love to hear your comments.
>
> Thank you
> Mike
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3303 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread* Re: slight different confirurations for a package
2009-09-16 17:25 slight different confirurations for a package C Michael Sundius
2009-09-17 2:01 ` Philip Balister
@ 2009-09-17 3:46 ` Denys Dmytriyenko
1 sibling, 0 replies; 3+ messages in thread
From: Denys Dmytriyenko @ 2009-09-17 3:46 UTC (permalink / raw)
To: openembedded-devel
On Wed, Sep 16, 2009 at 10:25:17AM -0700, C Michael Sundius wrote:
> I'd like to be able to build several different configurations of the same
> package and I'm wondering if the community might have some good input on the
> best way to organize this. My project has several images that are built for
> various products and customers and hardware. Generally all of the software
> is the same save a few key packages. (really even the kernel is constant
> across all platforms). and right now I have a different disto.conf file that
> corresponds to an image recipe for each platform.
>
> I want to be able to build all of the platforms together within the same out
> dir. (so I don't have to rebuild the bulk of the software wasting disk space
> and time).
>
> I've thought about defining separate recipes:
> (foo-config1.bb, foo-config2.bb)
Quick and dirty: If you use the same distro, but have separate recipes
(foo-config1.bb and foo-config2.bb), you can place them under separate
tasks/images (image1.bb and image2.bb) and build both images. All the
packages, except foo-* and image1/2 will be shared and built only once, so no
wasting of disk space and time.
> or simply using a variable to define ${PN} from within the recipe:
>
> PN = ${DISTRO_CONFIG}
>
> I suppose these could work, but I'm wondering if I can create a whole new
> directory under work and staging like when I set PACKAGE_ARCH =
> ${MACHINE_ARCH} for the kernel and drivers.
>
> as I said, right now I have a separate distro/*.conf file for each image
> (and thus configuration) I build, really the difference between these is the
> configuration of just a few packages all other software is built w/ the same
> recipe and configs. Is there a way anyone can think of to consolidate these
> so I can build everything without
> changing the local.conf (DISTRO variable).
>
> I realize this is a nebulous question, but if anyone has an experience
> similar where they have had to organize various builds and found a clean or
> better way to build them all for both development and production or you have
> some opinions about how you made your decisions to do things one way or
> another , I'd love to hear your comments.
>
> Thank you
> Mike
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2009-09-17 3:47 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-09-16 17:25 slight different confirurations for a package C Michael Sundius
2009-09-17 2:01 ` Philip Balister
2009-09-17 3:46 ` Denys Dmytriyenko
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.