From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter Korsgaard Date: Tue, 28 Jun 2016 19:32:24 +0200 Subject: [Buildroot] [v1 1/1] uboot: Add local directory option to menuconfig In-Reply-To: <20160628162417.421cc3cb@free-electrons.com> (Thomas Petazzoni's message of "Tue, 28 Jun 2016 16:24:17 +0200") References: <1466994356-15411-1-git-send-email-Aduskett@gmail.com> <20160627205746.GC3714@free.fr> <87por1q1ps.fsf@dell.be.48ers.dk> <20160628162417.421cc3cb@free-electrons.com> Message-ID: <87lh1pmd7b.fsf@dell.be.48ers.dk> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: buildroot@busybox.net >>>>> "Thomas" == Thomas Petazzoni 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