| Message ID | fd01d05b62a384b43722e790e3e491f87c818797.1357595083.git.yann.morin.1998@free.fr |
|---|---|
| State | Superseded |
| Headers | show |
Hello All, On Monday 07 January 2013 Yann E. MORIN wrote: > Support scripts (in support/) may need to parse the .config file, > so give them an easy access to it, by exporting CONFIG_FILE with > the fully-qualified path to .config. > > Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> > --- > Makefile | 4 ++++ > 1 files changed, 4 insertions(+), 0 deletions(-) > > diff --git a/Makefile b/Makefile > index 4b09437..7a2902d 100644 > --- a/Makefile > +++ b/Makefile > @@ -91,6 +91,10 @@ EXTRAMAKEARGS = O=$(O) > NEED_WRAPPER=y > endif > > +# Scripts in support/ may need to parse out .config, so give > +# them easy access > +export BR2_CONFIG_FILE=$(CONFIG_DIR)/.config > + > # Pull in the user's configuration file > ifeq ($(filter $(noconfig_targets),$(MAKECMDGOALS)),) > -include $(CONFIG_DIR)/.config There are a few other places in this file where we use: $(CONFIG_DIR)/.config I was not sure how to handle these, especially since they are associated with: $(CONFIG_DIR)/.config.nopkg Using $(BR2_CONFIG_FILE).nopkg looks a bit ugly to me. Instead, I went to reason that we're in the top-level Makefile, and that we know what we're doing. BR2_CONFIG_FILE is our /API/ and although it would be nice to use it internally too, it does not fit properly, so I did not change it. Comments welcome. ;-) Regards, Yann E. MORIN.
Hi Yann, On 07/01/13 22:52, Yann E. MORIN wrote: > Support scripts (in support/) may need to parse the .config file, > so give them an easy access to it, by exporting CONFIG_FILE with > the fully-qualified path to .config. Good idea! > > Signed-off-by: "Yann E. MORIN"<yann.morin.1998@free.fr> > --- > Makefile | 4 ++++ > 1 files changed, 4 insertions(+), 0 deletions(-) > > diff --git a/Makefile b/Makefile > index 4b09437..7a2902d 100644 > --- a/Makefile > +++ b/Makefile > @@ -91,6 +91,10 @@ EXTRAMAKEARGS = O=$(O) > NEED_WRAPPER=y > endif > > +# Scripts in support/ may need to parse out .config, so give > +# them easy access > +export BR2_CONFIG_FILE=$(CONFIG_DIR)/.config. Convention is that BR2_* is set by Kconfig. I kind of like that, it helps us developers to understand a variable's meaning. [Yes, BR2_DEFCONFIG which I introduced myself is an exception. However, I have a pending patch that moves it into the .config :-)] > + > # Pull in the user's configuration file > ifeq ($(filter $(noconfig_targets),$(MAKECMDGOALS)),) > -include $(CONFIG_DIR)/.config I would replace the occurences of the plain config file with $(CONFIG_FILE). $(CONFIG_FILE).nopkg does indeed look stupid, so that one should be left alone. Regards, Arnout
Arnout,, All, On Tuesday 08 January 2013 07:50:51 Arnout Vandecappelle wrote: > On 07/01/13 22:52, Yann E. MORIN wrote: [--SNIP--] > > +# Scripts in support/ may need to parse out .config, so give > > +# them easy access > > +export BR2_CONFIG_FILE=$(CONFIG_DIR)/.config. > > Convention is that BR2_* is set by Kconfig. I kind of like that, it > helps us developers to understand a variable's meaning. I am afraid CONFIG_FILE as is could clash with some packages. Maybe DOT_CONFIG instead? I'll use that. > I would replace the occurences of the plain config file with > $(CONFIG_FILE). $(CONFIG_FILE).nopkg does indeed look stupid, so that one > should be left alone. OK, will do. Thanks. Regards, Yann E. MORIN.
On 08/01/13 13:51, Yann E. MORIN wrote: > Arnout,, All, > > On Tuesday 08 January 2013 07:50:51 Arnout Vandecappelle wrote: >> On 07/01/13 22:52, Yann E. MORIN wrote: > [--SNIP--] >>> +# Scripts in support/ may need to parse out .config, so give >>> +# them easy access >>> +export BR2_CONFIG_FILE=$(CONFIG_DIR)/.config. >> >> Convention is that BR2_* is set by Kconfig. I kind of like that, it >> helps us developers to understand a variable's meaning. > > I am afraid CONFIG_FILE as is could clash with some packages. > Maybe DOT_CONFIG instead? I'll use that. DOT_CONFIG is equally likely to conflict. (None of our own files use CONFIG_FILE, cfr. 'git grep -w CONFIG_FILE'). Regards, Arnout [snip]
Arnout, All, On Tuesday 08 January 2013 14:07:39 Arnout Vandecappelle wrote: > On 08/01/13 13:51, Yann E. MORIN wrote: > > On Tuesday 08 January 2013 07:50:51 Arnout Vandecappelle wrote: > >> On 07/01/13 22:52, Yann E. MORIN wrote: > > [--SNIP--] > >>> +# Scripts in support/ may need to parse out .config, so give > >>> +# them easy access > >>> +export BR2_CONFIG_FILE=$(CONFIG_DIR)/.config. > >> > >> Convention is that BR2_* is set by Kconfig. I kind of like that, it > >> helps us developers to understand a variable's meaning. > > > > I am afraid CONFIG_FILE as is could clash with some packages. > > Maybe DOT_CONFIG instead? I'll use that. > > DOT_CONFIG is equally likely to conflict. > > (None of our own files use CONFIG_FILE, cfr. 'git grep -w CONFIG_FILE'). I was not referring to our .mk files, but rather to the packages themselves. I did a quick survey in 110+ packages, and: - kconfig-based packages are not affected: kernel, uClibc, busybox, ct-ng - packages using CONFIG_FILE: - gdb: gdb/sim/ppc/Makefile.in:CONFIG_FILE = @sim_config@ - xbmc: xbmc/lib/freetype/builds/detect.mk:ifndef CONFIG_FILE - no package uses DOT_CONFIG - openbricks is using DOT_CONFIG, too List of tested packages in attached file, searched for with: grep --exclude-dir=.git --exclude-dir=.hg --exclude-dir=.svn \ -r -E '\<(CONFIG_FILE|DOT_CONFIG)\>' * 2>/dev/null Regards, Yann E. MORIN.
On 08/01/13 14:46, Yann E. MORIN wrote: > Arnout, All, > > On Tuesday 08 January 2013 14:07:39 Arnout Vandecappelle wrote: >> On 08/01/13 13:51, Yann E. MORIN wrote: >>> On Tuesday 08 January 2013 07:50:51 Arnout Vandecappelle wrote: >>>> On 07/01/13 22:52, Yann E. MORIN wrote: >>> [--SNIP--] >>>>> +# Scripts in support/ may need to parse out .config, so give >>>>> +# them easy access >>>>> +export BR2_CONFIG_FILE=$(CONFIG_DIR)/.config. >>>> >>>> Convention is that BR2_* is set by Kconfig. I kind of like that, it >>>> helps us developers to understand a variable's meaning. >>> >>> I am afraid CONFIG_FILE as is could clash with some packages. >>> Maybe DOT_CONFIG instead? I'll use that. >> >> DOT_CONFIG is equally likely to conflict. >> >> (None of our own files use CONFIG_FILE, cfr. 'git grep -w CONFIG_FILE'). > > I was not referring to our .mk files, but rather to the packages themselves. > I did a quick survey in 110+ packages, and: > - kconfig-based packages are not affected: kernel, uClibc, busybox, ct-ng > - packages using CONFIG_FILE: > - gdb: gdb/sim/ppc/Makefile.in:CONFIG_FILE = @sim_config@ > - xbmc: xbmc/lib/freetype/builds/detect.mk:ifndef CONFIG_FILE > - no package uses DOT_CONFIG > - openbricks is using DOT_CONFIG, too But if you anyway change the name, BUILDROOT_CONFIG is better than the non-specific DOT_CONFIG. How long can we discuss about a name? :-) Regards, Arnout > > List of tested packages in attached file, searched for with: > grep --exclude-dir=.git --exclude-dir=.hg --exclude-dir=.svn \ > -r -E '\<(CONFIG_FILE|DOT_CONFIG)\>' * 2>/dev/null > > Regards, > Yann E. MORIN. >
>>>>> "Arnout" == Arnout Vandecappelle <arnout@mind.be> writes: Hi, >> I was not referring to our .mk files, but rather to the packages themselves. >> I did a quick survey in 110+ packages, and: >> - kconfig-based packages are not affected: kernel, uClibc, busybox, ct-ng >> - packages using CONFIG_FILE: >> - gdb: gdb/sim/ppc/Makefile.in:CONFIG_FILE = @sim_config@ >> - xbmc: xbmc/lib/freetype/builds/detect.mk:ifndef CONFIG_FILE >> - no package uses DOT_CONFIG >> - openbricks is using DOT_CONFIG, too Arnout> But if you anyway change the name, BUILDROOT_CONFIG is better than Arnout> the non-specific DOT_CONFIG. Arnout> How long can we discuss about a name? :-) Long ;) I like BUILDROOT_CONFIG. It's unique and it's meaning is very obvious. Yann, care to rework the series to use BUILDROOT_CONFIG instead?
Peter, Arnout, All, On Sunday 13 January 2013 Peter Korsgaard wrote: > >>>>> "Arnout" == Arnout Vandecappelle <arnout@mind.be> writes: > >> I was not referring to our .mk files, but rather to the packages themselves. > >> I did a quick survey in 110+ packages, and: > >> - kconfig-based packages are not affected: kernel, uClibc, busybox, ct-ng > >> - packages using CONFIG_FILE: > >> - gdb: gdb/sim/ppc/Makefile.in:CONFIG_FILE = @sim_config@ > >> - xbmc: xbmc/lib/freetype/builds/detect.mk:ifndef CONFIG_FILE > >> - no package uses DOT_CONFIG > >> - openbricks is using DOT_CONFIG, too > > Arnout> But if you anyway change the name, BUILDROOT_CONFIG is better than > Arnout> the non-specific DOT_CONFIG. > > Arnout> How long can we discuss about a name? :-) > > Long ;) > > I like BUILDROOT_CONFIG. It's unique and it's meaning is very > obvious. Yann, care to rework the series to use BUILDROOT_CONFIG > instead? Yes, it's just a pull-request away! ;-) Regards, Yann E. MORIN.
diff --git a/Makefile b/Makefile index 4b09437..7a2902d 100644 --- a/Makefile +++ b/Makefile @@ -91,6 +91,10 @@ EXTRAMAKEARGS = O=$(O) NEED_WRAPPER=y endif +# Scripts in support/ may need to parse out .config, so give +# them easy access +export BR2_CONFIG_FILE=$(CONFIG_DIR)/.config + # Pull in the user's configuration file ifeq ($(filter $(noconfig_targets),$(MAKECMDGOALS)),) -include $(CONFIG_DIR)/.config
Support scripts (in support/) may need to parse the .config file, so give them an easy access to it, by exporting CONFIG_FILE with the fully-qualified path to .config. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> --- Makefile | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-)