| Message ID | 1389111727-11021-1-git-send-email-jeremy.rosen@openwide.fr |
|---|---|
| State | Accepted |
| Commit | 94dd02f5d0ce89549a82a99c56602e1c4a73bae7 |
| Headers | show |
ping ? Cordialement Jérémy Rosen +33 (0)1 42 68 28 04 fight key loggers : write some perl using vim Open Wide Ingenierie 23, rue Daviel 75012 Paris - France www.openwide.fr ----- Mail original ----- > Signed-off-by: Jérémy Rosen <jeremy.rosen@openwide.fr> > > --- > The following command, run from a clean buildroot checkout > > make O=.. BR2_EXTERNAL=.. raspberrypi_defconfig > > cause the following output, and makes stop : > > > make: *** Pas de règle pour fabriquer la cible « > /home/rosen/tmp/buildroot/ > configs/../configs/../configs/../configs/<lots more >/../configs/ > raspberrypi_defconfig », nécessaire pour « /home/rosen/tmp/buildroot/ > configs/../configs/../configs/<lots more>/../configs/ > raspberrypi_defconfig ». Arrêt. > > The problem is that the buildroot makefile has two rules to generate > %_defconfig: One that depends on $(TOPDIR)/configs/%_defconfig and > the > other one that depends on $(BR2_EXTERNAL)/configs/%_defconfig. > > When one rule checks for the file, the other rule becomes an implicit > rule > for the dependancy causing an infinite cross-recursion. > > By overriding the implicit rule, we prevent the infinite recursion. > --- > Makefile | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/Makefile b/Makefile > index 4320e7b..41d641c 100644 > --- a/Makefile > +++ b/Makefile > @@ -760,10 +760,14 @@ defconfig: $(BUILD_DIR)/buildroot-config/conf > outputmakefile > @mkdir -p $(BUILD_DIR)/buildroot-config > @$(COMMON_CONFIG_ENV) $< --defconfig=$(TOPDIR)/configs/$@ > $(CONFIG_CONFIG_IN) > > +$(TOPDIR)/configs/%_defconfig:; > + > %_defconfig: $(BUILD_DIR)/buildroot-config/conf > $(BR2_EXTERNAL)/configs/%_defconfig outputmakefile > @mkdir -p $(BUILD_DIR)/buildroot-config > @$(COMMON_CONFIG_ENV) $< --defconfig=$(BR2_EXTERNAL)/configs/$@ > $(CONFIG_CONFIG_IN) > > +$(BR2_EXTERNAL)/configs/%_defconfig:; > + > savedefconfig: $(BUILD_DIR)/buildroot-config/conf outputmakefile > @mkdir -p $(BUILD_DIR)/buildroot-config > @$(COMMON_CONFIG_ENV) $< \ > -- > 1.8.5.2 > >
>>>>> "Jeremy" == Jeremy Rosen <jeremy.rosen@openwide.fr> writes: > ping ? > Cordialement I cannot reproduce it here (with make 3.81), and I don't understand the French error message - But it looks sane, so committed, thanks.
Jérémy, All, On 2014-01-07 17:22 +0100, Jérémy Rosen spake thusly: > Signed-off-by: Jérémy Rosen <jeremy.rosen@openwide.fr> > > --- > The following command, run from a clean buildroot checkout > > make O=.. BR2_EXTERNAL=.. raspberrypi_defconfig > > cause the following output, and makes stop : > > > make: *** Pas de règle pour fabriquer la cible « /home/rosen/tmp/buildroot/ > configs/../configs/../configs/../configs/<lots more >/../configs/ > raspberrypi_defconfig », nécessaire pour « /home/rosen/tmp/buildroot/ > configs/../configs/../configs/<lots more>/../configs/ > raspberrypi_defconfig ». Arrêt. > > The problem is that the buildroot makefile has two rules to generate > %_defconfig: One that depends on $(TOPDIR)/configs/%_defconfig and the > other one that depends on $(BR2_EXTERNAL)/configs/%_defconfig. > > When one rule checks for the file, the other rule becomes an implicit rule > for the dependancy causing an infinite cross-recursion. > > By overriding the implicit rule, we prevent the infinite recursion. This breaks defconfigs from BR2_EXTERNAL when used with an out-of-tree build: make -C /path/to/buildroot \ O=/path/to/build \ BR2_EXTERNAL=/path/to/br2.external \ yem_defconfig [--SNIP--] *** Can't find default configuration "/home/ymorin/dev/buildroot/buildroot/configs/yem_defconfig"! :-( I'm looking into it... Regards, Yann E. MORIN.
Jérémy, All, On 2014-01-17 18:52 +0100, Yann E. MORIN spake thusly: > On 2014-01-07 17:22 +0100, Jérémy Rosen spake thusly: > > Signed-off-by: Jérémy Rosen <jeremy.rosen@openwide.fr> > > > > --- > > The following command, run from a clean buildroot checkout > > > > make O=.. BR2_EXTERNAL=.. raspberrypi_defconfig > > > > cause the following output, and makes stop : > > > > > > make: *** Pas de règle pour fabriquer la cible « /home/rosen/tmp/buildroot/ > > configs/../configs/../configs/../configs/<lots more >/../configs/ > > raspberrypi_defconfig », nécessaire pour « /home/rosen/tmp/buildroot/ > > configs/../configs/../configs/<lots more>/../configs/ > > raspberrypi_defconfig ». Arrêt. > > > > The problem is that the buildroot makefile has two rules to generate > > %_defconfig: One that depends on $(TOPDIR)/configs/%_defconfig and the > > other one that depends on $(BR2_EXTERNAL)/configs/%_defconfig. > > > > When one rule checks for the file, the other rule becomes an implicit rule > > for the dependancy causing an infinite cross-recursion. > > > > By overriding the implicit rule, we prevent the infinite recursion. > > This breaks defconfigs from BR2_EXTERNAL when used with an out-of-tree > build: > > make -C /path/to/buildroot \ > O=/path/to/build \ > BR2_EXTERNAL=/path/to/br2.external \ > yem_defconfig > [--SNIP--] > *** Can't find default configuration "/home/ymorin/dev/buildroot/buildroot/configs/yem_defconfig"! It even breaks BR2_EXTERNAL for in-tree builds. Reverting that patch fixes both issues, and does not exhibit the reported problem. Peter, can we just revert that patch (cset 94dd02f) for now, please? Jérémy, can you describe your setup, so we can try to reproduce it, and find a proper fix? Regards, Yann E. MORIN.
Jérémy, All, On 2014-01-17 19:09 +0100, Yann E. MORIN spake thusly: > On 2014-01-17 18:52 +0100, Yann E. MORIN spake thusly: > > On 2014-01-07 17:22 +0100, Jérémy Rosen spake thusly: > > > Signed-off-by: Jérémy Rosen <jeremy.rosen@openwide.fr> > > > > > > --- > > > The following command, run from a clean buildroot checkout > > > > > > make O=.. BR2_EXTERNAL=.. raspberrypi_defconfig > > > > > > cause the following output, and makes stop : > > > > > > > > > make: *** Pas de règle pour fabriquer la cible « /home/rosen/tmp/buildroot/ > > > configs/../configs/../configs/../configs/<lots more >/../configs/ > > > raspberrypi_defconfig », nécessaire pour « /home/rosen/tmp/buildroot/ > > > configs/../configs/../configs/<lots more>/../configs/ > > > raspberrypi_defconfig ». Arrêt. > > > > > > The problem is that the buildroot makefile has two rules to generate > > > %_defconfig: One that depends on $(TOPDIR)/configs/%_defconfig and the > > > other one that depends on $(BR2_EXTERNAL)/configs/%_defconfig. > > > > > > When one rule checks for the file, the other rule becomes an implicit rule > > > for the dependancy causing an infinite cross-recursion. > > > > > > By overriding the implicit rule, we prevent the infinite recursion. > > > > This breaks defconfigs from BR2_EXTERNAL when used with an out-of-tree > > build: > > > > make -C /path/to/buildroot \ > > O=/path/to/build \ > > BR2_EXTERNAL=/path/to/br2.external \ > > yem_defconfig > > [--SNIP--] > > *** Can't find default configuration "/home/ymorin/dev/buildroot/buildroot/configs/yem_defconfig"! > > It even breaks BR2_EXTERNAL for in-tree builds. > > Reverting that patch fixes both issues, and does not exhibit the > reported problem. > > Peter, can we just revert that patch (cset 94dd02f) for now, please? > > Jérémy, can you describe your setup, so we can try to reproduce it, and > find a proper fix? Out of curiosity, I just installed a make-4.0 to make sure that was not due to some idiocy of make-4.0 (since it hs changed quite a few behaviours that were relied on from previous versions, such as the ordering of files in $(wildcard ...) ). But no, it works as expected, with make-3.81 and make-4.0 alike. Regards, Yann E. MORIN.
> > > > Jérémy, can you describe your setup, so we can try to reproduce it, > > and > > find a proper fix? > Ok, i'll look into it and try to figure out... it's really weird that you were not able to reproduce with the steps in the patch, it was pretty systematic for me. I'll try to reproduce and report whatever I find
aaand reproduced. following the steps described, I get that problem systematically I use make 3.81 (debian testing) and I'm not sure what else is involved when crashing that early. I tried with LANG=C in case there was anything weird, but apparently not My make skills are not very high so i'll gladly take any help on figuring that one out... Cordialement Jérémy Rosen +33 (0)1 42 68 28 04 fight key loggers : write some perl using vim Open Wide Ingenierie 23, rue Daviel 75012 Paris - France www.openwide.fr ----- Mail original ----- > > > > > > > Jérémy, can you describe your setup, so we can try to reproduce > > > it, > > > and > > > find a proper fix? > > > > > Ok, i'll look into it and try to figure out... > > it's really weird that you were not able to reproduce with the steps > in the patch, it was pretty systematic for me. I'll try to reproduce > and report whatever I find > _______________________________________________ > buildroot mailing list > buildroot@busybox.net > http://lists.busybox.net/mailman/listinfo/buildroot
Jérémy, All, On 2014-01-20 09:13 +0100, Jeremy Rosen spake thusly: > aaand reproduced. > > following the steps described, I get that problem systematically > > I use make 3.81 (debian testing) and I'm not sure what else is > involved when crashing that early. > > > I tried with LANG=C in case there was anything weird, but apparently not > > My make skills are not very high so i'll gladly take any help on > figuring that one out... Please find attached a quick-n-dirty script to test. There are a few things you can customise inside. Especially, see the list of changesets. Don't forget to chmod +x the script, obviously! ;-) Can you report if you observe the same behaviour as the one documented in the script? Can you also tweak the script so that it exhibits your failure case, and repost it back? Regards, Yann E. MORIN.
Le 20/01/2014 09:13, Jeremy Rosen a écrit : > aaand reproduced. > > following the steps described, I get that problem systematically > > I use make 3.81 (debian testing) and I'm not sure what else is > involved when crashing that early. > > > I tried with LANG=C in case there was anything weird, but apparently not > > My make skills are not very high so i'll gladly take any help on > figuring that one out... > > Cordialement > > Jérémy Rosen > +33 (0)1 42 68 28 04 > > fight key loggers : write some perl using vim > > > Open Wide Ingenierie > > 23, rue Daviel > 75012 Paris - France > www.openwide.fr > > > > > > ----- Mail original ----- >>>> Jérémy, can you describe your setup, so we can try to reproduce >>>> it, >>>> and >>>> find a proper fix? >> >> Ok, i'll look into it and try to figure out... >> >> it's really weird that you were not able to reproduce with the steps >> in the patch, it was pretty systematic for me. I'll try to reproduce >> and report whatever I find >> Hi Jérémy, Yann I'm able to reproduce the issue here. There is no specific setup, I used my current buildroot directory and run: make O=.. BR2_EXTERNAL=.. raspberrypi_defconfig make: stat: /home/naourr/git/buildroot/configs/../configs/../configs/.. [snip] ../configs/raspberrypi_defconfig ». Stop Or make O=../output BR2_EXTERNAL=.. raspberrypi_defconfig make: stat: /home/naourr/git/buildroot/configs/../configs/../configs/.. [snip] ../configs/raspberrypi_defconfig ». Stop But it's ok with : make O=../output BR2_EXTERNAL=../external raspberrypi_defconfig GEN ../output/Makefile # # configuration written to ../output/.config # I have no solution currently, but I hope this help... Yann, what's wrong with relative path for BR2_EXTERNAL or O ? Best regards, Romain Naour
Romain, Jérémy, All, On 2014-01-20 23:58 +0100, Romain Naour spake thusly: > I'm able to reproduce the issue here. > > There is no specific setup, I used my current buildroot directory and run: > > make O=.. BR2_EXTERNAL=.. raspberrypi_defconfig > make: stat: /home/naourr/git/buildroot/configs/../configs/../configs/.. > [snip] > ../configs/raspberrypi_defconfig ». Stop > > Or > > make O=../output BR2_EXTERNAL=.. raspberrypi_defconfig > make: stat: /home/naourr/git/buildroot/configs/../configs/../configs/.. > [snip] > ../configs/raspberrypi_defconfig ». Stop OK, we have a way to reproduce it, now. We can investigate. Good! :-) > But it's ok with : > > make O=../output BR2_EXTERNAL=../external raspberrypi_defconfig GEN > ../output/Makefile > # > # configuration written to ../output/.config > # > > I have no solution currently, but I hope this help... > > Yann, what's wrong with relative path for BR2_EXTERNAL or O ? Because they do not work as you would expect. If you pass relative paths, they are interpreted relative to the buildroot directory. In your first two cases, you would expect it would work, but not in the following case: make -C buildroot O=build BR2_EXTERNAL=br2.external foo_defconfig In this case, you'd expect O and BR2_EXTERNAL to be relative to the current working directory. But hey are not. They are interpreted relative to the Buildroot dir. Bummer, that's not what you expect. So, you should only pass absolute paths to O and BR2_EXTERNAL (IMHO). See the manual: http://nightly.buildroot.org/#outside-br-custom ---8<--- The BR2_EXTERNAL path can be either an absolute or a relative path, but if it’s passed as a relative path, it is important to note that it is interpreted relatively to the main Buildroot source directory, not the Buildroot output directory. ---8<--- (Note: what this does not tell, however, is that it is not interpreted relative to the current working directory either.) And ditto for O, although nothing is psecified about using relative paths. :-( Now, I don't know why it fails as thus in your case... But it's late here. More on this tomorrow. If someone has a good idea about it... ;-) But the bottom line is: relative paths are a plague! ;-] Anyway, I'm all for fixing this problem you see, but the proposed patch broke another legitimate use-case. So we have to find a better fix, if possible. I for one would prefer we just forbid relative paths altogether, but I'm totaly open on keeping them, as long as: - we document it's very picky, and - we check for special cases such as the one mentioned above. Regards, Yann E. MORIN.
> > > > There is no specific setup, I used my current buildroot directory > > and run: > > > > make O=.. BR2_EXTERNAL=.. raspberrypi_defconfig > > make: stat: > > /home/naourr/git/buildroot/configs/../configs/../configs/.. > > [snip] > > ../configs/raspberrypi_defconfig ». Stop > > > > Or > > > > make O=../output BR2_EXTERNAL=.. raspberrypi_defconfig > > make: stat: > > /home/naourr/git/buildroot/configs/../configs/../configs/.. > > [snip] > > ../configs/raspberrypi_defconfig ». Stop > > OK, we have a way to reproduce it, now. We can investigate. Good! :-) > Awesome, do you still need me to run your script or are your fine ? as a side note, i'm boucman on IRC, i'll try to ping you if I see you around... > > But it's ok with : > > > > make O=../output BR2_EXTERNAL=../external raspberrypi_defconfig > > GEN > > ../output/Makefile > > # > > # configuration written to ../output/.config > > # > > > > I have no solution currently, but I hope this help... > > > > Yann, what's wrong with relative path for BR2_EXTERNAL or O ? > > Because they do not work as you would expect. If you pass relative > paths, they are interpreted relative to the buildroot directory. > that was indeed my understanding, I am trying to have the layout at https://github.com/Openwide-Ingenierie/raspaudio that is: * Having a buildroot/ subdirectory at the root of the project * Having a Makefile in the root of the project that correctly allows to build the project * Having BR2_EXTERNAL be the root of the project (and as much as possible, all config files in the root of the project) * Having an output/ subdirectory in the root of the project with all build files * Having everything relocatable (since I want to save it to git, I can't have absolute paths) That is currently not possible and maybe it's a bad idea, but this layout seems to make sense to me and the relative path requirement makes sense too, since it's needed for other people to use my project > In your first two cases, you would expect it would work, but not in > the > following case: > > make -C buildroot O=build BR2_EXTERNAL=br2.external foo_defconfig > > In this case, you'd expect O and BR2_EXTERNAL to be relative to the > current working directory. But hey are not. They are interpreted > relative to the Buildroot dir. Bummer, that's not what you expect. > actually, I did expect that not to work. I did look at everything I could in the usermanual :P Though I agree that it would be more sensible to have 0= and BR2_EXTERNAL be relative to cwd... > So, you should only pass absolute paths to O and BR2_EXTERNAL (IMHO). > see my use-case above... I need to commit the makefile to git, so no absolute path for me... > And ditto for O, although nothing is psecified about using relative > paths. :-( > yes, this needs to be added, i'll add a note. note that the makefile generated in the O= directory has an absolute path to the buildroot directory, not a relative one, which breaks my use case > Now, I don't know why it fails as thus in your case... But it's late > here. More on this tomorrow. If someone has a good idea about it... > ;-) > > But the bottom line is: relative paths are a plague! ;-] > i'd call them a necessary evil, but I see your point > Anyway, I'm all for fixing this problem you see, but the proposed > patch > broke another legitimate use-case. So we have to find a better fix, > if > possible. fair enough. I have some clues at what's going on (the biggest one being that the previous patch did fix my issue) but as I said I am at the limit of my make-fu... > > I for one would prefer we just forbid relative paths altogether, but > I'm > totaly open on keeping them, as long as: > - we document it's very picky, and > - we check for special cases such as the one mentioned above. > as stated above, I need relative path for my use-case. If absolute paths are required, we need to find a way to properly save in git a buildroot-based project. I am not sure how to do that but i'm opened to suggestions... > 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. | > '------------------------------^-------^------------------^--------------------' >
Jérémy, Romain, All, On 2014-01-21 09:44 +0100, Jeremy Rosen spake thusly: > > > make: stat: > > > /home/naourr/git/buildroot/configs/../configs/../configs/.. > > > [snip] > > > ../configs/raspberrypi_defconfig ». Stop > > OK, we have a way to reproduce it, now. We can investigate. Good! :-) > Awesome, do you still need me to run your script or are your fine ? Of course not, now we now how to reproduce the error. > > > Yann, what's wrong with relative path for BR2_EXTERNAL or O ? > > Because they do not work as you would expect. If you pass relative > > paths, they are interpreted relative to the buildroot directory. > that was indeed my understanding, I am trying to have the layout at > > https://github.com/Openwide-Ingenierie/raspaudio He, nice! :-) > that is: > > * Having a buildroot/ subdirectory at the root of the project > * Having a Makefile in the root of the project that correctly > allows to build the project > * Having BR2_EXTERNAL be the root of the project (and as much > as possible, all config files in the root of the project) > * Having an output/ subdirectory in the root of the project > with all build files > * Having everything relocatable (since I want to save it to git, I > can't have absolute paths) > > That is currently not possible and maybe it's a bad idea, but this > layout seems to make sense to me and the relative path requirement > makes sense too, since it's needed for other people to use my project But your Makefile already does not use relative paths: MAKEARGS := -C $(CURDIR)/buildroot MAKEARGS += O=$(CURDIR)/output MAKEARGS += BR2_EXTERNAL=$(CURDIR) which is IMHO the way to go. [--SNIP--] > Though I agree that it would be more sensible to have 0= and > BR2_EXTERNAL be relative to cwd... But since we may call 'make -C /bla/bla', CWD is lost long before we even get to the point our Makefile is parsed. > > So, you should only pass absolute paths to O and BR2_EXTERNAL (IMHO). > see my use-case above... I need to commit the makefile to git, so no > absolute path for me... See my answer above: you already use absolute paths, but with a variable. Which commits just fine, and is fully relocatable at check-out. > > And ditto for O, although nothing is psecified about using relative > > paths. :-( > yes, this needs to be added, i'll add a note. Thanks. > note that the makefile generated in the O= directory has an absolute > path to the buildroot directory, not a relative one, which breaks > my use case Indeed. But I don;t see why you need to be relocatable once you called one of the *config targets. Relocation at check-out time is perfectly understandable, yes, and already works with your repository. > > I for one would prefer we just forbid relative paths altogether, but > > I'm > > totaly open on keeping them, as long as: > > - we document it's very picky, and > > - we check for special cases such as the one mentioned above. > > > > as stated above, I need relative path for my use-case. If absolute > paths are required, we need to find a way to properly save in git a > buildroot-based project. I am not sure how to do that but i'm opened > to suggestions... Well, just look at your repository! ;-) Unles I missed something obvious, that is... :-) Regards, Yann E. MORIN.
> > > > * Having a buildroot/ subdirectory at the root of the project > > * Having a Makefile in the root of the project that correctly > > allows to build the project > > * Having BR2_EXTERNAL be the root of the project (and as much > > as possible, all config files in the root of the project) > > * Having an output/ subdirectory in the root of the project > > with all build files > > * Having everything relocatable (since I want to save it to git, I > > can't have absolute paths) > > > > That is currently not possible and maybe it's a bad idea, but this > > layout seems to make sense to me and the relative path requirement > > makes sense too, since it's needed for other people to use my > > project > > But your Makefile already does not use relative paths: > MAKEARGS := -C $(CURDIR)/buildroot > MAKEARGS += O=$(CURDIR)/output > MAKEARGS += BR2_EXTERNAL=$(CURDIR) > > which is IMHO the way to go. > ok, good. i'll stay with that approch (that doesn't use the br generated makefile nor the .br-external file) for my project > [--SNIP--] > > Though I agree that it would be more sensible to have 0= and > > BR2_EXTERNAL be relative to cwd... > > But since we may call 'make -C /bla/bla', CWD is lost long before we > even get to the point our Makefile is parsed. > indeed. so no CWD, then. makes sense <snip> > > Well, just look at your repository! ;-) > Unles I missed something obvious, that is... :-) > yes, indeed. I didn't realize that it was working for me :) BR2_EXTERNAL does indeed do what I want now. I'll move foward with the next step in my proof of concept project: relocating the various .config files but that's a story for another day :) > 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. | > '------------------------------^-------^------------------^--------------------' >
diff --git a/Makefile b/Makefile index 4320e7b..41d641c 100644 --- a/Makefile +++ b/Makefile @@ -760,10 +760,14 @@ defconfig: $(BUILD_DIR)/buildroot-config/conf outputmakefile @mkdir -p $(BUILD_DIR)/buildroot-config @$(COMMON_CONFIG_ENV) $< --defconfig=$(TOPDIR)/configs/$@ $(CONFIG_CONFIG_IN) +$(TOPDIR)/configs/%_defconfig:; + %_defconfig: $(BUILD_DIR)/buildroot-config/conf $(BR2_EXTERNAL)/configs/%_defconfig outputmakefile @mkdir -p $(BUILD_DIR)/buildroot-config @$(COMMON_CONFIG_ENV) $< --defconfig=$(BR2_EXTERNAL)/configs/$@ $(CONFIG_CONFIG_IN) +$(BR2_EXTERNAL)/configs/%_defconfig:; + savedefconfig: $(BUILD_DIR)/buildroot-config/conf outputmakefile @mkdir -p $(BUILD_DIR)/buildroot-config @$(COMMON_CONFIG_ENV) $< \
Signed-off-by: Jérémy Rosen <jeremy.rosen@openwide.fr> --- The following command, run from a clean buildroot checkout make O=.. BR2_EXTERNAL=.. raspberrypi_defconfig cause the following output, and makes stop : make: *** Pas de règle pour fabriquer la cible « /home/rosen/tmp/buildroot/ configs/../configs/../configs/../configs/<lots more >/../configs/ raspberrypi_defconfig », nécessaire pour « /home/rosen/tmp/buildroot/ configs/../configs/../configs/<lots more>/../configs/ raspberrypi_defconfig ». Arrêt. The problem is that the buildroot makefile has two rules to generate %_defconfig: One that depends on $(TOPDIR)/configs/%_defconfig and the other one that depends on $(BR2_EXTERNAL)/configs/%_defconfig. When one rule checks for the file, the other rule becomes an implicit rule for the dependancy causing an infinite cross-recursion. By overriding the implicit rule, we prevent the infinite recursion. --- Makefile | 4 ++++ 1 file changed, 4 insertions(+)