delivering a Windows binary through common package managers

[Foadsf]

Following this post, it would be great if we could have a Windows binary releases as well. Then we could add the software to some of the common Windows package managers.

I just tested the source code on Windows by:

cmake -DBUILD_APPLICATIONS:BOOL=ON -DBUILD_EXAMPLE:BOOL=ON .. 
cmake --build . --config release --target install

and except some warnings, it seems to be working perfectly fine.

[schuhschuh]

Thanks for the suggestion. As you seem to have looked into package managers for Windows before, are there specific ones you can suggest? Do you have an idea of the complexity of their respective build / packaging scripts? I'm rarely developing on Windows, so haven't found myself using any Windows package managers yet. There seems to be quite a variety of package managers / repositories, which isn't ideal. Are there maybe a few that would be considered a "norm"?

Would you like to maintain build scripts for such package managers in a separate repository under the cmake-basis GitHub organization?

[schuhschuh]

As an alternative, what about attaching a Windows installer file (MSI) to the GitHub release page? These could be readily created with CPack without requiring separate build scripts for different package managers. Would that be suitable as well?

[schuhschuh]

I see that registries such as just-install do indeed just download and run such installers.

[schuhschuh]

Ideally, the installer package would be created as a by-product of a CI test, e.g., using AppVeyor.

I see that Travis CI has now also an early stage Windows build environment, which favors Chocolatey for installation of required third-party libraries. That would put Chocolatey onto the short list of Windows package managers.

EDIT: Given this SO thread, seems NuGet would be more appropriate than Chocolatey for a "library". There is also a CPack NuGet Generator which could possibly be used to create a package.

[Foadsf]

OK let me answer the questions one by one:

1. First of all, when we talk about Windows package managers we are actually referring to glorified downloader and install helpers. The situation is actually very bad. Read here.
2. I think Chocolatey is the best and the most commonly used one. Not that I'm happy with the devs (I stopped being a Patreon while ago), but it is the least awful one. Scoop is more HomeBrew-like, but not that used. Maybe WinGet in the future, as it is developed by Microsoft directly.
3. If you choose Chocolatey I can ask some great people to help us with that. No worries about that part.
4. I think Chocolatey packages must be maintained on Chocolatey Orgs/Repose. And the package maintainers usually keep a clone from which they send PRs.
5. Delivering a binary package is actually required for any of the so-called Windows package managers, including Chocolatey. None to my best knowledge can compile from source. Here in GitHub is the best place as Chocolatey can automatically pick up the latest versions.
6. I can help you with compiling. But the more sustainable solution is that you have a virtual Windows 10 on a VirtualBox or something. Unlike Apple, Microsoft is actually very keen that people use its OS. So much for Apple becoming the evilest tech corp at the moment. :))
7. CPack is great I would love to learn that as well.
8. If you want to deliver BASIS as a library, which doesn't seem like a good idea to me, then Conan and Vcpkg are the most common options AFIK.

[schuhschuh]

If you want to deliver BASIS as a library, which doesn't seem like a good idea to me, then Conan and Vcpkg are the most common options AFIK.

In my opinion, BASIS is a library of CMake modules. It also contains libraries for programming languages, the so-called BASIS Utilities, but these I belief are mostly unused.

The only application it contains is basisproject, but this tool was more included for convenience and I consider it non-essential. It's not what defines BASIS.

Similar to applications / libraries in other programming languages, which may depend on header files or modules from a third-party library, the same is true for BASIS. The CMakeLists.txt of the user project depends on including the CMake modules of the BASIS "library".

[schuhschuh]

Delivering a binary package is actually required for any of the so-called Windows package managers, including Chocolatey. [...]
CPack is great I would love to learn that as well.

Then I'd say let's start with CPack and try the WiX Generator and NuGet generator.

The definition of CPack variables for these generators should go in config/Package.cmake. The default settings can be found in BasisPack.cmake.

[Foadsf]

@schuhschuh maybe you can write a blog post or something explaining the differences between BASIS and other template generators like CoockieCutter?

[schuhschuh]

There is a clear misconception. BASIS is not a template generator. I would indeed suggest use of cookiecutter instead of basisproject tool. Your cookiecutter template would, however, contain files that make use of the BASIS CMake modules. Think of BASIS as an extension of CMake funtionality. Just like CMake provides you with functions and a set of CMake modules written in the CMake language for the purpose of build configuration.