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

[Tom Rini]

-----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.  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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQIcBAEBAgAGBQJQfx2GAAoJENk4IS6UOR1W/YYQALM7ejRg8kZ2JLgJ5j0Ae6UG
49ZhsNtaJYS4p224wOvGTHkKMNg0apD1bO6r+aZ17mD/tNmJCzg46zwpVMeyydf4
/DBlQsxAHP1cpe5+5Gf2q/UXuzbL3XiQEN/ELea8jpY0eW3LImNB7PEAX3DaIcQE
NlretiUdWZmsdrtKPt16SBtC+yRqJXbRu9UEA6WKhKdLoAjhUm0NMDNzNHEsbsyV
DcAWa7MuppZ9x3UC6KHWtcjNZgKHlfRoRvYRWc0H+pVX/QTejhIh+dFN2Tx3Lu/0
8hGDLN+rBZS8yooPkiOtDEcAX8N/mj2pODqGvIuGBiPTXvauGHXGJfnscZMBhJoi
jKWqPzvpmUM8TR94ucadXszAb4GaGBZYy++w6kfb57InBTBy4+HwXMPEbqhv8LMm
VpuzN3sxNYW+KtaIUB5kaoznGI1zK7hY+/5n6EBYebZHE3zLdyMRKnvpq2bCO21r
IZsj+ki1STi6VBgWKg7uORAQzDIpCN9DTKauM4lVnxdYXLkOc2f3Zz8r17C+VrtQ
go7PShkF45djJr6EjbZHJ1jMuyT2+gw4QzyNDFv1coojDV7YF4MsTwXTi3R2EoMz
POwbt9crwe1O9EvbP85qYrznfG1ogNK8ZRSoSfz4sNvoYipZ6rTSiGyAq5eVT4yH
E5GKf6wg4ujGTgLm2djj
=rpFn
-----END PGP SIGNATURE-----