[question] Shared code and workspaces

[fischjo3SICKAG]

I have a library A that also exports some headers/cpp (mainly (google) mocks from some interfaces) files as resources for consumers. These public files are installed into resources directory after building. Consumers have to import these files into their cmake binary directory (otherwise, paths tend to get too long for cmake to handle). This worked fine, until I've tried out workspaces with A and a consumer B:

1. 'conan workspace ...' calls install() on A and B. A has not yet been built, therefore, no shared files have been copied to resources directory. Then B tries to import() everything from A's empty resource directory.
2. When building, B's test suite compilation fails due to missing files.

Questions:
I'm a bit reluctant to split A into two packages A and A_mocks because then number of dependencies increase by factor of two and versions can happen to mismatch (e.g., version A gets upgraded, but not the A_mock version in test-suites dependencies). But the sharing process I've described above also seems quite complex and fragile to me. Do you know any 'conanian' way to solve this more elegantly?

• I've read the CONTRIBUTING guide.

[Lawrencemm]

Shouldn't library A be sending those files through exports_sources?

[fischjo3SICKAG]

@Lawrencemm: Thank you for your suggestion. As far as I understand it, the export sources mechanism is used to provide the source code for compiling and testing the whole package (=code + regression test code + mock code). There are also mocks that are used only package-internally (i.e., not suitable for re-use). Therefore I want package to export an additional subset of these sources (== only the re-usable mocks). If I would rely on the export sources mechanism, each client would need to sift through all sources and select the mocks.

[lasote]

Yes, for the consumers, you would need anyway to package these mocks, so the issue would remain the same. Building first A is not a possibility?

[fischjo3SICKAG]

Yes, building A would definitely solve it. I've done so when I used lib A as editable. But in the context this would mean a change 'workspace install'. Currently, 'workspace install' calls 'conan install' for all packages of workspace in order of their dependency graph. If we would require dependencies to be built first, then 'workspace install' would need to call 'conan install && conan build' for all packages of workspace. You might skip conan build for root packages.

[lasote]

Yes, you are right. I tagged the issue and added to the workspace "project", the workspace feature definitely needs to improve.

[fischjo3SICKAG]

Thank you. Workspaces are a good concept and my colleagues and I definitely need them.

[memsharded]

#15992 is centralizing feedback and effort for Conan 2 workspaces, lets close this one and track progress there.