[U-Boot] [PATCH V3 17/32] imximage.cfg: run files through C preprocessor

[Troy Kisky]

On 10/11/2012 4:15 PM, Tom Rini wrote:
> On Fri, Oct 12, 2012 at 12:27:09AM +0200, stefano babic wrote:
>
> [snip]
>> One reason to move into the board directory is that there was a decision
>> to move rules related to only one arch or SOC where they belong to, that
>> is in the corresponding arch/ or board/ directory.
> I'll admit that maybe my make-fu is off, but that idea doesn't work, at
> least for SPL.  So I'd really like someone to make that work first.
>
>>> 2. Easy to clean the temporary generated file. The main Makefile
>>> deletes files with .pcfgtmp extension.
>>>
>>> 3. The file referred to by boards.cfg actually exists before the build
>>> starts.
>> This is true, but I do not understand which is the advantage. A lot of
>> files are generated, also .c or .S files. If it exists or not, it does
>> not matter.

Consistency was my point here. Every other file in boards.cfg exists 
prior to build.

>>> 4. The temporary file can be placed in an out-of-tree directory for
>>> make -O builds
>>>
>>> Using the file extension to determine whether to use the preprocessor is
>>> also
>>> what gcc uses to preprocess ".S" files while skipping this for ".s" files.
>>>
>>> I believe that at least other mx6 boards will quickly change to using
>>> the preprocessor
>>> as well to add support for solo/duallite, so total line count should
>>> eventually be
>>> less with changes to the main makefile.
>> Ok, but if this true, the rule should be moved to the mx6 directory, and
>> should not be valid for other i.MX that do not need it.
> Introducing slight differences to the image generation rules per family
> generation when we could just have one rule that works fine for all
> generations is one worry I have about the notion of moving things out of
> a top level Makefile and putting them elsewhere.
>
>>> Having said that, I really have no problem going your route, I just
>>> don't prefer it.
>>> Let me know.
>> Let's wait to know Tom's opinion.
> How about this, if we convert the existing cfg files to '@' comments and
> use the LDSCRIPT style preprocessor rule instead of another one?  I
> assume there's improvements that could be done to the mx5 ones if we
> preprocessed them.  Or no?  I'm looking for opinions here myself still..
>

I had previously converted all existing cfg files to /* */ comments. 
That style of
comment seems common for LDSCRIPTs as well. '@''s actually give me an error.

arm-eabi-ld:u-boot.lds:1: ignoring invalid character `@' in expression

I do believe mx5 files can benefit from preprocessing. I can see the 
advantage of
converting everything now. I also like flexibility of not forcing every 
cfg file to
change now. So, I am setting on the fence. If I have to take a position, I'd
fall on the side of the smaller patch set of a gradual conversion, just 
because I
like smaller patches.


Troy