[Buildroot] Suggestion for Makefile to probably import BR2_CONFIG

[Buildroot] Suggestion for Makefile to probably import BR2_CONFIG

[Toan Pham]

Hi,

I would like to make a suggestion on patching the main Makefile line:

BR2_CONFIG = $(CONFIG_DIR)/.config

to

BR2_CONFIG ?= $(CONFIG_DIR)/.config


The main reason for this patch is that it allows the configuration file to
be specified from command argument.  For example, I would be able to build
two different targets (even in parallel) with the following commands:


make BR2_CONFIG=$PWD/myTarget1 O=output.target1

make BR2_CONFIG=$PWD/myTarget2 O=output.target2


Without the above patch, buildroot assumes that the config file is already
saved under output.target{1,2}/.config and would fail if the file does not
exist.  I find that the above patch is very valuable, please comment or
make suggestion!


thank you,

TP
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20180117/54ca3a3e/attachment.html>

[Buildroot] Suggestion for Makefile to probably import BR2_CONFIG

[Toan Pham]

ping

On Jan 17, 2018 5:06 PM, "Toan Pham" <tpham3783@gmail.com> wrote:

>
>
> Hi,
>
> I would like to make a suggestion on patching the main Makefile line:
>
> BR2_CONFIG = $(CONFIG_DIR)/.config
>
> to
>
> BR2_CONFIG ?= $(CONFIG_DIR)/.config
>
>
> The main reason for this patch is that it allows the configuration file to
> be specified from command argument.  For example, I would be able to build
> two different targets (even in parallel) with the following commands:
>
>
> make BR2_CONFIG=$PWD/myTarget1 O=output.target1
>
> make BR2_CONFIG=$PWD/myTarget2 O=output.target2
>
>
> Without the above patch, buildroot assumes that the config file is already
> saved under output.target{1,2}/.config and would fail if the file does not
> exist.  I find that the above patch is very valuable, please comment or
> make suggestion!
>
>
> thank you,
>
> TP
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20180119/bfff24f9/attachment.html>

[Buildroot] Suggestion for Makefile to probably import BR2_CONFIG

[Arnout Vandecappelle]

 Hi TP,

 Thank you for your suggestion!


On 17-01-18 23:06, Toan Pham wrote:
> 
> 
> Hi,
> 
> I would like to make a suggestion on patching the main Makefile line:?
> 
> BR2_CONFIG = $(CONFIG_DIR)/.config??
> 
> to
> 
> BR2_CONFIG ?= $(CONFIG_DIR)/.config
> 
> 
> The main reason for this patch is that it allows the configuration file to be
> specified from command argument.? For example, I would be able to build two
> different targets (even in parallel) with the following commands:
> 
> 
> make BR2_CONFIG=$PWD/myTarget1 O=output.target1
> 
> make BR2_CONFIG=$PWD/myTarget2 O=output.target2
>
>
> Without the above patch, buildroot assumes that the config file is already saved
> under output.target{1,2}/.config and would fail if the file does not exist.? I
> find that the above patch is very valuable, please comment or make suggestion!

 The .config file is a generated file. In fact, it will sometimes be overwritten
when you start a build. The .config files also contains information about your
build environment. So no, it really isn't a good idea to do this.

 If you have an existing defconfig file (normally generated with 'make
savedefconfig', but you can also just copy the .config file), you can use it as
the source of the generated .config as follows:

make BR2_DEFCONFIG=$PWD/myTarget1 O=output.target1
make O=output.target1


 Regards,
 Arnout


-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] Suggestion for Makefile to probably import BR2_CONFIG

[Toan Pham]

Thank you for the clarification.  BR2_CONFIG is a run-time generated config
and that it shouldn't be used.  One should use BR2_DEFCONFIG instead to
guarantee reproducible builds on different hosts.

Based on what you pointed out, BR2_CONFIG is more like a cached file of the
build environment.  If I were to follow your methods described here:

make BR2_DEFCONFIG=$PWD/myTarget1 O=output.target1
make O=output.target1

It wont work if output.target1 hasn't been configured with make
{oldconfig,menuconfig,xconfig}.  ie error from BR2:

  GEN     /projects/sandbox/ups/buildroot/output.test/Makefile
> ***
> *** Configuration file
> "/projects/sandbox/ups/buildroot/output.test/.config" not found!
> ***
> *** Please run some configurator (e.g. "make oldconfig" or
> *** "make menuconfig" or "make xconfig").
>



Note that 'make silentoldconfig' isn't even an option.  It would be nice
for BR2 to have a 'silentoldconfig' target so that the config file gets
generated automatically, without any user intervention on first run.  Also,
having the ability to override BR2_CONFIG is also nice (for those who know
what they're doing).

TP













On Mon, Jan 22, 2018 at 4:45 PM, Arnout Vandecappelle <arnout@mind.be>
wrote:

>  Hi TP,
>
>  Thank you for your suggestion!
>
>
> On 17-01-18 23:06, Toan Pham wrote:
> >
> >
> > Hi,
> >
> > I would like to make a suggestion on patching the main Makefile line:
> >
> > BR2_CONFIG = $(CONFIG_DIR)/.config
> >
> > to
> >
> > BR2_CONFIG ?= $(CONFIG_DIR)/.config
> >
> >
> > The main reason for this patch is that it allows the configuration file
> to be
> > specified from command argument.  For example, I would be able to build
> two
> > different targets (even in parallel) with the following commands:
> >
> >
> > make BR2_CONFIG=$PWD/myTarget1 O=output.target1
> >
> > make BR2_CONFIG=$PWD/myTarget2 O=output.target2
> >
> >
> > Without the above patch, buildroot assumes that the config file is
> already saved
> > under output.target{1,2}/.config and would fail if the file does not
> exist.  I
> > find that the above patch is very valuable, please comment or make
> suggestion!
>
>  The .config file is a generated file. In fact, it will sometimes be
> overwritten
> when you start a build. The .config files also contains information about
> your
> build environment. So no, it really isn't a good idea to do this.
>
>  If you have an existing defconfig file (normally generated with 'make
> savedefconfig', but you can also just copy the .config file), you can use
> it as
> the source of the generated .config as follows:
>
> make BR2_DEFCONFIG=$PWD/myTarget1 O=output.target1
> make O=output.target1
>
>
>  Regards,
>  Arnout
>
>
> --
> Arnout Vandecappelle                          arnout at mind be
> Senior Embedded Software Architect            +32-16-286500
> Essensium/Mind                                http://www.mind.be
> G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
> LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
> GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20180122/0881fd5c/attachment.html>

[Buildroot] Suggestion for Makefile to probably import BR2_CONFIG

[Arnout Vandecappelle]

 Hi TP,

 [Please don't top-post, but reply inline like I do below.]

On 23-01-18 00:00, Toan Pham wrote:
> Thank you for the clarification.? BR2_CONFIG is a run-time generated config and
> that it shouldn't be used.? One should use BR2_DEFCONFIG instead to guarantee
> reproducible builds on different hosts.
> 
> Based on what you pointed out, BR2_CONFIG is more like a cached file of the
> build environment.? If I were to follow your methods described here:
> 
>     make BR2_DEFCONFIG=$PWD/myTarget1 O=output.target1

 Sorry, my bad, this should have been

make BR2_DEFCONFIG=$PWD/myTarget1 O=output.target1 defconfig

>     make O=output.target1
> 
> It wont work if output.target1 hasn't been configured with make
> {oldconfig,menuconfig,xconfig}.? ie error from BR2:
> 
>     ? GEN???? /projects/sandbox/ups/buildroot/output.test/Makefile
>     ***
>     *** Configuration file "/projects/sandbox/ups/buildroot/output.test/.config"
>     not found!
>     ***
>     *** Please run some configurator (e.g. "make oldconfig" or
>     *** "make menuconfig" or "make xconfig").
> 
> 
> 
> 
> Note that 'make silentoldconfig' isn't even an option.? It would be nice for BR2
> to have a 'silentoldconfig' target so that the config file gets generated
> automatically, without any user intervention on first run.? Also, having the
> ability to override BR2_CONFIG is also nice (for those who know what they're doing).

 Well, if you really know what you are doing, then you also know that you can in
fact override BR2_CONFIG :-). In fact, the commandline you give in your original
mail *will* work. Any assignment specified on the make commandline (after
'make') overrides the assignments done within the Makefiles.

 Regards,
 Arnout

> 
> TP
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> On Mon, Jan 22, 2018 at 4:45 PM, Arnout Vandecappelle <arnout@mind.be
> <mailto:arnout@mind.be>> wrote:
> 
>     ?Hi TP,
> 
>     ?Thank you for your suggestion!
> 
> 
>     On 17-01-18 23:06, Toan Pham wrote:
>     >
>     >
>     > Hi,
>     >
>     > I would like to make a suggestion on patching the main Makefile line:?
>     >
>     > BR2_CONFIG = $(CONFIG_DIR)/.config??
>     >
>     > to
>     >
>     > BR2_CONFIG ?= $(CONFIG_DIR)/.config
>     >
>     >
>     > The main reason for this patch is that it allows the configuration file to be
>     > specified from command argument.? For example, I would be able to build two
>     > different targets (even in parallel) with the following commands:
>     >
>     >
>     > make BR2_CONFIG=$PWD/myTarget1 O=output.target1
>     >
>     > make BR2_CONFIG=$PWD/myTarget2 O=output.target2
>     >
>     >
>     > Without the above patch, buildroot assumes that the config file is already saved
>     > under output.target{1,2}/.config and would fail if the file does not exist.? I
>     > find that the above patch is very valuable, please comment or make suggestion!
> 
>     ?The .config file is a generated file. In fact, it will sometimes be overwritten
>     when you start a build. The .config files also contains information about your
>     build environment. So no, it really isn't a good idea to do this.
> 
>     ?If you have an existing defconfig file (normally generated with 'make
>     savedefconfig', but you can also just copy the .config file), you can use it as
>     the source of the generated .config as follows:
> 
>     make BR2_DEFCONFIG=$PWD/myTarget1 O=output.target1
>     make O=output.target1
> 
> 
>     ?Regards,
>     ?Arnout
> 
> 
>     --
>     Arnout Vandecappelle? ? ? ? ? ? ? ? ? ? ? ? ? arnout at mind be
>     Senior Embedded Software Architect? ? ? ? ? ? +32-16-286500
>     <tel:%2B32-16-286500>
>     Essensium/Mind? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? http://www.mind.be
>     G.Geenslaan 9, 3001 Leuven, Belgium? ? ? ? ? ?BE 872 984 063 RPR Leuven
>     LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
>     <http://www.linkedin.com/in/arnoutvandecappelle>
>     GPG fingerprint:? 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
> 
> 

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] Suggestion for Makefile to probably import BR2_CONFIG

[Toan Pham]

>
>  Well, if you really know what you are doing, then you also know that you
> can in
> fact override BR2_CONFIG :-).


Yes, but it wont work if the build is out of branch (O is defined) along
with BR2_CONFIG.  Please try it out!



> In fact, the commandline you give in your original
> mail *will* work. Any assignment specified on the make commandline (after
> 'make') overrides the assignments done within the Makefiles.
>


Yes, except that it doesn't work because  BR2 would print the error
described in the first email.  I just found the proper patch to fix that
error (see below patch).  The reason why we got the error because buildroot
called submake target silentoldconfig without passing along the BR2_CONFIG
we intended to use.  One way to fix that is to pass -e option to submake
but it is a bad practice to use environment variable overload.  A better
way is to pass along BR2_CONFIG, otherwise submake would evaluate
BR2_CONFIG as $(CONFIG_DIR)/.config as oppose to the path given from
command line argument.  Please review it and let me know.


Thanks for the feedback,

TP




diff --git a/Makefile b/Makefile
index 7d8ab51..4b12359 100644
--- a/Makefile
+++ b/Makefile
 # Pull in the user's configuration file
@@ -547,7 +550,7 @@ dirs: $(BUILD_DIR) $(STAGING_DIR) $(TARGET_DIR) \
        $(HOST_DIR) $(HOST_DIR)/usr $(HOST_DIR)/lib $(BINARIES_DIR)

 $(BUILD_DIR)/buildroot-config/auto.conf: $(BR2_CONFIG)
-       $(MAKE1) $(EXTRAMAKEARGS) HOSTCC="$(HOSTCC_NOCCACHE)"
HOSTCXX="$(HOSTCXX_NOCCACHE)" silentoldconfig
+       $(MAKE1) BR2_CONFIG=$(BR2_CONFIG) $(EXTRAMAKEARGS)
HOSTCC="$(HOSTCC_NOCCACHE)" HOSTCXX="$(HOSTCXX_NOCCACHE)" silentoldconfig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20180123/f5b9838d/attachment.html>

[Buildroot] Suggestion for Makefile to probably import BR2_CONFIG

[Toan Pham]

ping!
?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20180126/3a46f3b8/attachment.html>

[Buildroot] Suggestion for Makefile to probably import BR2_CONFIG

[Arnout Vandecappelle]

 [Adding some core developers in Cc since this includes an infrastructural
change proposal.]

On 23-01-18 19:28, Toan Pham wrote:
> 
> 
>     ?Well, if you really know what you are doing, then you also know that you can in
>     fact override BR2_CONFIG :-). 
> 
> 
> Yes, but it wont work if the build is out of branch (O is defined) along with
> BR2_CONFIG.? Please try it out!?
> 
> ?
> 
>     In fact, the commandline you give in your original
>     mail *will* work. Any assignment specified on the make commandline (after
>     'make') overrides the assignments done within the Makefiles.
> 
> 
> 
> Yes, except that it doesn't work because? BR2 would print the error described in
> the first email.? I just found the proper patch to fix that error (see below
> patch).? The reason why we got the error because buildroot called submake target
> silentoldconfig without passing along the BR2_CONFIG we intended to use.? One
> way to fix that is to pass -e option to submake but it is a bad practice to use
> environment variable overload.? A better way is to pass along BR2_CONFIG,
> otherwise submake would evaluate BR2_CONFIG as $(CONFIG_DIR)/.config as oppose
> to the path given from command line argument.? Please review it and let me know.??
> 
> 
> Thanks for the feedback,
> 
> TP
> 
> 
> ?
> 
> diff --git a/Makefile b/Makefile
> index 7d8ab51..4b12359 100644
> --- a/Makefile
> +++ b/Makefile
> ?# Pull in the user's configuration file
> @@ -547,7 +550,7 @@ dirs: $(BUILD_DIR) $(STAGING_DIR) $(TARGET_DIR) \
> ??????? $(HOST_DIR) $(HOST_DIR)/usr $(HOST_DIR)/lib $(BINARIES_DIR)
> ?
> ?$(BUILD_DIR)/buildroot-config/auto.conf: $(BR2_CONFIG)
> -?????? $(MAKE1) $(EXTRAMAKEARGS) HOSTCC="$(HOSTCC_NOCCACHE)"
> HOSTCXX="$(HOSTCXX_NOCCACHE)" silentoldconfig
> +?????? $(MAKE1) BR2_CONFIG=$(BR2_CONFIG) $(EXTRAMAKEARGS)
> HOSTCC="$(HOSTCC_NOCCACHE)" HOSTCXX="$(HOSTCXX_NOCCACHE)" silentoldconfig

 It would indeed make sense to pass all options pertaining to Kconfig explicitly
to the silentoldconfig call.

 However, I wonder if it wouldn't be better to remove this auto.conf handling
entirely. It is supposed to make sure that silendoldconfig gets run whenever
something changed in Config.in files. But for that to work, we need to actually
include the auto.conf file in the Makefile. Looking at what's done in the
kernel, it seems there would be a lot more changes needed to get this right. And
even then, I think there's still a risk to not get things fully right - e.g.
changes in the host environment will not be detected.

 The only commit pertaining to this auto.conf dependency that I could find is
commit 0b36880085f0c65286877853caccf0bde2dd7f0b, from 2010. Quoting its commit
message:

    The previous commit has removed calls to conf_write_autoconf(), which
    is the function that generates the KCONFIG_AUTOCONF,
    KCONFIG_AUTOHEADER, KCONFIG_TRISTATE files and the split config (with
    one file per config item). Therefore, those things were not generated
    anymore before the build.

    In order to get them generated before the build, we use the same
    mechanism as the kernel: run a silentoldconfig when the .config file
    is newer than the KCONFIG_AUTOCONF file.

    In Buildroot, all those elements are not really used today, except the
    split config which is used a little bit in the toolchain build, in a
    try to make sure the toolchain gets rebuilt properly when the
    configuration changes. It does not seem that this work has been
    completed.

    However, as we want to keep the same behaviour as previously, we have
    to generate all those elements before starting the build.

 So basically, the only reason to have this is to make sure this split config is
generated, but we don't use any of it anymore.


 Yann, Thomas, Peter, what do you think?

 Regards,
 Arnout

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] Suggestion for Makefile to probably import BR2_CONFIG

[Thomas Petazzoni]

Hello,

On Sun, 28 Jan 2018 23:30:34 +0100, Arnout Vandecappelle wrote:

> > diff --git a/Makefile b/Makefile
> > index 7d8ab51..4b12359 100644
> > --- a/Makefile
> > +++ b/Makefile
> > ?# Pull in the user's configuration file
> > @@ -547,7 +550,7 @@ dirs: $(BUILD_DIR) $(STAGING_DIR) $(TARGET_DIR) \
> > ??????? $(HOST_DIR) $(HOST_DIR)/usr $(HOST_DIR)/lib $(BINARIES_DIR)
> > ?
> > ?$(BUILD_DIR)/buildroot-config/auto.conf: $(BR2_CONFIG)
> > -?????? $(MAKE1) $(EXTRAMAKEARGS) HOSTCC="$(HOSTCC_NOCCACHE)"
> > HOSTCXX="$(HOSTCXX_NOCCACHE)" silentoldconfig
> > +?????? $(MAKE1) BR2_CONFIG=$(BR2_CONFIG) $(EXTRAMAKEARGS)
> > HOSTCC="$(HOSTCC_NOCCACHE)" HOSTCXX="$(HOSTCXX_NOCCACHE)" silentoldconfig  
> 
>  It would indeed make sense to pass all options pertaining to Kconfig explicitly
> to the silentoldconfig call.
> 
>  However, I wonder if it wouldn't be better to remove this auto.conf handling
> entirely. It is supposed to make sure that silendoldconfig gets run whenever
> something changed in Config.in files. But for that to work, we need to actually
> include the auto.conf file in the Makefile. Looking at what's done in the
> kernel, it seems there would be a lot more changes needed to get this right. And
> even then, I think there's still a risk to not get things fully right - e.g.
> changes in the host environment will not be detected.
> 
>  The only commit pertaining to this auto.conf dependency that I could find is
> commit 0b36880085f0c65286877853caccf0bde2dd7f0b, from 2010. Quoting its commit
> message:
> 
>     The previous commit has removed calls to conf_write_autoconf(), which
>     is the function that generates the KCONFIG_AUTOCONF,
>     KCONFIG_AUTOHEADER, KCONFIG_TRISTATE files and the split config (with
>     one file per config item). Therefore, those things were not generated
>     anymore before the build.
> 
>     In order to get them generated before the build, we use the same
>     mechanism as the kernel: run a silentoldconfig when the .config file
>     is newer than the KCONFIG_AUTOCONF file.
> 
>     In Buildroot, all those elements are not really used today, except the
>     split config which is used a little bit in the toolchain build, in a
>     try to make sure the toolchain gets rebuilt properly when the
>     configuration changes. It does not seem that this work has been
>     completed.
> 
>     However, as we want to keep the same behaviour as previously, we have
>     to generate all those elements before starting the build.
> 
>  So basically, the only reason to have this is to make sure this split config is
> generated, but we don't use any of it anymore.
> 
> 
>  Yann, Thomas, Peter, what do you think?

I haven't followed the entire discussion, so maybe I'll be out of topic
here. But indeed I believe the split config is completely unused
nowadays, and could be removed entirely.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[Buildroot] Suggestion for Makefile to probably import BR2_CONFIG

[Peter Korsgaard]

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

Hi,
 >> Yann, Thomas, Peter, what do you think?

 > I haven't followed the entire discussion, so maybe I'll be out of topic
 > here. But indeed I believe the split config is completely unused
 > nowadays, and could be removed entirely.

Agreed!

-- 
Bye, Peter Korsgaard

[Buildroot] Suggestion for Makefile to probably import BR2_CONFIG

[Yann E. MORIN]

All,

On 2018-01-29 09:28 +0100, Peter Korsgaard spake thusly:
> >>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
>  >> Yann, Thomas, Peter, what do you think?
> 
>  > I haven't followed the entire discussion, so maybe I'll be out of topic
>  > here. But indeed I believe the split config is completely unused
>  > nowadays, and could be removed entirely.
> 
> Agreed!

Seconded.

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] Suggestion for Makefile to probably import BR2_CONFIG

[Toan Pham]

>  >> Yann, Thomas, Peter, what do you think?
>
>
Arnout,

Thank you for the detailed explanation as to why "auto.conf" was needed.
Please apply appropriate patches to remove the split config so that we can
have a more intuitive build system.  In the meantime, I'll stick with using
the supplied patch, which was passing BR2_CONFIG to silentoldconfig target.

TP
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20180207/97ef7496/attachment.html>

[Buildroot] Suggestion for Makefile to probably import BR2_CONFIG

[Toan Pham]

>
>  If you have an existing defconfig file (normally generated with 'make
> savedefconfig', but you can also just copy the .config file), you can use
> it as
> the source of the generated .config as follows:
>
> make BR2_DEFCONFIG=$PWD/myTarget1 O=output.target1
> make O=output.target1
>
>
Arnout, Is there anyway you can consider one more patch (attached file)?
It allows BR2 to bootstrap a build automatically if BR2_DEFCONFIG is
defined, and that BR2_CONFIG file hasn't been created yet.  One does not
have to copy a defconfig to the destination of .config to start the build.
Moreover, if the user passes in BR2_DEFCONFIG, most likely he or she wants
to use that as the config file.  There's no need to error out with a
message like "You have to run menuconfig first"!  Most users at this time
would run "make BR2_DEFCONFIG=/tmp/defconfig menuconfig", believing that
the new config would be generated from defconfig.  That's not the case,
let's improve it!


Without the patch, the user has to carry out one of the following steps:

  1.  copy defconfig file to config file (according to you)
       ie:  mkdir $PWD/myTarget1 && cp defconfig $PWD/myTarget1/.config

  2.  Manually generate .config from defconfig (according to BR2 manual)
       make BR2_DEFCONFIG=$PWD/myTarget1 O=output.target1 defconfig


It would be nice if that process is automated!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20180209/cab8d8a3/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: br2_auto_generate_config.patch
Type: text/x-patch
Size: 678 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20180209/cab8d8a3/attachment.bin>