Conan Support

Starting in release 3.5.0, CommonLibSSE NG now supports using the Conan package manager both to manage its own build dependencies and as a method of using CommonLibSSE NG in your own projects.

Why Conan?

Historically CommonLibSSE and projects based on it have used Vcpkg, a package manager for C/C++ made by Microsoft. CommonLibSSE NG added the ability to consume CommonLibSSE itself via Vcpkg. However Vcpkg has some deficiencies as a package manager.

• It has poor versioning support, and what support there is was tacked on as an afterthought. As a result dependencies are typically unversioned in Vcpkg projects, and projects frequently break when there are breaking changes in a dependency pushed to a Vcpkg repository.
• No proper support for binary packages. The only support that exists is to cache a subsetted Vcpkg repository for a given project, but no support exists for reusable binary builds of specific packages without creating a fully distinct package (which cannot be used to satisfy transient dependencies). This results in potentially very long and massive builds for some dependencies.
• Poor repository design makes editing a repository fragile and difficult to test, and thus even Microsoft's official ports frequently break.

Conan can address these problems by having true repositories of builds rather than only recipes to perform a build (although it does support building from source as well). Repositories follow a tried-and-true layout model from existing repository solutions and thus is not liable to break, and is easily testable. And versioning is a first-class concept.

Building CommonLibSSE NG with Conan

To develop CommonLibSSE NG itself (not a plugin based on it), you can use Conan to manage dependencies. First, Conan 1.49 or later is required. At the time of this writing, this is a preview release and available from the GitHub releases page. It is also a requirement at the time of this writing that your Conan profile use Visual Studio compiler version 16 (2019). This is due to many Conan artifacts currently not being built yet for version 17 (2022).

You can deal with this in one of two ways. The first method is to use source packages. This is acceptable since CommonLibSSE NG has only a single package that needs compiled, the Catch2 testing library, and it's a trivial build job that takes minimal time (unlike other CommonLibSSE forks, NG uses fmt and spdlog in header-only mode, so these are not compiled at all). To setup your project this way, in the CommonLibSSE NG project directory run conan install --build=missing .. Conan will setup everything appropriately.

You should now be able to develop with CommonLibSSE NG if you use any of the MSVC Conan-specific configuration/build presets from CMakePresets.json, e.g. using the build preset debug-msvc-conan-all.

Consuming CommonLibSSE NG with Conan

You can add CommonLibSSE NG to your conanfile.txt (or conanfile.py) requirements. First you you must add the appropriate Color-Glass/Skyrim NG repository:

conan remote add colorglass https://charmedbaryon.jfrog.io/artifactory/api/conan/default-conan

Then add the dependency:

[requires]
commonlibsse-ng/3.5.0

Update the version number to the version constraints you want. Conan support was added in version 3.5.0, making that the earliest version available. Currently Conan builds are available for the following build_type/arch/os/compiler/compiler.version combinations:

• Debug/x86_64/Windows/Visual Studio/16
• Debug/x86_64/Windows/Visual Studio/17
• Release/x86_64/Windows/Visual Studio/16
• Release/x86_64/Windows/Visual Studio/17

When running conan install ./conanfile.txt Conan will now fetch and install CommonLibSSE NG for you, and you can use it normally.

Selective Runtime Support

Selective runtime support is handled via package options.

[requires]
commonlibsse-ng/3.5.0

[options]
commonlibsse-ng:ae=True
commonlibsse-ng:se=True
commonlibsse-ng:vr=True

The default is to support all three runtimes. To get a build with selective runtimes, disable any runtimes you do not want.