[Buildroot] [PATCH] prevent recursion in %_defconfig rules
Yann E. MORIN
yann.morin.1998 at free.fr
Tue Jan 21 18:38:20 UTC 2014
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.
--
.-----------------.--------------------.------------------.--------------------.
| 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. |
'------------------------------^-------^------------------^--------------------'
More information about the buildroot
mailing list