Seamless separate compilation of libraries using Sharpmake

[cmello]

Hi,

I'm brainstorming ideas to use Sharpmake to build libraries in distinct repositories/builds and seamlessly consume them from other projects also built using Sharpmake. Please I would like to know your thoughts, recommendations or alternative ideas about this topic.

The vcpkg sample provides a way to fetch libraries from a dependency manager and consume them seamlessly, which looks great. I would like to extend that idea with the following features in mind:

• The build of each library is specified in a Sharpmake project+solution as usual, with its own unit tests / validation / CI.

• Dependencies to other libraries can be either:

  1. Resolved by the dependency manager (e.g. vcpkg or others) and referenced transparently in Sharpmake as binary artifacts (static or dynamic libraries). This would be the default option for consuming dependencies.

  or

  2. Included in the consumer solution as a project built from sources, in order to make editing and debugging of dependencies straightforward. This would resemble Gradle's Composite Builds .

The developer by default would build only the project they are working on, and have dependencies fulfilled by the dependency manager. But if the developer wants to choose any dependency to build locally from sources, they could switch to an editable local build easily. In this case, the solution generated by Sharpmake would include the dependency as a project. Ideally, this should be an easy step performed through configuration: both the dependency Sharpmake project and the consumer Sharpmake project would encapsulate the behavior in a way that could be configured without code changes (or at most a trivial code change in the consumer Sharpmake project).

Any ideas or suggestions will be greatly appreciated!

Thank you for your attention.

Best regards,
Cesar

[martinecker]

We're quite interested in something like this as well. One fundamental problem is that currently wrapping a precompiled library requires using the [Sharpmake.Export] attribute on the project class versus the [Sharpmake.Generate] attribute for libs that you want to fully build.

I haven't explored solutions yet but my current thinking is to add a new project class attribute that allows switching between "export" or "generate" at generation time, either when adding a project to a solution via AddProject, or maybe via AddPublic/PrivateDependency, or possibly introduce a new function that allows choosing between the precompiled or fully generated version of a project and this could be driven via a custom cmd line arg passed to Sharpmake.

[cmello]

Thanks for sharing your requirements and insight, Martin! Initially I was thinking about generating a C# file with a single class and method that would either do the AddProject or AddPublic/PrivateDependency, and including that generated file via a [module: Include]. I concluded that might not be a good idea when dealing with transitive dependencies, because it would require the generated class name to be unique. So I am trying to think of some other approach to delegate the source/binary dependency management to a C# library instead of dealing with including C# source code through [module: Include] . I am interested in learning thoughts of the Sharpmake community about this. Thanks!