[Piglit] [PATCH v2 08/13] piglit-dispatch: Add generated files.

Kenneth Graunke kenneth at whitecape.org
Tue Mar 13 13:38:26 PDT 2012


On 03/13/2012 09:24 AM, Paul Berry wrote:
[snip]
> Yeah, I agree that what I've put on the mailing list seems redundant.
> It seems like we have three options on the table:
>
> (1) Leave the patches as they are.
>
> CON: Seems redundant.
>
> CON: There's a danger that someone will edit the source files (or the
> generator script) and forget to re-run code generation.

I'm not a fan of checking in generated files.

> (2) Don't check the generated code into CMake; instead generate it at
> build time.
>
> PRO: Since this forces everyone to do code generation all the time, it
> will help ensure that the code generation script is platform independent
> and doesn't accumulate bugs.  Also it ensures that I'm not the only
> person who knows how to run the code generator and remembers to do so :)
>
> PRO: There's no danger of someone accidentally editing the generated
> files and checking in the results.

I like these advantages a lot.

> CON: I'm not 100% sure how to program the correct dependencies into
> CMake, to ensure that (a) the code generation script runs before any C
> files are built, and (b) all C files are rebuilt after the generated
> code changes.  (Chad helped me get this set up on an early draft of the
> code but I was unable to keep it working properly).

One solution to this is to create your own external project.  Then you 
just ship a library and appropriate header files, and people link 
against it.  Your external project would have a sensible build system, 
and the projects that use it would have a sensible build system.  No 
bizarre Makefile magic necessary.

I know you don't want to do that, but I'm going to keep suggesting it 
anyway. :)

> CON: When changing the code generation scripts (or the .spec and .tm
> files), more work will be required to manually verify that the generated
> code is correct, because the generated code won't show up in git diffs.

I think that's fine.

> (3) Don't check the source files into CMake; instead download them and
> manually rebuild whenever upstream changes.

I agree with Chad and Jose that (3) is not an option.


More information about the Piglit mailing list