executable, library targets don't honor sources dependencies

[esodan]

I have a Vala project, producing a library. In order to compile without issues, the project needs to generate an XML file, referenced by Vala code to access GTK UI definitions.

I've declared a dependency like:

resources_xml_dep = declare_dependency (sources: resources)

where resources is a sources custome target.

Then, I added to the library's dependencies, but simple it fails to build. After runing three times ninja command the file is generated and the build is successful.

This issue comes after using the source generator from a subproject. If I compile and install the source generator before run meson and ninja, the build is successful.

Relevant meson.build code is at:

https://gitlab.com/esodan/gtktester/blob/master/src/meson.build#L85

[nirbheek]

This seems like it's vala-specific, since this workflow works with other languages.

[QuLogic]

@esodan Based on your usage of declare_dependency, I think you may have misunderstood what it does. Writing valasources = declare_dependency(sources: [...], dependencies: resources_xml_dep) does not mean that the sources depend on the xml file, but it created an object that when used in a target adds those sources and dependencies to the target. Perhaps I am wrong and you were already aware of this, but then there seem to be a lot of extra declare_dependency in your setup.

@nirbheek It works with other languages because they are not two-stage compile-to-C, generally. In this setup, it's <bunch of files> -> gresg -> resources.xml -> glib-compile-resources -> resources.[ch]. The generated C and header files are included in the C stage, while the xml file is needed during the Vala stage. The generated C and header are correctly listed in the target, but it appears that Meson only applies that dependency information to the C part of the compile. The xml file is also listed in sources, but I guess Meson assumes it's only needed for linking. If this were a C-like language (i.e., single stage), the header dependency would take care of the xml file.

IMO, one of the issues is actually here, where meson forces you to specify a string instead of a build target for the compiler arguments. If Meson accepted targets in compiler args, it could add a dependency there.

[QuLogic]

I guess the first thing is #1994 and the second is #3822.

[jameswestman]

Is there a workaround for this? How would I go about properly fixing it?

[tristan957]

@jameswestman you might want to hop into the Mesonbuild channel on Matrix or OFTC to discuss this.

[eli-schwartz]

Generated headers always throw away a little bit of possible parallelization, for the sake of simplicity in rule definitions. You cannot compile ANY .c sources until all headers were generated the first time. Even if most of your .c sources don't actually include that specific header, you cannot add additional header deps to a specific source file within a target.

We could probably sacrifice a bit more by saying you cannot run valac on ANY source files until all headers (or xml "headers") are generated. Any reason not to do this?

[rgommers]

Just happened to see this. It sounds like exactly the same problem Cython has when generated sources are needed at the .pyx -> c stage. Which is being fixed in gh-11000.