Cannot build using the Hunter package manager (Issue #22352)
Kevin Scroggins
Describe the problem
Hi! I currently use Hunter as a package manager for C++ libraries in my project and was hoping to add wxWidgets using this system as well to avoid any environment setup and dependency conflicts. I recognize that this is not something that is officially supported, but thought I would at least reach out for support before giving up. One of the issues with building wxWidgets as-is is that Git submodules do not appear to be initialized by Hunter when building, and would conflict with the fundamental design of this system. As such I have created some side branches which utilize Hunter for dependency injection and I have gotten the project generating and building using CMake, but I am experiencing some linker failures related to being unable to open JPEG.lib and PNG.lib. This is my first experience trying to use wxWidgets, so my understanding of the inner workings of the build system are lacking. It would be nice if optional official support for using Hunter was added to allow for improved dependency management and ease of building without having to manage environment setup and external dependencies. Please let me know if you have any thoughts and are able to assist with this issue, or if this is inappropriate. Repository forks and logs are located below. I did not include forks for expat, catch2 or libjpeg-turbo since no modifications were done to these libraries. Thank you!!
Logs
LINK : fatal error LNK1104: cannot open file 'JPEG.lib' [E:\Programming Projects\Hunter\Packages\wxWidgets\CMakeBuild\libs\wxmono.vcxproj]
Repositories
https://github.com/Telefrag-Software/wxWidgets/tree/hunter
https://github.com/Telefrag-Software/zlib/tree/hunter-wx-d0982b8
https://github.com/Telefrag-Software/libtiff/tree/hunter-wx-bbe71f4a
https://github.com/Telefrag-Software/libpng/tree/hunter-wx-9f5815a21
Platform and version information
- wxWidgets Version: ~3.1.7 (5f469f4)
- wxWidgets Port: wxMSW?
- OS: Windows 7 Professional Service Pack 1 (x64) (6.1.7601)
- Compiler: Microsoft Visual Studio 2019 Community Edition (4.8.03761)
- CMake: 3.20.2
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Maarten
Looks like the hunter library names you provide do not exist. When I look at https://hunter.readthedocs.io/en/latest/packages/pkg/Jpeg.html it seems you have to specify the jpeg target instead of a library name, so set(JPEG_LIBRARIES JPEG::jpeg) instead of set(JPEG_LIBRARIES "JPEG") might work.
Also wxBUILD_LIB_TYPE is not a valid option. It is either shared libraries with wxBUILD_SHARED=ON or static libraries with wxBUILD_SHARED=OFF.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Kevin Scroggins
Oh!! 🤦♂️ That's exactly the info I was missing, I did not realize those variables were being used as linker targets. Thank you SO much for the quick, and insightful response! I'm still sifting through various build and linker errors and had to disable things like libtiff, lzma, zstd and so on, but that's mostly on me. 😄 Only thing left to do is Hunterize pcre since I missed that the first time around. 🤞 Will follow up once I make some more progress.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Kevin Scroggins
I've managed to make a significant amount of progress and got wxWidgets building as a stand-alone library with PCRE2 & NanoSVG also now being Hunterized, however I'm running into complications with ZLib. I already use a vanilla release of ZLib in my project for things like LibZIP, as well as for other dependencies in wxWidgets such as LibPNG, which will result in conflicts when statically linking everything together. I've been reviewing the changes on the wx branch of ZLib to see how feasible it might be to bring this in as the main version, but I noticed there are some changes which would break outside of the context of wxWidgets. I had previously started the process of renaming the wxWidgets version of ZLib to wxzlib to avoid this and maintain two different versions since the WX version uses a custom prefix, however I was still encountering several linker errors related to various ZLib functions. Still trying to figure out the best path forward, so if you have any suggestions or additional insight, I am all ears. Thanks!
Also, if you're interested, I set up the NanoSVG library to be properly consumed by CMake.. perhaps this is something you would like to bring into your fork so that it doesn't have to be hard-linked as a submodule?
Telefrag-Software/nanosvg@26db6fe
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Maarten
I'd suggest to not use the wxWidgets zlib branch (or any of the specific wx branches for png/tiff/jpeg/...) and just use zlib and other packages that hunter provides. If I search the hunter packages it has all of them, also libpcre and nanosvg.
wxWidgets works fine with zlib, png and all other system libraries on Linux, macOS, homebrew, msys2/mingw, so I see no reason why it wouldn't work with hunter.
NanoSVG is just a header that is included, there is nothing to build there. I don't see why we would need CMake files for that.
The only problem with nanosvg is that wxWidgets always tries to include it from ../../3rdparty/nanosvg/src/nanosvg.h, it does not support having nanosvg.h as an external source.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
It looks like the original question has been answered (thanks Maarten!) and I'm not sure if there is anything left here, i.e. are there any open issues or should this one be closed?
Generally speaking, we, of course, welcome any integration of wx with the other build/packaging systems, but I'm afraid we don't have any resources to maintain them on our own. So if you have any concrete questions, we'd be glad to (try to) answer them and if you propose any PRs that could improve things for your use case without any significant drawbacks for the other library users, they could be considered for inclusion in wx itself too, but I can't promise much more, sorry.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Kevin Scroggins
Oh alright sure, I can definitely switch off of WX specific branches, I had assumed that there changes on those branches were still required. I've managed to get the library to build successfully using Hunter as a stand-alone package using standard branches for each dependency thanks to your suggestions, which is a good start! Hunter does indeed have it's own versions of various packages available, but they aren't always updated on a regular basis, so I usually maintain my own forks of these repositories so I can update them when needed instead. 😄
That's definitely fair regarding NanoSVG, it was just a complication I ran into when trying to build all dependencies using Hunter so I had updated it to be consumed as a CMake interface package instead, so I thought I would mention it. This would allow NanoSVG to be supported as an external source.. assuming that they also had the same CMake changes of course, and remove any hard-coded relative paths. 😄
I have however encountered another obstacle regarding the structure of the library itself, and when trying to add it as a package to another project directly, CMake was reporting that neither wxWidgetsConfig.cmake nor wxwidgets-config.cmake could be found. I've been doing some digging to figure out how the export / package installation is set up within the library and the only thing I found was build/cmake/install.cmake which as far as I can tell seems to be undocumented, and possibly intended for installing a version of the library to the local file system? Typically there is a certain structure that is followed when creating a package that is intended to be consumed using CMake so that header, library, binary, CMake files, etc. all end up in the expected destinations so they can be consumed by another application or library, but I don't seem to see anywhere that this is being done within wxWidgets? For reference, there is a project which demonstrates this setup on GitHub here which many different C and C++ projects incorporate. Is there something I am missing here, or is this not something that is currently supported?
Glad to hear that you are open to community contributions though! Hunter is a pure CMake package management system that is intended to make integrating with third party libraries as simple and hands off as possible by building, and caching dependencies automatically with versioning, and so forth. Updating to new versions is very painless and there is virtually no environment setup at all for dealing with third party libraries which I always think is fantastic. Do you think that you might be interested in adopting support for this system as an optional alternative to make wxWidgets easier to consume as an external package? I'd be happy to help with this contribution if you'd like! I've managed to mostly complete this process, and set it up so that it can be toggled on as needed with full backwards compatibility for how the project would build normally. Let me know what you think!
Thank you again for all of your feedback though, really appreciate the support.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Maarten
Is there something I am missing here, or is this not something that is currently supported?
No, you are correct. We currently do not distribute config files, but rely on FindwxWidgets. We did add exported target files recently, but no config files yet.
install.cmake installs files in include, lib, and bin, similar to what automake does.
And as Vadz said, any PR is welcome.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.