using of local dir

Hello,

in buildroot Makefile this includes the board specific config file from the local dir.

-include $(TOPDIR)/local/$(BOARD)/$(BOARD).config

Some lines later the LOCAL variable will be set:

ifneq ($(BUILDROOT_LOCAL),)
LOCAL:=$(BUILDROOT_LOCAL)
else
LOCAL:=local
endif

I think the LOCAL variable must be initialized before the include command and it have to use the LOCAL variable.

Is this correct?

Thanks,

Daniel

This would have been the correct thing, yes. svn blame Makefile; Ah, alright, no surprise..

Apart from what you mention, i strikes me as broken not to allow for BUILDROOT_LOCAL to point to anywhere but to limit it to the TOPDIR

*shrug* I'd rip it out in a whim either way

Bernhard> This would have been the correct thing, yes. svn blame Makefile; Bernhard> Ah, alright, no surprise..

Bernhard> Apart from what you mention, i strikes me as broken not to allow for Bernhard> BUILDROOT_LOCAL to point to anywhere but to limit it to the TOPDIR

It indeed seems quite broken. The $LOCAL variable isn't used anywhere either.

Bernhard> *shrug* I'd rip it out in a whim either way

Well, the local/save/getconfig stuff does seem kinda overengineered - Couldn't we just have a bunch of *_defconfig files under configs/ instead with a make %_defconfig target like the kernel has instead?

Bye, Peter Korsgaard

If the shell variable BUILDROOT_LOCAL is defined, then LOCAL can be anywhere, including relative to the current tree.

Check "project.mk"

The purpose of this is to allow you to start with an existing defconfig, and the commands will collects the different configurations in one place. You can't replace this function with defconfigs, but you can use the result to create new defconfigs.

At this time, not having access to the source tree, I can't see why LOCAL is defined *after* the include, so maybe this needs to be moved. Feel free to test.

Best Regards
Ulf Samuelsson

Hi,

Ulf> Check "project.mk"

Ahh. Why isn't the variable set there if it's only used in project.mk anyway?

Bernhard> *shrug* I'd rip it out in a whim either way

Ulf> The purpose of this is to allow you to start with an existing Ulf> defconfig, and the commands will collects the different Ulf> configurations in one place. You can't replace this function Ulf> with defconfigs, but you can use the result to create new Ulf> defconfigs.

Ulf> At this time, not having access to the source tree, I can't see why LOCAL Ulf> is defined *after* the include, so maybe this needs to be moved. Ulf> Feel free to test.

No thanks - You made the mess, and you get to clean it up.

<grumpy-mode>

I really think we need to focus on getting the basic functionality of buildroot stable and working so we can put out a release instead of adding (what atleast looks like) half baked extensions.

</grumpy-mode>

Bye, Peter Korsgaard

As long as you can have several projects built within the same tree. I'm using the projects functionality to have several related projects built this way.

Mind you I don't like using getconfig/saveconfig; too prone to losing changes if you forget to saveconfig. Instead I use "make BOARD=xyz .." each time. I will sometime send some patches to improve this method.

Hamish

Hamish Moffatt VK3SB <[email protected]> <[email protected]>

That is its intended use.

The stuff is used to generate the files needed by "make BOARD=xyz" If you have no need to change the configs after that,then you can use the BOARD=xyz after that.
Once you think it is frozen, you can submit a new board.

What do you want to change?

Best Regards
Ulf Samuelsson