eli-schwartz
commented
3 weeks ago This mechanism should work for both the case where the interface definition is installed into some system folder, and when using it through the subproject mechanism, so I'd probably have to wrap it inside a dependency object.
I would start with figuring out how to store that information when installed into a system folder.
The usual mechanism for storing arbitrary data as part of an installed system dependency is to set a pkg-config variable (e.g. the variables kwarg to pkgconfig_mod.generate()) which works pretty well for string data.
I'm not sure how well it scales for your array use case...
We have a project that defines a set of interfaces, as protobuf files. This project is pulled into a number of other projects as a subproject, and each of these subprojects needs to compile the protobuf files using their preferred compiler (protoc/nanopb/python3-protobuf).
Each of the consumer projects needs to determine the list of files to compile. As we have a policy against globbing input files (because adding and removing files is not detected as a rebuild reason by CI), this means maintaining a redundant set of lists in other projects.
What we'd like to do now is export the interfaces from the interface project by defining a project variable that represents a file system tree containing a set of files, and passing that variable to a generator. This mechanism should work for both the case where the interface definition is installed into some system folder, and when using it through the subproject mechanism, so I'd probably have to wrap it inside a dependency object.
My initial idea was to use structured sources, but that appears to be a very special hack for Rust, and not usable outside that context.
Does it make sense to genericize structured sources in this way (i.e. allow passing through a dependency object, and support enough introspection to allow a generator to operate on it (query base directory to be used as an include path, and relative or absolute paths of contained files)?