Better code generation definition in CMakeLists.txt files

[floooh]

The shader code generator currently not only needs a .shd file with the actual shader source code, but an additional .py file which triggers the code generation. It would be better to have a separate cmake macro which allows to have a cleaner project structure, e.g.:

fips_generate(type args...)

For the shader code generator only the .shd file would be needed in this case, and the shader.py file could be removed:

fips_generate(Shader shader.shd)

[floooh]

PS: this should be an alternative way for non-.py file extensions. fips_generate() would basically associate a specific file (e.g. bla.xml, blub.png) with a Python generator script under fips-generators/. Fips would then create a custom build target for this the same way it would if a .py file would be provided.

[code-disaster]

With Oryol you add both the .shd files and the generated sources to source control. This itself isn't such a big issue, but I wonder how difficult it would be with CMake to generate sources into some intermediate build folder, without losing any benefits.

For example, the build system I've used in the past (https://github.com/code-disaster/lace-build) can write generated code too, but for some chicken-and-egg reasons they were not added to the IDE project files. Only the include path was added to the compile flags. This caused the symbols to not be available in the IDE, which was kind of counter-productive.

Of course one could simply setup a naming convention, and then .gitignore the generated files...

[floooh]

Yes good idea, I've been thinking about that as well, for instance the glfw cmake files generate a config.h header somewhere in the cmake build directory structure. The generated files would still have to be added to the project but not among the normal source files, but probably in the generator build target.

First thing however is that I want to have this fips_generate() macro, which takes the name of a python code generator, one or more input files, and one or more output files, e.g. for Oryol's shader system this would be:

fips_generate(ShaderLibrary bla.shd "bla.cc;bla.h")

This way the output isn't restricted anymore to exactly one .cc and one .h file, cmake has all the information to setup file dependencies correctly, and the output file extensions are no longer hardcoded to .cc and .h and the current bla.py can be removed.

[floooh]

Hmm, just stumbled over a problem when trying to move the generated files out of the source tree. I can't find a simple/intuitive way to automatically setup header search paths. I will keep them in the source tree, but move them into an IDE sub folder so that they are out of the way (that's what I found most confusing, instead of just a shader.shd file in the IDE, there's also a shader.py, shader.cc and shader.h file. The generated files will still be available in the IDE.

As for inclusion in version control: I think I will just keep them in there, since updating .gitignore, or having some naming convention for the generated files and .gitignore them with a pattern isn't very nice either. I can't currently think of a downside of adding them to version control, generated files will only change if the source .py file changes, or the VERSION stamp of the generator script is updated, so they wont show up as modified in version control without a reason.

[floooh]

PS: of course I could just put all generated files into one directory, but this would cause naming collisions (e.g. all samples have the same filename for the shader files), also I can't use auto-generated names (e.g. GUIDs) since the generated headers must still have a humen readable name since they must be included elsewhere in the code.

[floooh]

This is now merged into master. I had to move the generated source files back into the source tree (and for now also under version control, will open a new ticket for this), because setting up header search paths for generated files in dependent projects which import projects with code generation wasn't doable without lots of hacks and assumptions about project structure.