[U-Boot] [RFC PATCH 3/4] Add new folder and build system for SPL

[Aneesh V]

On Friday 08 July 2011 06:02 PM, Wolfgang Denk wrote:
> Dear Aneesh V,
>
> In message<4E16EAE9.5070505 at ti.com>  you wrote:
>>
>>>> +# create 'spl/obj' within OBJTREE for spl
>>>> +OBJTREE := $(OBJTREE)/spl/obj
>
> This is the part I dislike: we redefine variables and lose track of
> their original values.
>
>>>> +# We want the final binaries in this directory
>>>> +obj	:= $(obj)../
>> First of all, this was really intended to be:
>>
>> +obj	:= $(obj)../../
>
> Now we have already two levels oif such redefinitions, one going down
> and the other going up.
>
> This is, well, confusing.
>
> I think, we should remember the original value of $(OBJTREE), so we
> can use it here where we need it.
>
>>> I don't really like these "../" parts.  Can we please try to omit
>>> these?  We can use $(TOPDIR) and/or $(OBJTREE) instead to express the
>>> path names, can't we?
>>
>> Please note that even if we use $(OBJTREE), to achieve the above, we
>> will need:
>>
>> +obj	:= $(OBJTREE)/../
>>
>> Please note that $(OBJTREE) needs to be updated before including
>> config.mk while $(obj) needs to be updated after it.
>
> Well, we can of course:
>
> - use a different name instead of OBJTREE everywhere, and leave

What Daniel suggested about using something like SPLTREE(or SPLOBJTREE)
seems to be be right solution then. Are you ok with that?

>    OBJTREE as reference to the origonal value for global use,  or
> - introduce a new variable that stores the original setting of OBJTREE
>    so we can refer to this later
>
>> I used BUILD_DIR/spl/obj as OBJTREE to avoid this problem.
>
> I understand what you are doing, and I agree with it.  I just dislike
> the tiny implementation detaild of using relative chnages up and down
> in the directory structure.  I would rather be able to use absolute
> directory names (which are way easier to verify for debugging, etc.).

You want to continue to maintain nand_boot.c kind of files within
$(TOPDIR)/spl/ , right?

best regards,
Aneesh