From mboxrd@z Thu Jan 1 00:00:00 1970 From: Troy Kisky Date: Wed, 17 Oct 2012 13:32:20 -0700 Subject: [U-Boot] [PATCH V3 17/32] imximage.cfg: run files through C preprocessor In-Reply-To: <20121011231502.GC20891@bill-the-cat> 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> Message-ID: <507F15D4.3070506@boundarydevices.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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