Help porting slicer - wxWidgets environment variables
I'm trying to port the slicer code to freebsd, and am not very familiar with cmake.
When I do a make configure, I get the following message:
CMake Error at /usr/local/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:137 (message):
Could NOT find wxWidgets (missing: wxWidgets_LIBRARIES
wxWidgets_INCLUDE_DIRS) (Required is at least version "3.1")
Can someone tell me what the format for wxWidgets_LIBRARIES is and where these are supposed to be set?
At the moment I added an include of freebsd.inc in the main CMakeLists.txt and in there did the following:
set(wxWidgets_INCLUDE_DIRS "/usr/local/lib")
set(wxWidgets_LIBRARIES "libwx_baseu")
There are a boatload of libwx_*_3.1.so libraries in /usr/local/lib; do I need to list them all, and do I need the leading libwx_ and the trailing _3.1.so?
Thanks for any hints.
RE: Help porting slicer - wxWidgets environment variables
This is more of a FreeBSD development issue than a PrusaSlicer issue. wxWidgets is a separate library, and you need to have that set up properly and working. I don't use FreeBSD myself (did play around with OpenBSD years ago) but there seems to be documentation on doing the necessary setup available. No idea how up-to-date that info is though, or if the version of wxWidgets is current. There is a porter's guide for FreeBSD that might be helpful.
and miscellaneous other tech projects
He is intelligent, but not experienced. His pattern indicates two dimensional thinking. -- Spock in Star Trek: The Wrath of Khan
RE: Help porting slicer - wxWidgets environment variables
There's also the concern that if you can't get the build environment working; changing the code is going to be extremely problematic. Prusa code is not the most robust, is poorly documented, and already laden with traps.
RE: Help porting slicer - wxWidgets environment variables
The CMake build system tries to execute a wx-config shell script. You have to configure your PATH environment variable to point to wx-config.
> Prusa code is not the most robust, is poorly documented, and already laden with traps.
Interesting.
RE: Help porting slicer - wxWidgets environment variables
> The CMake build system tries to execute a wx-config shell script. You have to configure your PATH environment variable to point to wx-config.
Thanks, that's a place to start... Is there supposed to be a default/sample wx-config supplied with the tarball? I don't see one.
Is there a list somewhere of what variables are expected to be set in wx-config and a description of their purpose?
RE: Help porting slicer - wxWidgets environment variables
the wx-config script is produced by the wxwidgets build process. You should have one.
RE: Help porting slicer - wxWidgets environment variables
Making some progress. I can get it to build but almost certainly not correctly. The code is full of things like:
#if defined _WIN32
...
#elif defined(__linux__)
...
#elif defined __APPLE__
...
occasionally there is a
#if defined(__NetBSD__) || defined(__OpenBSD__) || defined(__bsdi__) || defined(__DragonFly__)
or a
#ifdef __unix__
or a
#ifdef __WXGTK__ (for wxwidgets toolkit mapped to gtk)
1. It looks like many of the uses of __linux__ are actually gtk issues which it seems should be common to linux and bsd under gtk on X. Is there some reason __linux__ was used and not __WXGTK__? If one keeps the __linux__ tests in these cases, it's necessary to add "|| defined(__FreeBSD__) || defined(__NetBSD__)..." etc. Is there a "BSD" sym that encompasses the various bsd variants?
2. If __linux__ is defined, is __unix__ also defined? If any of the __*BSD__ syms are defined, is __unix__ also defined?
3. What's the relationship between the _WIN32, __APPLE__, __unix__ syms i code and the WIN32, APPLE, UNIX, XCODE syms in the CMakeLists.txt file? Are any/all of these case sensitive? How is CMAKE_SYSTEM_NAME, which may be "Linux" (on linux), related to the above syms?
RE: Help porting slicer - wxWidgets environment variables
We were not really targeting any other Unix platform than Linux and OSX. I am not sure about the wxWidgets support on freebsd, you should verify that first.
I suppose the best way would be to replace the _linux_ symbol with some more generic "UNIX" symbol, we just need to make sure it is not set for OSX. We may set this symbol either in CMake or in some common header.
Please continue this discussion on the PrusaSlicer github issue tracker. Thank you.
> Is there some reason __linux__ was used and not __WXGTK_?
At the UI level, we likely could use __WXGTK__. we don't link the wxWidgets library to the non-ui modules, so some other macro should be used there.
> Is there a "BSD" sym that encompasses the various bsd variants?
I don't know. We will be glad if you contribute with your investigation.
> If __linux__ is defined, is __unix__ also defined? If any of the __*BSD__ syms are defined, is __unix__ also defined?
Again, we don't know. Please investigate.
> What's the relationship between the _WIN32, __APPLE__, __unix__ syms i code and the WIN32, APPLE, UNIX, XCODE syms in the CMakeLists.txt file? Are any/all of these case sensitive? How is CMAKE_SYSTEM_NAME, which may be "Linux" (on linux), related to the above syms?
Again, I would have to look up. I think the underscored symbols are intrinsically generated by the compiler. The others are either generated by the CMake, but they as well may be defined by some include.