Idiomatic way to define generated files?

[avetiso]

We have projects that pull down data models as Ruby gems/.proto files and we generate C++ getters and setters for these models. So we have generated headers and source files.

If you update versions of the dependencies, some of these may go away, change, or new ones may be added. I would need a way to tell meson exactly what these sources and where the header includes are (aka, glob them), preferably without having to adjust the build files every time. These files are based on the ruby rake system, so they are only ever regenerated if their definitions have changed, so subsequent runs of meson build will not cause constant regeneration.

We would obviously prefer that we don't have to modify the meson build files to account for changes, but I understand that seems to be the intended design of meson? What compromises on this are the "least bad"?

[eli-schwartz]

Would automatically modifying the meson.build be a suitable solution? For example, a script that regenerates meson.build (or ./ruby/meson.build) based on some locked versions of gems that you're using (I assume this doesn't just pull down the "latest" gem?)

[eli-schwartz]

That would be the ./ruby/meson.build case I mentioned, right?

Note also that before you invoke subdir() you have a chance to create/modify the file using a run_command('generator-script.sh') or what have you. This is kind of gross, honestly, but the WrapDB version of OpenSSL does this to hook into the perl-based build system and translate some of its data into meson.build files. It's used in the WrapDB release flow and then those meson.build files get saved and used to create the WrapDB patch.

[avetiso]

It does seem a little gross. I suppose I could also do it in my conan script. That would make the meson "prettier". I'm not sure if I like it being in the conanfile more or in the meson.build file more.

Speaking of it being gross, what's the philosophy for meson here? The fundamental issue being ninja not allowing globbing, but what does the meson team see as the solution to this class of problems, generally?

[eli-schwartz]

We have tools like meson rewrite which can be used to perform scripted updates to meson.build that are subsequently checked into git.

In general, I'd say the belief is that there are too many advantages to "properly" listing all source files rather than dynamically globbing them, but providing people ways to avoid the painful busywork of manually typing in filelists is an interesting problem that is nice to solve.

[dcbaker]

I have a case where globing has been worth the trade off (generators that output 10,000 plus files) I use a python script to find them that’s always considered out of date, have it write a stamp file, then depend on that.

it does mean ninja always has to run that target, but it’s small price to pay compared to writing 10000 outputs manually

[avetiso]

Just FYI, I'm trying some variation of run_command('find', '', '-name', ''*.cpp'').stdout().strip() for this and I think it should work well enough because I always know the folder where the generated code is