From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Petazzoni Date: Thu, 12 May 2016 16:02:26 +0200 Subject: [Buildroot] [PATCH 1/1] Makefile: Support merged defconfigs In-Reply-To: <90639972664ebd51802b3c2b94b8c01e235bd956.1462771329.git.sam.bobroff@au1.ibm.com> References: <90639972664ebd51802b3c2b94b8c01e235bd956.1462771329.git.sam.bobroff@au1.ibm.com> Message-ID: <20160512160226.62bb28bd@free-electrons.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: buildroot@busybox.net Hello, On Mon, 9 May 2016 15:22:32 +1000, Sam Bobroff wrote: > Within the Linux kernel, and several other packages, it's currently > possible to maintain defconfigs as diffs (fragments) against other > configs but this is not possible with buildroot itself. > > This patch adds the capability, although using a slightly different > implementation. Files may be added in the normal config directories > ($TOPDIR/configs or $BR2_EXTERNAL/configs) with the format > "xxx_defconfig.merge" that contain, one per line, the files to be > passed to merge_config.sh to create the matching xxx_defconfig file > (the first line should contain the base config followed by the > fragments). The generated defconfig file is then handled as it would > normally be. > > Signed-off-by: Sam Bobroff Warning: the below is definitely not a final opinion or decision. It is merely the start of a discussion. I do like the usage of fragments. Your Github link at https://github.com/open-power/op-build/issues/457 even points to Buildroot training materials that I wrote, which explains how to use fragments. However, I am not sure whether we want in Buildroot a mechanism to build a defconfig from fragments. To me, Buildroot should remain a simple tool that takes as input a complete configuration, and generates a Linux system from it. Whether this "complete configuration" comes from a full .config, a minimal defconfig, a defconfig generated from fragments, a defconfig generated by a separate tool, by a webpage, or anything else, is not Buildroot's matter. Buildroot's job starts when the configuration is ready. Essentially, the part that's missing in your commit is the update to the documentation. And when you'll start updating the manual to explain how this feature is working, you'll probably see that it's a bit tricky to explain. So, I'm definitely not saying "no" to this, but my belief is that it's on the edges of Buildroot features. On the one hand, it brings a well-defined and correct way of storing fragments and generated a defconfig from fragments, that everyone can use and rely on. On the other hand, it adds one more slightly "tricky" feature to Buildroot, increasing its learning curve. For a customer project, Gustavo has written a "genconfig" shell script, that takes as input various parameters that define the system to be built (which HW platform, which software stack, whether it should be a debug or release build) and produces the defconfig for Buildroot. What do others think? Thanks! Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com