Skip to contentSkip to conversation

$(SED) not defined if 'make menuconfig savedefconfig'

Buildroot New Alvaro Gamez 5 participants 14 messages Jun 15, 2015 – Feb 28, 2016 Kbuild

lore
Share & tools
lore

Alvaro Gamez

author
#0 lore raw

Hi!

While using buildroot-submodule (
https://github.com/Openwide-Ingenierie/buildroot-submodule) I've noticed this happens since commit f71a621d91ec27f175fc84012962f88b1107305f was introduced into buildroot.

$ make menuconfig savedefconfig
[Do whatever, or nothing at all and exit, there's no need to save anything]
*** End of the configuration.
*** Execute 'make' to start the build or try 'make help'.

make: /BR2_DEFCONFIG=/d: Command not found Makefile:777: recipe for target 'savedefconfig' failed
make: *** [savedefconfig] Error 127

However,

$ make menuconfig
$ make savedefconfig

does not end with that error. I've just tracked it down to the fact that $(SED) is not defined when menuconfig savedefconfig are used in a single make call, whereas it equals to '/bin/sed -i -e'

Simply replacing that @$(SED) by /bin/sed -i -e on line 777 of Makefile makes it work again, but I don't think that solution is desirable. I'm sorry I can't provide a full patch, the motive of this bug is beyond my knowledge.

Best regards

Signature · 4 lines
?lvaro G?mez Machado
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20150615/e5bb3d96/attachment.html>
#1 lore raw

Dear Alvaro Gamez,

Quoted 18 lines · Alvaro Gamez

While using buildroot-submodule (
https://github.com/Openwide-Ingenierie/buildroot-submodule) I've noticed this happens since commit f71a621d91ec27f175fc84012962f88b1107305f was introduced into buildroot.

$ make menuconfig savedefconfig
[Do whatever, or nothing at all and exit, there's no need to save anything]
*** End of the configuration.
*** Execute 'make' to start the build or try 'make help'.

make: /BR2_DEFCONFIG=/d: Command not found Makefile:777: recipe for target 'savedefconfig' failed
make: *** [savedefconfig] Error 127

However,

$ make menuconfig
$ make savedefconfig
Quoted 8 lines

does not end with that error. I've just tracked it down to the fact that $(SED) is not defined when menuconfig savedefconfig are used in a single make call, whereas it equals to '/bin/sed -i -e'

Simply replacing that @$(SED) by /bin/sed -i -e on line 777 of Makefile makes it work again, but I don't think that solution is desirable. I'm sorry I can't provide a full patch, the motive of this bug is beyond my knowledge.

Hum, right. Can you try the below patch:

Makefile +1 -0
index d3f80c4..67eb50c 100644
@@ -272,6 +272,7 @@ HOSTLN := $(shell which $(HOSTLN) || type -p $(HOSTLN) || echo ln)
 HOSTNM := $(shell which $(HOSTNM) || type -p $(HOSTNM) || echo nm)
 HOSTOBJCOPY := $(shell which $(HOSTOBJCOPY) || type -p $(HOSTOBJCOPY) || echo objcopy)
 HOSTRANLIB := $(shell which $(HOSTRANLIB) || type -p $(HOSTRANLIB) || echo ranlib)
+SED := $(shell which sed || type -p sed) -i -e
 
 export HOSTAR HOSTAS HOSTCC HOSTCXX HOSTLD
 export HOSTCC_NOCCACHE HOSTCXX_NOCCACHE
package/Makefile.in +0 -1
index c02d31f..f256b05 100644
@@ -217,7 +217,6 @@ endif
 INSTALL := $(shell which install || type -p install)
 FLEX := $(shell which flex || type -p flex)
 BISON := $(shell which bison || type -p bison)
-SED := $(shell which sed || type -p sed) -i -e
 UNZIP := $(shell which unzip || type -p unzip) -q
 
 APPLY_PATCHES = support/scripts/apply-patches.sh $(if $(QUIET),-s)
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
Tested-by
#2 lore raw

Hi Thomas, Alvaro,

Quoted 52 lines · Thomas Petazzoni

Dear Alvaro Gamez,

Quoted 18 lines · Alvaro Gamez

While using buildroot-submodule (
https://github.com/Openwide-Ingenierie/buildroot-submodule) I've noticed this happens since commit f71a621d91ec27f175fc84012962f88b1107305f was introduced into buildroot.

$ make menuconfig savedefconfig
[Do whatever, or nothing at all and exit, there's no need to save anything]
*** End of the configuration.
*** Execute 'make' to start the build or try 'make help'.

make: /BR2_DEFCONFIG=/d: Command not found Makefile:777: recipe for target 'savedefconfig' failed
make: *** [savedefconfig] Error 127

However,

$ make menuconfig
$ make savedefconfig
Quoted 8 lines

does not end with that error. I've just tracked it down to the fact that $(SED) is not defined when menuconfig savedefconfig are used in a single make call, whereas it equals to '/bin/sed -i -e'

Simply replacing that @$(SED) by /bin/sed -i -e on line 777 of Makefile makes it work again, but I don't think that solution is desirable. I'm sorry I can't provide a full patch, the motive of this bug is beyond my knowledge.

Hum, right. Can you try the below patch:

Makefile +1 -0
index d3f80c4..67eb50c 100644
@@ -272,6 +272,7 @@ HOSTLN := $(shell which $(HOSTLN) || type -p $(HOSTLN) || echo ln)
 HOSTNM := $(shell which $(HOSTNM) || type -p $(HOSTNM) || echo nm)
 HOSTOBJCOPY := $(shell which $(HOSTOBJCOPY) || type -p $(HOSTOBJCOPY) || echo objcopy)
 HOSTRANLIB := $(shell which $(HOSTRANLIB) || type -p $(HOSTRANLIB) || echo ranlib)
+SED := $(shell which sed || type -p sed) -i -e
 
 export HOSTAR HOSTAS HOSTCC HOSTCXX HOSTLD
 export HOSTCC_NOCCACHE HOSTCXX_NOCCACHE
package/Makefile.in +0 -0
index c02d31f..f256b05 100644

package/Makefile.in endif · line 222

Quoted 7 lines
package/Makefile.in +0 -1
@@ -217,7 +217,6 @@ endif
 INSTALL := $(shell which install || type -p install)
 FLEX := $(shell which flex || type -p flex)
 BISON := $(shell which bison || type -p bison)
-SED := $(shell which sed || type -p sed) -i -e
 UNZIP := $(shell which unzip || type -p unzip) -q
 
 APPLY_PATCHES = support/scripts/apply-patches.sh $(if $(QUIET),-s)

I reproduced Alvaro's observation and your patch does resolve the issue.

Tested-by Doug Kehn <[email protected]>

Regards,
...doug

author Tested-by
#3 lore raw

Hi, Thomas, Doug,

2015-06-15 16:20 GMT+02:00 <[email protected]>:

Quoted 33 lines

Makefile HOSTLN := $(shell which $(HOSTLN) || type -p

Quoted 5 lines
Makefile +0 -0
index d3f80c4..67eb50c 100644
@@ -272,6 +272,7 @@ HOSTLN := $(shell which $(HOSTLN) || type -p

$(HOSTLN) || echo ln)

Makefile HOSTLN := $(shell which $(HOSTLN) || type -p · line 273

Quoted 2 lines
Makefile +0 -0
 HOSTNM := $(shell which $(HOSTNM) || type -p $(HOSTNM) || echo nm)
 HOSTOBJCOPY := $(shell which $(HOSTOBJCOPY) || type -p $(HOSTOBJCOPY)

|| echo objcopy)
>  HOSTRANLIB := $(shell which $(HOSTRANLIB) || type -p $(HOSTRANLIB) ||

echo ranlib)

Quoted 11 lines
Makefile +1 -0
+SED := $(shell which sed || type -p sed) -i -e
 
 export HOSTAR HOSTAS HOSTCC HOSTCXX HOSTLD
 export HOSTCC_NOCCACHE HOSTCXX_NOCCACHE
package/Makefile.in +0 -0
index c02d31f..f256b05 100644

package/Makefile.in endif · line 222

Quoted 7 lines
package/Makefile.in +0 -1
@@ -217,7 +217,6 @@ endif
 INSTALL := $(shell which install || type -p install)
 FLEX := $(shell which flex || type -p flex)
 BISON := $(shell which bison || type -p bison)
-SED := $(shell which sed || type -p sed) -i -e
 UNZIP := $(shell which unzip || type -p unzip) -q
 
 APPLY_PATCHES = support/scripts/apply-patches.sh $(if $(QUIET),-s)

I reproduced Alvaro's observation and your patch does resolve the issue.

Quoted 6 lines
Tested-by Doug Kehn <[email protected]>

Regards,
...doug

I've just tested it too and can confirm that this fixes the problem and my particular use case with buildroot-submodule.

Tested-by Alvaro G. M. <[email protected]>

Thanks a lot

Signature · 4 lines
?lvaro G?mez Machado
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20150616/193bdcfa/attachment.html>
author
#4 lore raw

Hi, all

2015-06-16 9:58 GMT+02:00 Alvaro Gamez <[email protected]>:

Quoted 37 lines

2015-06-15 16:20 GMT+02:00 <[email protected]>:

Quoted 35 lines

Makefile HOSTLN := $(shell which $(HOSTLN) || type -p

Quoted 5 lines
Makefile +0 -0
index d3f80c4..67eb50c 100644
@@ -272,6 +272,7 @@ HOSTLN := $(shell which $(HOSTLN) || type -p

$(HOSTLN) || echo ln)

Makefile HOSTLN := $(shell which $(HOSTLN) || type -p · line 273

Quoted 2 lines
Makefile +0 -0
 HOSTNM := $(shell which $(HOSTNM) || type -p $(HOSTNM) || echo nm)
 HOSTOBJCOPY := $(shell which $(HOSTOBJCOPY) || type -p $(HOSTOBJCOPY)

|| echo objcopy)
>  HOSTRANLIB := $(shell which $(HOSTRANLIB) || type -p $(HOSTRANLIB) ||

echo ranlib)

Quoted 11 lines
Makefile +1 -0
+SED := $(shell which sed || type -p sed) -i -e
 
 export HOSTAR HOSTAS HOSTCC HOSTCXX HOSTLD
 export HOSTCC_NOCCACHE HOSTCXX_NOCCACHE
package/Makefile.in +0 -0
index c02d31f..f256b05 100644

package/Makefile.in endif · line 222

Quoted 7 lines
package/Makefile.in +0 -1
@@ -217,7 +217,6 @@ endif
 INSTALL := $(shell which install || type -p install)
 FLEX := $(shell which flex || type -p flex)
 BISON := $(shell which bison || type -p bison)
-SED := $(shell which sed || type -p sed) -i -e
 UNZIP := $(shell which unzip || type -p unzip) -q
 
 APPLY_PATCHES = support/scripts/apply-patches.sh $(if $(QUIET),-s)

I reproduced Alvaro's observation and your patch does resolve the issue.

Tested-by Doug Kehn <[email protected]>
Quoted 10 lines
Quoted 4 lines

Regards,
...doug

I've just tested it too and can confirm that this fixes the problem and my particular use case with buildroot-submodule.

Tested-by Alvaro G. M. <[email protected]>

I just wanted to query about the status of this patch. I haven't found it on patchwork, probably because it wasn't sent as a PATCH email on itself, but it was tested by Doug and me.

I can confirm it still applies and works as intended. If you need me to, I can git-email it.

Best regards

Signature · 4 lines
?lvaro G?mez Machado
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20160216/b528d529/attachment.html>
#5 lore raw

Hello Alvaro,

Quoted 6 lines · Alvaro Gamez
Quoted 6 lines

I've just tested it too and can confirm that this fixes the problem and my particular use case with buildroot-submodule.

Tested-by Alvaro G. M. <[email protected]>
Quoted 6 lines

I just wanted to query about the status of this patch. I haven't found it on patchwork, probably because it wasn't sent as a PATCH email on itself, but it was tested by Doug and me.

I can confirm it still applies and works as intended. If you need me to, I can git-email it.

Indeed this patch is not in patchwork. And if a patch is not in patchwork, we will definitely forget about it. We have several hundreds of patches already in patchwork, so we can hardly keep track of patches that were not submitted in a form that allows them to be tracked by patchwork.

So, it would be really good if you could submit this patch with 'git send-email'.

Thanks a lot!

Thomas

Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
author
#6 lore raw

PATCH 1/1 Declare SED Makefile instead of package/Makefile.in so it exists globally.

In particular, this allows the use of buildroot-submodule and in general, any use of buildroot from out of tree.

Tested-by Doug Kehn <[email protected]>
Tested-by Alvaro G. M. <[email protected]>
Signed-off-by Alvaro G. M <[email protected]>
---
 Makefile            | 1 +
 package/Makefile.in | 1 -
 2 files changed, 1 insertion(+), 1 deletion(-)
Makefile +1 -0
index 71735b5..d6069dd 100644
@@ -279,6 +279,7 @@ HOSTLN := $(shell which $(HOSTLN) || type -p $(HOSTLN) || echo ln)
 HOSTNM := $(shell which $(HOSTNM) || type -p $(HOSTNM) || echo nm)
 HOSTOBJCOPY := $(shell which $(HOSTOBJCOPY) || type -p $(HOSTOBJCOPY) || echo objcopy)
 HOSTRANLIB := $(shell which $(HOSTRANLIB) || type -p $(HOSTRANLIB) || echo ranlib)
+SED := $(shell which sed || type -p sed) -i -e
 
 export HOSTAR HOSTAS HOSTCC HOSTCXX HOSTLD
 export HOSTCC_NOCCACHE HOSTCXX_NOCCACHE
package/Makefile.in +0 -1
index dd595e2..273a594 100644
@@ -214,7 +214,6 @@ endif
 INSTALL := $(shell which install || type -p install)
 FLEX := $(shell which flex || type -p flex)
 BISON := $(shell which bison || type -p bison)
-SED := $(shell which sed || type -p sed) -i -e
 UNZIP := $(shell which unzip || type -p unzip) -q
 
 APPLY_PATCHES = support/scripts/apply-patches.sh $(if $(QUIET),-s)
Signature · 1 line
2.7.0
#7 lore raw

PATCH 1/1 Declare SED Makefile instead of package/Makefile.in so it exists globally.

Hello,

The title is too long, it should be:

Makefile: declare SED globally

or something like that.

Quoted 2 lines · Alvaro G. M

In particular, this allows the use of buildroot-submodule and in general, any use of buildroot from out of tree.

This commit log should be improved, because:

1/ Why should we care about buildroot-submodule, and if we care, what
is the actual problem ?

2/ What do you mean by "use Buildroot from out of tree" ? I do out of
tree builds every day and it works just fine. So this aspect needs to be detailed.

I have nothing against the change, which is fairly simple, but it needs to be justified properly.

Thanks a lot!

Thomas

Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
#8 lore raw

PATCH 1/1 Declare SED Makefile instead of package/Makefile.in so it exists globally.

Hi Alvaro,

In addition to Thomas's comments, please use your full name in the
Signed-off-by line.

Quoted 17 lines · Thomas Petazzoni

Hello,

The title is too long, it should be:

Makefile: declare SED globally

or something like that.

Quoted 2 lines · Alvaro G. M

In particular, this allows the use of buildroot-submodule and in general, any use of buildroot from out of tree.

This commit log should be improved, because:

1/ Why should we care about buildroot-submodule, and if we care, what
is the actual problem ?

Quoted 6 lines

2/ What do you mean by "use Buildroot from out of tree" ? I do out of
tree builds every day and it works just fine. So this aspect needs to be detailed.

I have nothing against the change, which is fairly simple, but it needs to be justified properly.

I suspect we're not going to like the justification :-)

Regards,
Arnout

Signature · 6 lines
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
author
#9 lore raw

PATCH 1/1 Declare SED Makefile instead of package/Makefile.in so it exists globally.

Hi, guys

2016-02-16 23:35 GMT+01:00 Arnout Vandecappelle <[email protected]>:

Quoted 6 lines

Hi Alvaro,

In addition to Thomas's comments, please use your full name in the
Signed-off-by line.

Well, I've been reviewing the original thread (
http://lists.busybox.net/pipermail/buildroot/2015-June/130347.html) in order to write a good commit and I've just realized that this patch wasn't in fact written by me, it was written by Thomas in respones to my inquiries, so I think the Signed-off-by line should in fact belong to him, not me. Sorry I took over that, it wasn't my intention.

Quoted 4 lines · Thomas Petazzoni
Quoted 2 lines

1/ Why should we care about buildroot-submodule, and if we care, what
is the actual problem ?

Because it provides a nice workflow, which even though not perfect, is very useful at least to me and to Jeremy Rosen, its original author :) Not that it should matter much to anyone who doesn't use it, I guess.

But, anyhow, reviewing the original thread, the bug this patch solves does not only affect buildroot-submodule, although I discovered it by using that piece of software, so the commit message was in fact very wrong, sorry.

There's one case of make invocation that won't work without this patch, which is this:

make menuconfig savedefconfig

After exiting menuconfig, the following error is reported:

make[1]: /BR2_DEFCONFIG=/d: Command not found Makefile:849: recipe for target 'savedefconfig' failed make[1]: *** [savedefconfig] Error 127 common.mk:65: recipe for target 'menuconfig' failed
make: *** [menuconfig] Error 2

Quoted 6 lines
Quoted 4 lines

2/ What do you mean by "use Buildroot from out of tree" ? I do out of
tree builds every day and it works just fine. So this aspect needs to be detailed.

As explained above, that was simply false. Oops. I had forgotten about the details of these and I thought it only affected make -C invocations, but it's not a matter of current path but of those two make targets invoked at the same time.

Quoted 2 lines

I suspect we're not going to like the justification :-)

Why not?

Best regards, sorry about all the trouble!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20160217/76c9f91a/attachment-0001.html>

#10 lore raw

PATCH 1/1 Declare SED Makefile instead of package/Makefile.in so it exists globally.

Hello,

Quoted 6 lines · Alvaro Gamez

Well, I've been reviewing the original thread (
http://lists.busybox.net/pipermail/buildroot/2015-June/130347.html) in order to write a good commit and I've just realized that this patch wasn't in fact written by me, it was written by Thomas in respones to my inquiries, so I think the Signed-off-by line should in fact belong to him, not me. Sorry I took over that, it wasn't my intention.

Aaah, yes, now I remember.

The savedefconfig target looks like:

savedefconfig: $(BUILD_DIR)/buildroot-config/conf outputmakefile

        @$(COMMON_CONFIG_ENV) $< \
                --savedefconfig=$(if $(DEFCONFIG),$(DEFCONFIG),$(CONFIG_DIR)/defconfig) \
                $(CONFIG_CONFIG_IN)
        @$(SED) '/BR2_DEFCONFIG=/d' $(if $(DEFCONFIG),$(DEFCONFIG),$(CONFIG_DIR)/defconfig)

So it uses the $(SED) variable.

However, this savedefconfig targets is implemented *outside* of the ifeq ($(BR2_HAVE_DOT_CONFIG),y) condition, but the inclusion of package/Makefile.in (which defines the SED variable) is only done inside the ifeq ($(BR2_HAVE_DOT_CONFIG),y).

So when you start from scratch and do "make menuconfig savedefconfig", BR2_HAVE_DOT_CONFIG is not defined, so package/Makefile.in is not included.

Define SED in the main Makefile is a quick work-around.

However, it will only fix this specific problem, and I believe if you do:

make menuconfig savedefconfig all

With the aim of starting the build right after the menuconfig, then it will still not work for other reasons.

I see two possible directions here:

1. We decide to really separate targets that can "create" the configuration from the other targets, and in this case, savedefconfig should be defined inside the BR2_HAVE_DOT_CONFIG condition. Which means that "make menuconfig savedefconfig" would no longer work, and you would have to do "make menuconfig" and then "make savedefconfig".

2. We decide that all targets should be available at all times, and get rid of this BR2_HAVE_DOT_CONFIG. However, I don't see how this can work since if you do "make menuconfig all", then@the time of "menuconfig", the .config doesn't exist, so it cannot be included by the main Makefile, and therefore when the "all" target will be processed, we won't have all the BR2_* make variables defined.

So I believe (2) doesn't work, and we should instead go with (1).

Arnout, what do you think?

Thomas

Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
#11 lore raw

PATCH 1/1 Declare SED Makefile instead of package/Makefile.in so it exists globally.

Quoted 57 lines · Thomas Petazzoni

Hello,

Quoted 6 lines · Alvaro Gamez

Well, I've been reviewing the original thread (
http://lists.busybox.net/pipermail/buildroot/2015-June/130347.html) in order to write a good commit and I've just realized that this patch wasn't in fact written by me, it was written by Thomas in respones to my inquiries, so I think the Signed-off-by line should in fact belong to him, not me. Sorry I took over that, it wasn't my intention.

Aaah, yes, now I remember.

The savedefconfig target looks like:

savedefconfig: $(BUILD_DIR)/buildroot-config/conf outputmakefile

        @$(COMMON_CONFIG_ENV) $< \
                --savedefconfig=$(if $(DEFCONFIG),$(DEFCONFIG),$(CONFIG_DIR)/defconfig) \
                $(CONFIG_CONFIG_IN)
        @$(SED) '/BR2_DEFCONFIG=/d' $(if $(DEFCONFIG),$(DEFCONFIG),$(CONFIG_DIR)/defconfig)

So it uses the $(SED) variable.

However, this savedefconfig targets is implemented *outside* of the ifeq ($(BR2_HAVE_DOT_CONFIG),y) condition, but the inclusion of package/Makefile.in (which defines the SED variable) is only done inside the ifeq ($(BR2_HAVE_DOT_CONFIG),y).

So when you start from scratch and do "make menuconfig savedefconfig", BR2_HAVE_DOT_CONFIG is not defined, so package/Makefile.in is not included.

Define SED in the main Makefile is a quick work-around.

However, it will only fix this specific problem, and I believe if you do:

make menuconfig savedefconfig all

With the aim of starting the build right after the menuconfig, then it will still not work for other reasons.

I see two possible directions here:

1. We decide to really separate targets that can "create" the configuration from the other targets, and in this case, savedefconfig should be defined inside the BR2_HAVE_DOT_CONFIG condition. Which means that "make menuconfig savedefconfig" would no longer work, and you would have to do "make menuconfig" and then "make savedefconfig".

2. We decide that all targets should be available at all times, and get rid of this BR2_HAVE_DOT_CONFIG. However, I don't see how this can work since if you do "make menuconfig all", then at the time of "menuconfig", the .config doesn't exist, so it cannot be included by the main Makefile, and therefore when the "all" target will be processed, we won't have all the BR2_* make variables defined.

Quoted 3 lines

So I believe (2) doesn't work, and we should instead go with (1).

Arnout, what do you think? In addition, I think it would be good t In addition, I think it would be good to In addition, I think it would be good to o

I agree we should go for (1).

However, this doesn't completely stop the 'make menuconfig savedefconfig': once
a .config file exists, you can still do that. But it could have some funky side effects (not that I can think of any right away, but it feels a bit iffy). So I think it would be good to enforce that all the noconfig_targets can only be called on their own on the command line. This would block completely silly things like 'make menuconfig defconfig' (it would also block potentially valid things like 'make foo_defconfig menuconfig', but I think adding an extra '&& make' in the middle of that is not so painful).

Regarding (2), it is probably not impossible, because make has this second-pass
mechanism. When you include a makefile (like we do for .config), and that file is the target of some rule that gets triggered, then all the makefiles will be re-read after that rule has been executed (but this happens only once, to avoid infinite recursion). So you could add something like:

.config: $(filter $(noconfig_targets),$(MAKECMDGOALS))

	@:

to re-read the .config. However, I think that's very fragile, difficult to understand, and not so much added value.

Regards,
Arnout

Signature · 6 lines
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
#12 lore raw

PATCH 1/1 Declare SED Makefile instead of package/Makefile.in so it exists globally.

Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line

"Arnout" == Arnout Vandecappelle <[email protected]> writes:

Hi,

Quoted 5 lines
Quoted 3 lines

Arnout, what do you think? In addition, I think it would be good t In addition, I think it would be good to In addition, I think it would be good to o

I agree we should go for (1).

Yes, I also think this is the sanest / simplest thing to do.

Quoted 8 lines

However, this doesn't completely stop the 'make menuconfig savedefconfig': once
a .config file exists, you can still do that. But it could have some funky side effects (not that I can think of any right away, but it feels a bit iffy). So I think it would be good to enforce that all the noconfig_targets can only be called on their own on the command line. This would block completely silly things like 'make menuconfig defconfig' (it would also block potentially valid things like 'make foo_defconfig menuconfig', but I think adding an extra '&& make' in the middle of that is not so painful).

No, that seems ok (as long as it is clear from the error message that you need to do so).

Signature · 1 line
Bye, Peter Korsgaard
author
#13 lore raw

PATCH 1/1 Declare SED Makefile instead of package/Makefile.in so it exists globally.

Hi,

2016-02-27 23:00 GMT+01:00 Peter Korsgaard <[email protected]>:

Quoted 11 lines
Quoted 2 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line

"Arnout" == Arnout Vandecappelle <[email protected]> writes:

However, this doesn't completely stop the 'make menuconfig

savedefconfig': once

Quoted 1 line

a .config file exists, you can still do that. But it could have some

funky side

Quoted 1 line

effects (not that I can think of any right away, but it feels a bit

iffy). So I

Quoted 1 line

think it would be good to enforce that all the noconfig_targets can

only be

Quoted 1 line

called on their own on the command line. This would block completely

silly

Quoted 9 lines
Quoted 1 line

things like 'make menuconfig defconfig' (it would also block

potentially valid

Quoted 1 line

things like 'make foo_defconfig menuconfig', but I think adding an

extra '&&

Quoted 1 line

make' in the middle of that is not so painful).

No, that seems ok (as long as it is clear from the error message that you need to do so).

I agree. For example from the point of view of buildroot-submodule there's no problem to invoke make twice, and, as you say, if there's an error message that explains that two targets cannot be called at once, that's all right then.

Signature · 4 lines
?lvaro G?mez Machado
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20160228/077824fe/attachment.html>