Making this library available as conan package

[jdoubleu]

Hi, I really like your library. I'd like to easily integrate it with other dependencies into my project using conan. Conan is a popular package manager in the C++ ecosystem, which integrates well with various build systems. By providing an "official" package in Conan's public repository, developers can easily consume this library in their projects.

I've started writing a conan "recipe" for this library, that is a definition of how this projects needs to be built by conan and can be consumed. But, first of all I wanted to check in with you, whether that's okay. I plan on submitting a PR to the conan-center-index later.

While creating the package, I faced some minor challenges. In order to ease the process of integrating this library, I'd suggest a few changes. I'm happy to submit these myself, if you agree:

1. The conan package's version is currently tied to the VirtualBox SDK's version, because your library doesn't provide a version itselt. I assume, there hasn't been a need to and it would slightly complicate the maintenance effort. As for the conan package, this makes it harder e.g. to include fixes of this library, because we would have to wait for the next VirtualBox SDK to include them. It is recommended for a package version to be closely tied to a fixed git/code version.
   • I haven't asked the conan team yet, how they deal with these situations (i.e. a project not providing a compatible versioning scheme). One solution could be to use the publish date as version. However, that may make it harder to correlate the package's version with this library/repository.
2. Is there a specific reason, why you manually prefix the library name on Windows with lib (see https://github.com/zrax/libvbox/blob/master/CMakeLists.txt#L56-L59)? This doesn't seem to affect the import lib (.lib) but only the shared library (.dll), making it harder for a generic find package mechanism (like CMake provides) to find and link to the library. I'd even argue that using non-standard behavior introduces issues with other tools/build systems, in general. I suggest removing this setting.
3. Furthermore, the import lib (.lib) doesn't seem to be installed on Windows. This might have to do with the manual override of the install components (see https://github.com/zrax/libvbox/blob/master/CMakeLists.txt#L248-L249). If there's no specific reason to why they need to be customized, I suggest leaving them out, because they almost match the defaults anyways (e.g. default RUNTIME DESTINATION should already be bin). I'm not sure about the COMPONENT shlib, though.

I circumvented these issues by applying patches (see jdoubleu/conan-center-index@jdoubleu:conan-center-index:master...add-libvbox#diff-f0bfde5d643d1bdac51a43ad38d41024628a3f36c108c138e39fe3e2c62d9e1f) when building the conan recipe/package.

What do you think about these suggestions and making your library available through conan?

Cheers

[zrax]

Hi, thanks for the interest! I'll try to give what context I can, and we'll see where to go from there...

1. Regarding the version number, I'm not entirely sure how useful it would be. We could just use the latest version of the SDK that libvbox supports, but I feel that can lead to confusion since libvbox actually supports a range of versions (5.0 - 7.1.6 currently) based on what version and SDK were specified to CMake -- I see you also download a matching SDK in the conan recipe, so it makes sense to apply that version in Conan.
2. The main reason I named it "libvbox" rather than "vbox" is to denote that it's not an official project or part of VirtualBox, but rather a library for interacting with it... On other platforms, the "lib" is implicit and required for standard linking behavior, so I just tried to match that naming on MSVC builds. Most notably, VirtualBox itself ships with several DLLs that start with "VBox", although admittedly no "VBox.dll" by itself. I'm open to suggestions here, but I hesitate to just remove the prefix...
3. You're right, I don't know (or remember) why I had those specified explicitly, and they were indeed suppressing the install of the import lib... I've removed those lines now in 381f9d1. Thanks!

[jdoubleu]

Thanks for your quick response!

Regarding your feedback:

1. This sounds even more like an argument for using a dedicated versioning scheme for this library/repo. For example: libvbox v1.0.0 could be compatible with VBox 5.0.2, 6.4.3 and 7.1.6; v1.0.1 contains a bugfix for one of the SKD's version; in v2, support for 5.x will be dropped, etc.
   I tied the package's version to the SDK only out of necessity. To support multiple different versions of the SDK with the conan package, I could introduce the SDK as a standalone package, but I'd have to ask upstream first.
   If you don't want to maintain a separate version of this repo, I guess the publish date as version approach would be best. Maybe the conan maintainers have another idea.
2. Understandable, especially with Oracle's past 😉. The main issue is that the import lib is just named differently from the .dll. If we could get CMake to rename both, that would work as well, I guess. Maybe that's possible with the OUTPUT_NAME property.
   Just out of curiosity: do you know how VBox libraries are called on Linux? I could imagine them using the lib prefix as well, as it's common.
3. Great! I also think, there's more potential in simplifying the main CMakeLists.txt. For example, the custom libvbox-config.cmake might not be necessary, because the required dependencies could also be exported through EXPORT_LINK_INTERFACE_LIBRARIES of the install(EXPORT ...) command. I haven't really used this feature, although I might try and change this and maybe submit a PR as well. However, that doesn't really affect the conan package.

[jdoubleu]

Just wanted to give a quick update on the current state:

1. Regarding the version: The conan center index anticipates this and recommends using a date based versioning scheme. When pinning to a commit hash, the package version should be stable.
2. The lib prefix "hack" on Windows turned out not to be a big problem, because I was able to configure conan to use that file.

Furthermore, I'm currently facing troubles with wrapping up the package on linux, because of the system dependency. Conan generates a FindXXX.cmake file itself. I have no way to inject the search logic to find vbox.h, etc. from the system package.

At this point, I'm also unsure whether the package will be accepted into the global repository. I think their guidelines forbid mangling multiple packages/dependencies, like I did with the VBox SDK, inside one package. Maybe the way forward is just to keep the package definition locally. I'm currently exploring ways to integrate it nicely into my project.