Could generators include the current package?

[kenfred]

It would be useful to have generators (such as cmake and pkgconfig) work for the current package.

We have a consumer recipe that builds a library and an executable. We want to use one of the generators to link the library with the executable.

Theoretically, one way to do this currently would be to have two recipes, one for the consuming executable and one for the library, where the former finds the latter via conan workspace. Before version 1.13.2, workspaces didn't quite get there. There was no way to specify the paths to the outputs. Since 1.13.2, you can specify those kinds of output paths, but there are a whole host of other workspace issues that make this "monorepo" style build difficult. (See #5762). Therefore, the only way we have been able to accomplish this is to manually generate a .pc file during the build stage. This is unfortunate, since conan already has solved the generator thing. It may be that the right answer is to simply use the two recipes and (some future, improved version of) workspace. I'd be satisfied with that.

Is there any way to run generators on the current package? I realize there is a lifecycle issue here. Normally one executes conan install to prepare all the dependencies (including the generators) and it has no knowledge of the package folder for the current recipe. Also it feels somewhat wrong that the build phase would have access to cmake or pc files related to that build (before the build and packaging has even occurred). Nevertheless, we have a use-case that is not served with the current implementation of workspaces.

To help us debug your issue please explain:

• I've read the CONTRIBUTING guide.
• I've specified the Conan version, operating system version and any tool that can be relevant.
• I've explained the steps to reproduce the error or the motivation/use case of the question/suggestion.

[memsharded]

Hi @kenfred

I think this is the current effort (just started, very early stage) to explicitly define "toolchains" in the recipes.
Please have a look to: #5737. If makes sense, we could close this one and track feedback in that other issue. Thanks!

[kenfred]

Thanks for looking at this issue. I don't think this overlaps with toolchains in #5737.

Specifically what I'm trying to do is this:

1. I have an executable in one build system (cgo, in this case) and a library in another build system (cmake, in this case), and the source and build scripts are both checked in to the same git repo.
2. The executable depends on the library and some other external libraries, and it consumes those dependencies via pkgconfig
3. The executable and library are both built in the same recipe, first the library and then the executable. (I don't really want to put them in the same recipe, but I have to. More on that later...)

Using the pkgconfig generator, I get pc files for all of the other external libraries, but I do not get a pc file for the local library, because it is part of the consumer recipe. That means I have to manually generate a pc file for it myself.

Now, you'd be right to question this wisdom of combining the executable and library in the same recipe. Theoretically, I should be able to have one recipe for the library and one for the executable, then check in a workspace that allows the library and executable to live together in a single git repo. However, workspaces aren't supporting that use case: pre version 1.13.2 the root package couldn't find the build outputs of the library to properly make a pc file; and post version 1.13.2 there are other issues surrounding how those output paths get specified (i.e layouts) and broken out-of-source builds. In both versions, workspaces are not supporting a heterogeneous build system where the library and executable have different toolchains. (I and others have made the suggestion in #5762 to use externalproject_add within the cmake workspace generator, which may allow us to have a super build of heterogeneous builds).

So I'd love to use workspaces for this, but they aren't (yet) suitable. Therefore, I'm looking for a way to use the pkgconfig generator on the consumer recipe itself.

[memsharded]

generate() method can also take into account the current package