[Buildroot] [v1 1/1] uboot: Add local directory option to menuconfig

[Peter Korsgaard <peter@korsgaard.com>]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

Hi,

 >> I agree that it isn't an obvious feature and that it is easy to miss. As
 >> Yann said, systems like Buildroot are really about reproducability, so
 >> referring to something local on the developers machine doesn't match
 >> very well.

 > This is only if you use Buildroot solely as a "final integration" tool.
 > But lots of people use Buildroot even during active development on a
 > given software component. In such a situation, people are ready to
 > trade "reproducibility" against "ease of building/testing a new
 > change". You certainly don't want to push to your kernel tree a new
 > commit, change your Buildroot configuration, pay the price of a
 > completely new kernel clone + build, to test each and every change you
 > make to your kernel.

You as a local developer might not, but for integration purposes
(E.G. driven through a continous integration tool like
Jenkins/buildbot/..) it becomes very important, especially as teams grow
in size. The fact that we don't track reverse dependencies means that
clean rebuilds are very important, and I would very much argue that this
is a daily thing rather than "final" integration.

People might do their development outside Buildroot (E.G. build by hand)
or use override if they prefer to let Buildroot build it, but finally
the tested changes need to get committed and the buildroot config
adjusted to use the new version.


 > The kernel, U-Boot and other bootloaders are somewhat special
 > components, as you often need HW-specific versions of those. This is
 > why we have the possibility of specifying custom Git versions, custom
 > tarballs, etc. From that perspective, having a way to specify a local
 > directory is also not a bad idea.

But the only advantage of local directory over override (besides
documentation / ease of discovery) is that the change is "permanent"
(E.G. listed in .config). That to me seems like a big disadvantage.


 > To me the _OVERRIDE_SRCDIR / local.mk thing is meant to be _local_ to
 > the developer machine. It's meant to only be used while hacking on a
 > given package, and at the end, produce a patch, or commit your changes.

Indeed, isn't that the use case you describe above?

 > I am not a big fan of suggesting people to version control their
 > local.mk, but maybe it's just a matter of taste (and improper name for
 > this local.mk).

But why would you want to make the development setup override permanent?

-- 
Venlig hilsen,
Peter Korsgaard