[Mesa-dev] [PATCH 1/8] swr/rast: Split backend.cpp to improve compile time

[Rowley, Timothy O]

> On Jun 28, 2017, at 3:56 AM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
> 
> On 26 June 2017 at 17:14, Rowley, Timothy O <timothy.o.rowley at intel.com> wrote:
>> 
>> On Jun 26, 2017, at 7:57 AM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
> 
>>>> +.INTERMEDIATE: backend.intermediate
>>>> 
>>> I have limited experience with .INTERMEDIATE and it didn't seem to
>>> bring single/incremental build times improvements.
>>> Have you seen any on your end? If not I'll just drop it.
>> 
>> 
>> I’m not really familiar with .INTERMEDIATE myself; found it when googling
>> around looking for a way to specify a code generator rule that produced
>> multiple files.  If there’s a better/cleaner way of doing this I’d like to
>> hear about it.
>> 
> AFAICT one can omit the line all together. I doubt it will hurt
> anything so don't bother removing it, just yet.
> 
>>> Hardcoding file names in generator scripts tends to be a bad idea. One
>>> example is the extra code needed to generate the cmake bits :-)
>>> One could prune that, but it's not a priority AFAICT.
>>> 
>>> 
>> I would like to be able to wildcard on the generated name, but it seems that
>> automake wants to have a static list of filenames at invocation.  Our cmake
>> approach internally generates a cmake fragment that is included by the
>> parent cmake, which is a little confusing but adds flexibility.
>> 
> Automake can use wildcards and template/suffix rules. Although we try
> to omit the former.
> 
> Can you share the flexibility points - I can only think of drawbacks.
> 
> I'm assuming your flow is as follows:
> A Ok, let's build the project
> B First go into go and execute a 'random file with magic arguments'
> C Now you can build via cmake
> 
> Doing any of the following and you're in a world of hurt:
> - Forget to do B - enjoy the strange error messages that you'll get ;-)
> - Do B, even when the file or any of it's dependencies have not changed.
> Your cmake files (and hence whole build) will be rebuild unnecessarily.
> 
> I think you/the team might have experienced some of those :-P
> Either way, I'll stop now since it's getting a tad much.

Ok, dug into the internal build system for this and the cmake solution isn’t as elegant as I thought.  We have a wrapper python script that runs cmake in the codegen directory to generate the cmake fragments and generated files based on the dependencies, then a normal cmake for the actual build that includes these fragments.  As long as people use that wrapper script everything builds without unnecessary work.

> -Emil
> P.S. Can we bribe you back to use plain text emails - I had to redo
> the email formatting :-\

This should be plain text.