Can custom_target generate source code in the source tree instead of in the build directory?

[franczc]

Hi,
I'd like to use custom_target() to run omniidl to generate C++ source and header files within my source tree. I can make omniidl to generate files in anywhere I want... but the problem is when I pass the custom_target() object into the static_library() function as a source, meson expects the generated files to be inside of the build directory.

The reason I want the generated files to be in the source tree is that they can be used to build my application for different CPU architectures. For example, I'll have a build directory for Intel and another build directory for ARM. I don't want to generate the same set of files twice.

I'd appreciate any ideas/advice. Thanks!

[TheQwertiest]

You can't generate anything with meson in the source tree (that is, you can, but meson will expect to find generated files in the build dir): "Meson is different from some other build systems in that it does not permit in-source builds. You must always create a separate build directory." (https://mesonbuild.com/Tutorial.html).

If you REALLY want to generate files only once, you can create a following custom_target:

1. If the file does not exist, generate it and put in some external folder (e.g. $cwd/../_result/generated/).
2. Create a symlink in build dir (using the @OUTDIR@ or @OUTPUT@ macros).

[franczc]

Thanks very much for the response!

[jpakkane]

Almost all of the time the overhead of generating sources multiple is insignificant compared to the time it takes to compile them. If this is the case, the simplest solution is to regenerate them for each build dir.

[franczc]

The symlink approach seems working OK. Thanks. The next question is, how can I make sure the generated code in the external folder can be deleted by running "ninja -t clean ". Currently it will only delete the symlink.

[eli-schwartz]

You can't, because ninja -t clean is part of ninja, not meson, and only deletes the declared outputs of build rules.

(It would be possible to create a custom wrapper that both runs ninja -t clean, and manually deletes additional files. This would be like manually creating a clean target in a Makefile with custom rm rules.)