All of lore.kernel.org
 help / color / mirror / Atom feed
* [Buildroot] switching hardware-specific parts of .config?
@ 2019-09-23 15:45 Hollis Blanchard
  2019-09-24  0:03 ` Christian Stewart
  0 siblings, 1 reply; 2+ messages in thread
From: Hollis Blanchard @ 2019-09-23 15:45 UTC (permalink / raw)
  To: buildroot

I have a .config that currently targets a particular architecture/board. 
What's the best way to switch just the hardware parts of it to target a 
different board from a different architecture, leaving options like 
package selection or rootfs format unaffected?

I imagine I could:

  * Maintain two separate config files. This would require me to
    remember that when I change e.g. package selection in one, I need to
    make the corresponding change in the other.
  * Maintain three config file fragments (2x hardware, 1x "other"). When
    I make changes, this would require me to manually split the ultimate
    .config back in to hardware and "other" fragments.
  * Create a tool to rewrite the single .config, e.g. replacing options
    like BR2_arm=y. This would require the rewriting tool to know the
    full set of options it needs to replace. I already do essentially
    this with toolchain options (so you can point at a different
    toolchain and have your config rewritten to match), so it's not
    crazy... but it might not be as easy as with BR2_TOOLCHAIN_*.

Any recommendations? Thanks!

-- 
Hollis Blanchard
Mentor Graphics Emulation Division

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20190923/8930b446/attachment.html>

^ permalink raw reply	[flat|nested] 2+ messages in thread

* [Buildroot] switching hardware-specific parts of .config?
  2019-09-23 15:45 [Buildroot] switching hardware-specific parts of .config? Hollis Blanchard
@ 2019-09-24  0:03 ` Christian Stewart
  0 siblings, 0 replies; 2+ messages in thread
From: Christian Stewart @ 2019-09-24  0:03 UTC (permalink / raw)
  To: buildroot

Hi Hollis,


On Mon, Sep 23, 2019, 8:53 AM Hollis Blanchard <hollis_blanchard@mentor.com>
wrote:

> I have a .config that currently targets a particular architecture/board.
> What's the best way to switch just the hardware parts of it to target a
> different board from a different architecture, leaving options like package
> selection or rootfs format unaffected?
>
> I imagine I could:
>
>    - Maintain two separate config files. This would require me to
>    remember that when I change e.g. package selection in one, I need to make
>    the corresponding change in the other.
>    - Maintain three config file fragments (2x hardware, 1x "other"). When
>    I make changes, this would require me to manually split the ultimate
>    .config back in to hardware and "other" fragments.
>    - Create a tool to rewrite the single .config, e.g. replacing options
>    like BR2_arm=y. This would require the rewriting tool to know the full set
>    of options it needs to replace. I already do essentially this with
>    toolchain options (so you can point at a different toolchain and have your
>    config rewritten to match), so it's not crazy... but it might not be as
>    easy as with BR2_TOOLCHAIN_*.
>
>
I did this with https://github.com/paralin/skiffos which wraps buildroot
with some scripts to combine device specific config fragments / layers /
patches together.

I've collected a small group of users and we are working on porting +
testing new boards.

Best regards,
Christian Stewart
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20190923/0655db78/attachment.html>

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2019-09-24  0:03 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-09-23 15:45 [Buildroot] switching hardware-specific parts of .config? Hollis Blanchard
2019-09-24  0:03 ` Christian Stewart

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.