[Buildroot] uboot.pbl - make 'include' issue

[Buildroot] uboot.pbl - make 'include' issue

[Ryan Barnett]

I have recently been working on trying to get support for the u-boot.pbl 
image format into buildroot. I submitted an initial patch set back in 
October and was given feedback to break out the boot/uboot/uboot.mk into 
processor specific architectures. Thomas Petazzoni and I did some initial 
work to split these out and he provide an example. I have been trying to 
take this work that he did and submit an updated patch set. However, I 
have hit a roadblock for which I can't seem to debug or figure out what is 
going wrong.

When I breakout defines and variables in boot/uboot/uboot.mk into separate 
files and add the following line:

include boot/uboot/*/*.mk

Once I add this to uboot.mk, the rules for uboot no longer work. Using any 
configuration, I can no longer do anything like this:

make uboot
make uboot-dirclean

Running the above yields the following error:

make[1]: *** No rule to make target `uboot'.  Stop.
make: *** [_all] Error 2

It seems that the include statement is affecting the $(eval 
$(generic-package)) call which generates the rules for uboot. However, I 
am able to copy the contents of both of my architecture specific changes 
verbatim into uboot.mk and they will work (when I remove or comment out 
the include statement). This leads me to believe that I do not have a 
syntax issue with the files. I have found that linux/linux.mk does the 
same thing and it works which is why this is very confusing to me.

I have put my recent work on a github branch - the top 3 patches are 
modification that I have done to head. If anybody has suggestions on how 
to fix this issue, please let me know.

https://github.com/rjbarnet/buildroot/tree/uboot-pbl

My original patch submission can be found here:
http://patchwork.ozlabs.org/bundle/rjbarnet/uboot-pbl/?state=*

Feedback from Thomas Petazzoni:
http://lists.busybox.net/pipermail/buildroot/2013-December/084613.html

Thanks,
-Ryan

[Buildroot] uboot.pbl - make 'include' issue

[Yann E. MORIN]

Ryan, Thomas, All,

On 2014-04-30 16:20 -0500, Ryan Barnett spake thusly:
> I have recently been working on trying to get support for the u-boot.pbl 
> image format into buildroot. I submitted an initial patch set back in 
> October and was given feedback to break out the boot/uboot/uboot.mk into 
> processor specific architectures. Thomas Petazzoni and I did some initial 
> work to split these out and he provide an example. I have been trying to 
> take this work that he did and submit an updated patch set. However, I 
> have hit a roadblock for which I can't seem to debug or figure out what is 
> going wrong.
> 
> When I breakout defines and variables in boot/uboot/uboot.mk into separate 
> files and add the following line:
> 
> include boot/uboot/*/*.mk
> 
> Once I add this to uboot.mk, the rules for uboot no longer work. Using any 
> configuration, I can no longer do anything like this:
> 
> make uboot
> make uboot-dirclean
> 
> Running the above yields the following error:
> 
> make[1]: *** No rule to make target `uboot'.  Stop.
> make: *** [_all] Error 2

Yes, that's not so surprising:

  - the $(eval $(generic-package)) use the $(pkgname) macro, which uses
    the $(pkgdir) macro

  - the $(pkgdir) macro is defined as thus:
        pkgdir = $(dir $(lastword $(MAKEFILE_LIST)))

  - and $(MAKEFILE_LIST) contains the _last_ Makefile that was parsed

  - but the pkg-inra expects that the last Makefile parsed be the
    current Makefile

Since you include other Makefiles from uboot.mk:
    boot/uboot/ppc-freescale/uboot-ppc-freescale.mk

then $(MAKEFILE_LIST) will end up with that when you call the usual eval
above, from which the generic-package derives the $(pkgdir) to be
"boot/uboot/ppc-freescale", and thus the $(pkgname) to be
"ppc-freescale", and not the "uboot" you expect.

So I'm afraid this approach won't work.

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] uboot.pbl - make 'include' issue

[Yann E. MORIN]

Ryan, Thomas, All,

On 2014-05-01 00:39 +0200, Yann E. MORIN spake thusly:
> On 2014-04-30 16:20 -0500, Ryan Barnett spake thusly:
> > I have recently been working on trying to get support for the u-boot.pbl 
> > image format into buildroot. I submitted an initial patch set back in 
> > October and was given feedback to break out the boot/uboot/uboot.mk into 
> > processor specific architectures. Thomas Petazzoni and I did some initial 
> > work to split these out and he provide an example. I have been trying to 
> > take this work that he did and submit an updated patch set. However, I 
> > have hit a roadblock for which I can't seem to debug or figure out what is 
> > going wrong.
> > 
> > When I breakout defines and variables in boot/uboot/uboot.mk into separate 
> > files and add the following line:
> > 
> > include boot/uboot/*/*.mk
> > 
> > Once I add this to uboot.mk, the rules for uboot no longer work. Using any 
> > configuration, I can no longer do anything like this:
> > 
> > make uboot
> > make uboot-dirclean
> > 
> > Running the above yields the following error:
> > 
> > make[1]: *** No rule to make target `uboot'.  Stop.
> > make: *** [_all] Error 2
> 
> Yes, that's not so surprising:
> 
>   - the $(eval $(generic-package)) use the $(pkgname) macro, which uses
>     the $(pkgdir) macro
> 
>   - the $(pkgdir) macro is defined as thus:
>         pkgdir = $(dir $(lastword $(MAKEFILE_LIST)))
> 
>   - and $(MAKEFILE_LIST) contains the _last_ Makefile that was parsed
> 
>   - but the pkg-inra expects that the last Makefile parsed be the
>     current Makefile
> 
> Since you include other Makefiles from uboot.mk:
>     boot/uboot/ppc-freescale/uboot-ppc-freescale.mk
> 
> then $(MAKEFILE_LIST) will end up with that when you call the usual eval
> above, from which the generic-package derives the $(pkgdir) to be
> "boot/uboot/ppc-freescale", and thus the $(pkgname) to be
> "ppc-freescale", and not the "uboot" you expect.

For reference, here is the applicable part of the make manual,
demonstrating the exact behaviour you observe:
    https://www.gnu.org/software/make/manual/make.html#index-MAKEFILE_005fLIST-_0040r_007b_0028list-of-parsed-makefiles_0029_007d-550

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] uboot.pbl - make 'include' issue

[Thomas Petazzoni]

Dear Yann E. MORIN,

On Thu, 1 May 2014 00:39:10 +0200, Yann E. MORIN wrote:

> Yes, that's not so surprising:
> 
>   - the $(eval $(generic-package)) use the $(pkgname) macro, which uses
>     the $(pkgdir) macro
> 
>   - the $(pkgdir) macro is defined as thus:
>         pkgdir = $(dir $(lastword $(MAKEFILE_LIST)))
> 
>   - and $(MAKEFILE_LIST) contains the _last_ Makefile that was parsed
> 
>   - but the pkg-inra expects that the last Makefile parsed be the
>     current Makefile
> 
> Since you include other Makefiles from uboot.mk:
>     boot/uboot/ppc-freescale/uboot-ppc-freescale.mk
> 
> then $(MAKEFILE_LIST) will end up with that when you call the usual eval
> above, from which the generic-package derives the $(pkgdir) to be
> "boot/uboot/ppc-freescale", and thus the $(pkgname) to be
> "ppc-freescale", and not the "uboot" you expect.

I haven't looked at the details, but linux/linux.mk seems to be doing
the exact same thing with the "Linux extensions" for real-time, and
doesn't appear to have any problem. It does:

include $(sort $(wildcard linux/linux-ext-*.mk))

$(eval $(generic-package))

So by the time generic-package is expanded, the last included makefile
is not linux.mk. And still the thing works.

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

[Buildroot] uboot.pbl - make 'include' issue

[Yann E. MORIN]

Thomas, Ryan, All,

On 2014-05-01 00:47 +0200, Thomas Petazzoni spake thusly:
> Dear Yann E. MORIN,
> 
> On Thu, 1 May 2014 00:39:10 +0200, Yann E. MORIN wrote:
> 
> > Yes, that's not so surprising:
> > 
> >   - the $(eval $(generic-package)) use the $(pkgname) macro, which uses
> >     the $(pkgdir) macro
> > 
> >   - the $(pkgdir) macro is defined as thus:
> >         pkgdir = $(dir $(lastword $(MAKEFILE_LIST)))
> > 
> >   - and $(MAKEFILE_LIST) contains the _last_ Makefile that was parsed
> > 
> >   - but the pkg-inra expects that the last Makefile parsed be the
> >     current Makefile
> > 
> > Since you include other Makefiles from uboot.mk:
> >     boot/uboot/ppc-freescale/uboot-ppc-freescale.mk
> > 
> > then $(MAKEFILE_LIST) will end up with that when you call the usual eval
> > above, from which the generic-package derives the $(pkgdir) to be
> > "boot/uboot/ppc-freescale", and thus the $(pkgname) to be
> > "ppc-freescale", and not the "uboot" you expect.
> 
> I haven't looked at the details, but linux/linux.mk seems to be doing
> the exact same thing with the "Linux extensions" for real-time, and
> doesn't appear to have any problem. It does:
> 
> include $(sort $(wildcard linux/linux-ext-*.mk))
> 
> $(eval $(generic-package))
> 
> So by the time generic-package is expanded, the last included makefile
> is not linux.mk. And still the thing works.

Indeed, but the includes are all in the same directory, so pkgdir still
return "linux" and thus the pkgname is correct.

In Ryan's case, the included Makefiles are in sub-dirs of uboot, so
pkgdir returns that last sub-dir, hence the wrong pkgname.

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] uboot.pbl - make 'include' issue

[Thomas Petazzoni]

Dear Yann E. MORIN,

On Thu, 1 May 2014 01:02:40 +0200, Yann E. MORIN wrote:

> > I haven't looked at the details, but linux/linux.mk seems to be doing
> > the exact same thing with the "Linux extensions" for real-time, and
> > doesn't appear to have any problem. It does:
> > 
> > include $(sort $(wildcard linux/linux-ext-*.mk))
> > 
> > $(eval $(generic-package))
> > 
> > So by the time generic-package is expanded, the last included makefile
> > is not linux.mk. And still the thing works.
> 
> Indeed, but the includes are all in the same directory, so pkgdir still
> return "linux" and thus the pkgname is correct.
> 
> In Ryan's case, the included Makefiles are in sub-dirs of uboot, so
> pkgdir returns that last sub-dir, hence the wrong pkgname.

Aah, good point. So I'll have to think more about this U-Boot extension
thing to find a more appropriate solution to suggest to Ryan.

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

[Buildroot] uboot.pbl - make 'include' issue

[rjbarnet at rockwellcollins.com]

Yann, Thomas, All,

"Yann E. MORIN" <yann.morin.1998@gmail.com> wrote on 04/30/2014 06:02:40 
PM:

> Thomas, Ryan, All,
> 
> On 2014-05-01 00:47 +0200, Thomas Petazzoni spake thusly:
>> Dear Yann E. MORIN,
>> 
>> On Thu, 1 May 2014 00:39:10 +0200, Yann E. MORIN wrote:
>> 
>>> Yes, that's not so surprising:
>>> 
>>>   - the $(eval $(generic-package)) use the $(pkgname) macro, which 
uses
>>>     the $(pkgdir) macro
>>> 
>>>   - the $(pkgdir) macro is defined as thus:
>>>         pkgdir = $(dir $(lastword $(MAKEFILE_LIST)))
>>> 
>>>   - and $(MAKEFILE_LIST) contains the _last_ Makefile that was parsed
>>> 
>>>   - but the pkg-inra expects that the last Makefile parsed be the
>>>     current Makefile
>>> 
>>> Since you include other Makefiles from uboot.mk:
>>>     boot/uboot/ppc-freescale/uboot-ppc-freescale.mk
>>> 
>>> then $(MAKEFILE_LIST) will end up with that when you call the usual 
eval
>>> above, from which the generic-package derives the $(pkgdir) to be
>>> "boot/uboot/ppc-freescale", and thus the $(pkgname) to be
>>> "ppc-freescale", and not the "uboot" you expect.

Yann - thank you for this explanation as was trying to figure out how 
MAKEFILE_LIST and all the includes were relating. When you run "make 
--debug" and all of the includes are printed it is very difficult to get a 
grasp of what is going on. I didn't realize that the targets were 
"ppc-freescale" and not "uboot".

>> I haven't looked at the details, but linux/linux.mk seems to be doing
>> the exact same thing with the "Linux extensions" for real-time, and
>> doesn't appear to have any problem. It does:
>> 
>> include $(sort $(wildcard linux/linux-ext-*.mk))
>> 
>> $(eval $(generic-package))
>> 
>> So by the time generic-package is expanded, the last included makefile
>> is not linux.mk. And still the thing works.
> 
> Indeed, but the includes are all in the same directory, so pkgdir still
> return "linux" and thus the pkgname is correct.
> 
> In Ryan's case, the included Makefiles are in sub-dirs of uboot, so
> pkgdir returns that last sub-dir, hence the wrong pkgname.

Based on this bit of information, I am going to rework the patch so that 
the names of the processor architectures are as follows:

boot/uboot/uboot.mk.<platform>
boot/uboot/Config.in.<platform>

Naming the files this way will get around the issues described above along 
with identified in the patch. I should be sending the first version of the 
patches later today to the mailing list.

Thanks again for the help,
-Ryan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20140501/9f810e84/attachment.html>