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

[Tom Rini <trini@ti.com>]

On Wed, Oct 17, 2012 at 02:38:47PM -0700, Troy Kisky wrote:
> 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 @.

Lets just go with /* */ comments, everyone understands that.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20121017/88894634/attachment.pgp>