
Hi Wolfgang,
On Thursday 26 May 2011 06:55 PM, Aneesh V wrote:
Hi Wolfgang,
On Tuesday 17 May 2011 06:23 PM, Wolfgang Denk wrote:
Dear Aneesh V,
In message4DD26B36.4050102@ti.com you wrote:
And how do you distinguish between the two cases at the top level Makefile? Using a CONFIG flag or on a per platform basis?
The decision should not be make in the top level makefile, but in spl/Makefile. And this can simply check if a board directory exists in the first place.
- How about the case where there is some board dependent code but also
code shared by the boards(SoC based code). Will we have different 'Makefile's then - one for board and one for SoC. Will we then build different libraries at each leavel and link them together etc?
- I think one key thing that you are perhaps missing is that in SPL
the board level Makefile is not just meant for board level files. Instead it is used to pull together files from all the layers and make a custom image. IMHO, we will get into un-necessary complexities if we lose this property of SPL. We may rather spend efforts on making the regular U-Boot more configurable.
Do you have any thoughts on this yet.
Is it ok if I continue to use the current SPL Makefile structure and abstract out common content from board level 'Makefile's to something like omap4.mk
Why not just invoke the board level Makefile from the top-level Makefile and let it decide about the code-reuse by doing something like I did?
Because then we need board specific directories and board specific Makefiles even for those boards where no board specific code exists, and all these Makefiles will be semi-identical copies of each other.
Considering point 2 above I think this is logical.
The board level Makefile needs to have all the files. For the SoC level selection of files and the SoC level rules, include the respective *.mk files. Because in this case there are no board specific files there is nothing more in the Makefile. Please note that this may not be the case in general. Most boards, I suspect, may have some board specific files too.
I wouldn't really consider the include statements as duplication of code. Instead, that was a way of avoiding duplication of code "given the constraints of the SPL model".
best regards, Aneesh