[Buildroot] external, how to achieve our needs?

Mircea GLIGA mgliga at bitdefender.com
Wed Feb 26 12:11:36 UTC 2020


Hi Ludovic,

I also have this kind of problems when implementing our external, sometimes is useful to 'override' or append to a recipe (Yocto style).

  *   I ended up "duplicating" recipes in our layer, e.g. bd-tcpdump in order to build the package differently
  *   where it was possible, I manipulated the original package variables, from a .mk file in the external layer: e.g modify the *_CONF_OPTS or *_CONF_ENV for some package

I'm also not that pleased with this 'unofficial' solution.

BR
Mircea
________________________________
From: buildroot <buildroot-bounces at busybox.net> on behalf of Ludovic Desroches <ludovic.desroches at microchip.com>
Sent: Tuesday, February 25, 2020 17:01
To: buildroot at buildroot.org <buildroot at buildroot.org>
Cc: Eugen Hristev <Eugen.Hristev at microchip.com>; Joshua Henderson <Joshua.Henderson at microchip.com>; Nicolas Ferre <Nicolas.Ferre at Microchip.com>; Cristian Birsan <Cristian.Birsan at microchip.com>; Tudor Ambarus <Tudor.Ambarus at microchip.com>
Subject: [Buildroot] external, how to achieve our needs?

Hi,

We are currently using it for linux4sam but it seems it has limitations
and I would like to know if you have advice to share or the same issue.
I did a quick search in the mailing list, I found a discussion with few
answers and patches from Yann for external toolchains, jpeg and openssl.
Unfortunately, it doesn't cover all our use cases.

At the beginning, we forked buildroot in the buildroot-at91 tree. It was
mostly done to put patches we sent upstream. We release a distribution
called linux4sam which contains bootloaders, kernel and rootfs. We can't
wait for the next release of Buildroot to get our patches. It was also
useful to handle additional defconfigs, buildroot bug fixes and sometimes
patches that are not accepted upstream.

When the external feature was released, we thought that it should be better
to rely on Buildroot vanilla and to release only our external. The goal was
to remove the buildroot-at91 fork. At least, it was the plan...

Now, we still have buildroot-at91 + buildroot-external-microchip trees. We
faced several problems which make difficult to only provide an external.

One of the latest issue is we are adding support for a GPU in cairo and
this work is not upstream yet. It involves patching cairo sources
(that's not a big deal) but also to modify cairo.mk to add dependencies and
new configure options. I discussed with Thomas who helped me to achieve it
with some tricks. I added a cairo_microchip package, I had to patch some
libraries to link with this version of cairo and use the external.mk to
force extra dependencies for cairo and pango. Honestly, even if it works,
I am not pleased with the solution. It will be so much easier and cleaner
to do this in buildroot-at91 instead of buildroot-external-microchip. We
discussed again, internally, about the external and the fork of buildroot
but we have different opinions. I would like to emphasize that recent
changes in buildroot make us think that it won't be easy to get rid of
buildroot-at91: devmem2 deprecated, rgnd which increases the boot time
since it uses the lib jitterentropy, curl library name change and others.

My feeling is that the external is not flexible enough to allow us to
remove buildroot-at91. Is it planned to offer a way to modify package
configs and makefiles or is it totally against Buildroot philosophy? I
think this is a strength of the Yocto layers but it's also a weakness as
it becomes difficult to know what is built and how. I also wonder if we can
have one version of the external to support several versions of buildroot
or if we'll need to tag it according to the version of buildroot it has
been tested against. Do we put too much hope in the external?

If I try to summarize our options with their pros and cons:

- buildroot fork:
  - pros:
    - one tree
    - full control, can do whatever we want
  - cons:
    - fork
    - need to rebase patches for new releases
    - may not be able to keep the pace of buildroot releases

- buildroot external:
  - pros:
    - one tree
    - not dependent on buildroot version (in theory) so no rebase to do
  - cons:
    - can't modify buildroot package makefiles, only the source code
    - can't quickly solve bugs in buildroot
    - may have dependency on the buildroot version

- buildroot fork + external:
  - pros:
    - full control, can do whatever we want
    - less patches to rebase (only the ones on top of buildroot)
  - cons:
    - fork
    - two trees
    - may not be able to keep the pace of buildroot releases
    - may have buildroot fork with no patches on top of it sometime


If you have any suggestions, about improvements for Buildroot or the way we
manage our Buildroot offer, I would be happy to hear them.


Regards,

Ludovic
_______________________________________________
buildroot mailing list
buildroot at busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot

________________________
This email was scanned by Bitdefender
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20200226/568519a3/attachment.html>


More information about the buildroot mailing list