[Buildroot] [PATCH 00/13] Add support for a project directory
Thomas Petazzoni
thomas.petazzoni at free-electrons.com
Sun Oct 14 12:55:39 UTC 2012
Arnout,
On Sun, 14 Oct 2012 12:43:14 +0200, Arnout Vandecappelle wrote:
> > All what this stuff is adding can already be done with the current
> > Buildroot, by putting the configuration files in a board/something/foo
> > directory, and adjusting the Buildroot configuration.
>
> It doesn't even have to be in a board/something/foo directory, it can
> easily be out of tree. The only problem is that you have to write down
> a fairly long path for each of the relevant config options.
Come on, it's just something like:
$(TOPDIR)/../myproject/linux.config
> > It just adds a
> > useless layer with a fuzzy concept of "project" that we had in the
> > past, and was a terrible idea.
>
> That it didn't work in the past doesn't mean it's a terrible idea :-)
Except that what you're proposing is almost exactly what we had at the
time, so to me it sounds like the same terrible idea :)
> > Moreover, the introduction text states that "Many buildroot users
> > prefer to keep their project's customizations separate from buildroot
> > itself", but the patch set doesn't solve this problem at all:
>
> It's not a "problem", because it is already possible now - I've done
> it for my last four buildroot projects (without any modification to
> stock buildroot), and I find it _much_ more convenient than before to
> upgrade buildroot - particularly if I just want to test that particular
> project against current master. But the main advantage is that you can
> nicely separate the things which are proprietary from the things that
> are potentially upstreamable (because those are still applied in the
> buildroot tree itself).
I still don't get what this patch set adds that you can't do with the
existing Buildroot infrastructure.
> > * Custom packages are not taken into account
>
> In $(PROJECT_DIR)/project.mk, add:
>
> BR2_PACKAGE_FOO=y
> include package/foo/foo.mk
Then you can just use the "local.mk" mechanism similarly, it already
exists.
> > * Additional patches added to existing packages are not taken into
> > account
>
> You can add a post-patch hook in project.mk. It's a bit more involved,
> that's why I propose to automate that in the package infrastructure.
> But I haven't needed that up to now so I don't have a solution ready,
> and I'm not going to spend time on it if it will be NAK'd anyway :-)
>
> For the things that do frequently need patches (linux, u-boot, ...)
> we already have config options, so we could just add PROJECT_DIR-based
> defaults for those as well.
I really would prefer to _document_ how to properly use the existing
Buildroot infrastructure to cleanly separate custom stuff from
Buildroot, rather than introducing more mechanisms on top of it.
> > * Modification to the recipes of existing packages are not taken into
> > account. And it is very common for a project that you need to
> > slightly upgrade or adjust the recipe of a few existing packages.
>
> Indeed. Those changes should still go in the buildroot tree itself.
And those are the most annoying ones to maintain and upgrade when you
want to upgrade to a new Buildroot version. So basically, it seems to
me like your patch set solves problems that are already solved
(specifying a custom location of kernel config, uClibc config, kernel
patches, U-Boot patches, etc.), while it doesn't solve any of the real
problems that aren't solved today.
> > So even with this additional complexity,
>
> Complexity? The diffstat of patches 1-7 is:
> 8 files changed, 30 insertions(+), 2 deletions(-)
>
> The ones after that are more involved, I agree.
It's not a question of diffstat. It's a question of "is this mechanism
easy to grasp for newcomers and can it be immediately understood" and
"does this mechanism adds any value over what Buildroot already
provides"?
> > the most annoying problems are
> > not solved. So I really do prefer to keep things as it is: people have
> > to use version control systems to keep their changes cleanly separated
> > from the base Buildroot version.
>
> Version control doesn't really solve it, in my experience.
Why so?
> >A half-working solution is not going
> > to help our users to understand how to properly use Buildroot.
> >
> > If we want to really separate the project specificities, then we need
> > to introduce a real concept of "layers" like OpenEmbedded has, which
> > allows to also override package recipes, add new custom packages, etc.
> > But I am not sure we want to go down this road.
>
> I'm pretty sure we don't want to go down that road. I don't believe
> the possibility of overriding package recipes is warranted. I also
> don't think it's very useful in our context to have several layers.
> The only thing I want is to keep the customizations (i.e. configuration,
> skeleton, etc.) in a separate directory tree from buildroot.
And this is all already possible:
BR2_ROOTFS_SKELETON_CUSTOM=y
BR2_ROOTFS_SKELETON_CUSTOM_PATH="$(TOPDIR)/../foo"
BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG=y
BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="$(TOPDIR)/../kernel.config"
etc, etc.
So, sorry, but still not convinced. But I'm not the only Buildroot
developer and user, and I'm not the maintainer. So my voice is just one
amongst many others.
Best regards,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
More information about the buildroot
mailing list