From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rini Date: Wed, 17 Oct 2012 14:05:10 -0700 Subject: [U-Boot] [PATCH V3 17/32] imximage.cfg: run files through C preprocessor In-Reply-To: <507F15D4.3070506@boundarydevices.com> References: <1348281558-19520-1-git-send-email-troy.kisky@boundarydevices.com> <1349315254-21151-1-git-send-email-troy.kisky@boundarydevices.com> <1349315254-21151-18-git-send-email-troy.kisky@boundarydevices.com> <5072D772.5000309@denx.de> <5074D75D.8050200@boundarydevices.com> <5076A94D.9060207@denx.de> <50772D25.3090208@boundarydevices.com> <507747BD.7060103@denx.de> <20121011231502.GC20891@bill-the-cat> <507F15D4.3070506@boundarydevices.com> Message-ID: <507F1D86.7010804@ti.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de -----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-----