[Buildroot] Evaluation of make variables

[Buildroot] Evaluation of make variables

[Quotient Remainder]

Hello all,
I've run into a similar problem now a few times where lines inside
define variables are not being evaluated in make context but in shell
context.
An example, I was trying to convert U-Boot's makefile to genpackage.
Here is an excerpt.
---
define U_BOOT_POST_PATCH_HOOK_CUSTOM
	echo -e "\n\n\n\nU_BOOT_POST_PATCH_HOOK_CUSTOM.\n\n\n"
ifneq ($(qstrip $(BR2_TARGET_UBOOT_CUSTOM_PATCH_DIR)),)
	toolchain/patch-kernel.sh $(@D) $(U_BOOT_CUSTOM_PATCH_DIR) u-boot-$(U_BOOT_VERSION)-\*.patch
endif
endef # U_BOOT_POST_PATCH_HOOK_CUSTOM.

U_BOOT_POST_PATCH_HOOKS+=U_BOOT_POST_PATCH_HOOK_CUSTOM
---



The output is then:
---
$ make V=1 u_boot
...
echo -e "\n\n\n\nU_BOOT_POST_PATCH_HOOK_CUSTOM.\n\n\n"




U_BOOT_POST_PATCH_HOOK_CUSTOM.



ifneq (,)
/bin/sh: -c: line 0: syntax error near unexpected token `,'
/bin/sh: -c: line 0: `ifneq (,)'
make: *** [/home/crehill/obair/buildroot.org/output/build/u_boot-HEAD/.stamp_patched] Error 2
---



As you can see, the "ifneq" is being passed to the shell, where it is
meaningless.
Is it the indentation of the line:
        $(foreach hook,$($(PKG)_POST_CONFIGURE_HOOKS),$(call $(hook))$(sep))
in package/Makefile.package.in that causes it to be passed to the shell
instead of being taken as make instructions?


If I unindent that line I get an error:
---
$ make V=1 u_boot
package/Makefile.package.in:209: *** commands commence before first target.  Stop.
---

So, is there any way of using ifdef/ifeq/ifneq in the a "define"
variable that is used as a command?

[Buildroot] Evaluation of make variables

[Thomas Petazzoni]

On Tue, 27 Jul 2010 11:36:17 +0100
Quotient Remainder <quotientvremainder@gmail.com> wrote:

> An example, I was trying to convert U-Boot's makefile to genpackage.

While I'd like to see the bootloaders use an infrastructure, the
genpackage infrastructure is really designed for *packages* (with the
concept of staging and target installation, which are meaningless
concepts for bootloaders). I'm not sure just using the genpackage
infrastructure is OK. But I'm open to see the result of your work and
see how it looks.

> Here is an excerpt.
> ---
> define U_BOOT_POST_PATCH_HOOK_CUSTOM
> 	echo -e "\n\n\n\nU_BOOT_POST_PATCH_HOOK_CUSTOM.\n\n\n"
> ifneq ($(qstrip $(BR2_TARGET_UBOOT_CUSTOM_PATCH_DIR)),)
> 	toolchain/patch-kernel.sh $(@D) $(U_BOOT_CUSTOM_PATCH_DIR)
> u-boot-$(U_BOOT_VERSION)-\*.patch endif
> endef # U_BOOT_POST_PATCH_HOOK_CUSTOM.

You can't use make ifeq/ifneq tests inside define...endef blocks.
That's the major drawback of the package infrastructure. So you have do
something like:

define U_BOOT_POST_PATCH_HOOK_CUSTOM
	toolchain/patch-kernel.sh $(@D) $(U_BOOT_CUSTOM_PATCH_DIR) u-boot-$(U_BOOT_VERSION)-\*.patch
endef

ifneq ($(qstrip $(BR2_TARGET_UBOOT_CUSTOM_PATCH_DIR)),)
U_BOOT_POST_PATCH_HOOKS+=U_BOOT_POST_PATCH_HOOK_CUSTOM
endif

I.e, use no condition inside the hook implementation, and put the
condition at the hook registration site.

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] Evaluation of make variables

[Quotient Remainder]

Ar M?irt, 2010-07-27 ag 13:42 +0200, scr?obh Thomas Petazzoni:
> While I'd like to see the bootloaders use an infrastructure, the
> genpackage infrastructure is really designed for *packages* (with the
> concept of staging and target installation, which are meaningless
> concepts for bootloaders). I'm not sure just using the genpackage
> infrastructure is OK. But I'm open to see the result of your work and
> see how it looks.

Well my reason for looking at this was so that I could use Maxime's
git/svn patches to use a git repo to hold the U-Boot source.  As it
stands only Makefiles using gentargets can use this.  I would want to do
this for the linux kernel too.
Other details like ..._VERSION are not suited to the git/svn approach
either so I may just have to hack in the download part for my own
purposes.  If I think I have something that may be useful beyond that,
I'll post it.

> You can't use make ifeq/ifneq tests inside define...endef blocks.

Is this an inherent limitation of the make syntax or specific to the
layout of the buildroot makefiles?

> I.e, use no condition inside the hook implementation, and put the
> condition at the hook registration site.

I feared as much...

[Buildroot] Evaluation of make variables

[Thomas Petazzoni]

On Tue, 27 Jul 2010 12:54:53 +0100
Quotient Remainder <quotientvremainder@gmail.com> wrote:

> Well my reason for looking at this was so that I could use Maxime's
> git/svn patches to use a git repo to hold the U-Boot source.  As it
> stands only Makefiles using gentargets can use this.  I would want to
> do this for the linux kernel too.

As we discussed in another thread (if I remember correctly), I'm not
sure the gentargets infrastructure is appropriate for building the
kernel and bootloaders. But definitely, some sort of infrastructure
for building these would be good.

> Is this an inherent limitation of the make syntax or specific to the
> layout of the buildroot makefiles?

Inherent limitation of the make syntax. Try a simple test.mk file that
does:

FOOBAR=y

define BARFOO
ifeq ($(FOOBAR),y)
	echo "Hello World"
endif
endef

all:
	$(BARFOO)

it doesn't work, while:

FOOBAR=y

ifeq ($(FOOBAR),y)
define BARFOO
	echo "Hello World"
endef
endif

all:
	$(BARFOO)

does work.

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] Evaluation of make variables

[Quotient Remainder]

Ar Aoine, 2010-07-30 ag 10:33 +0200, scr?obh Thomas Petazzoni:
> As we discussed in another thread (if I remember correctly), I'm not
> sure the gentargets infrastructure is appropriate for building the
> kernel and bootloaders. But definitely, some sort of infrastructure
> for building these would be good.
> 

It was actually your previous post in this thread, but I understand;
you're "a little" busy these days. ;-)

> > Is this an inherent limitation of the make syntax or specific to the
> > layout of the buildroot makefiles?
> 
> Inherent limitation of the make syntax. Try a simple test.mk file that
> does:
> 
> FOOBAR=y
> 
> define BARFOO
> ifeq ($(FOOBAR),y)
> 	echo "Hello World"
> endif
> endef
> 
> all:
> 	$(BARFOO)
> 
> it doesn't work, while:

Yes and I wouldn't expect it to work.  but if I leave the top part the
same and just change to:

all:
$(BARFOO)

i.e. don't indent the $(BARFOO) line, the thinking being that the
variable would just get textually replaced by its value.
make then gives a missing separator error and this is what I don't
understand.  What separator is expected?

Then we look at the definition of GENTARGETS_INNER, which is used in a
target rule and it includes ifeq, etc.  What's special about that?  I
presume it's the $(eval ...) that changes its context in some way.