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

[Troy Kisky]

On 10/17/2012 2:05 PM, Tom Rini wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 10/17/12 13:32, Troy Kisky wrote:
>> 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
> Right, but in u-boot.lds.S it gets preprocessed away, at least I swear
> I changed and tested that.  My thinking being it was a smaller diff
> delta.

Good point. Is there some magic parameter to pass to gcc to strip @. My 
current
command line is expanded to

arm-eabi-gcc -E -x c board/freescale/imx/ddr/mx6q_4x_mt41j128.pcfg -g  -Os
  -fno-common -ffixed-r8 -msoft-float  -D__KERNEL__ 
-DCONFIG_SYS_TEXT_BASE=0x17800000
  -I/home/tkisky/u-boot-imx6/include -fno-builtin -ffreestanding -nostdinc
  -isystem 
/home/tkisky/myandroid/prebuilt/linux-x86/toolchain/arm-eabi-4.4.3/bin/../lib/gcc/arm-eabi/4.4.3/include 
-pipe
   -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux 
-march=armv7-a
   -o board/freescale/imx/ddr/mx6q_4x_mt41j128.pcfgtmp

Alternatively, I could send a small patch to mkimage to ignore @ lines 
along with the currently
ignored # lines.

I grepped all lds files in u-boot, but could not find one that used @ as 
a comment indicator.
I don't know what/where u-boot.lds.S is.

>    But my final point being I don't think we should start
> introducing artificial differences here just because older boards may
> not use it.  That doing that leads to bit rot.
>
>> 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.
> I'm on the other side only because "later" sometimes never happens.
> Doing it as a series of smaller patches, now might be fine too...
>
> - -- 
> Tom
>