-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Retrieve required flags from Libnest2D target #3
base: main
Are you sure you want to change the base?
Retrieve required flags from Libnest2D target #3
Conversation
Instead of setting include paths and libs manually, just use the imported target. All required properties are set Libnest2DTargets.cmake. This also adds the otherwise missing libpthread to the link libraries.
@Ghostkeeper This PR is open for some time. Is this one on your board to be reviewed? |
Yeah, I've seen it. There are still older ones I'd like to handle first. |
Can this be merged, and a 4.9.0 release tagged? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We're making a build environment that includes this change on our build servers, to properly test it. The changes themselves look good to me (and work locally in my own environment).
4.9.0 and 4.9.1 have been tagged. They are the same. I think this repository wasn't in @jellespijker's script yet when he tagged them.
The merge conflict is resolved on the https://github.com/Ultimaker/pynest2d/tree/StefanBruens-cmake_use_imported_target branch. |
This seems to fail to build, on Windows only. We're getting this result:
The package config file does exist, in This is the snippet from the log where libnest2d was installed (showing nothing out of the ordinary):
So perhaps this change requires a change to the way libnest2d is found as well? |
On Linux, Module mode (i.e. |
Well, that's just replacing the find procedure with a manual hard-coded path in the cura-build-environment source. I don't think that's something we want to merge then, since it wouldn't be cross-platform and would lock the build script to that computer. Some of our requirements are:
The first requirement is currently not met in this PR for this repository. Your suggestion would break the second requirement for cura-build-environment as a whole. The real solution would be to make sure that the CMake script of libnest2d is properly providing a config file also on Windows. However we're not about to debug that ourselves, since the current solution is working fine and is unlikely to require frequent maintenance. The maintenance burden with our current solution (and why your PR would be better) is only a problem if the dependencies of libnest2d change, which is not likely to happen frequently. We can't justify the time investment to fix the bug in libnest2d, considering the slim benefit we'd get in the reduced maintenance (and somewhat nicer code). |
I completely debugged it for you already. It does not hardcode the path to libnest2d, it provides the path of your build/install prefix. Obviously you have that already set somewhere, otherwise it would not be able to find the headers. Apparently it already works on Linux and MacOS, as you have confirmed. If an existing Libnest2DConfig.cmake is not found on Windows, then your Windows build setup is broken, and with the custom Findlibnest2d.cmake you are papering over it. |
Also, the current setup does not fulfill your second requirement: The specified link libraries omit Boost, which causes a linker error later, as some symbols from Boost transitively required by libnest2d can not be found. |
We provide all libraries with the same installation prefix as cura-build-environment itself, where it should be finding libnest2d: This is ostensibly not enough.
Indeed, I see this as the real problem. Now we could make an attempt to fix libnest2d in a fork. Or we could keep it as is and paper over their bug. Since papering over their bug is already a working workaround, it doesn't need time investment on our side. |
X:/env/CURA-8240_pynest2d_transitive_dependencies/inst/lib/cmake/Libnest2D/Libnest2DConfig.cmake can be broken down to (with CMAKE_INSTALL_PREFIX=X:/env/CURA-8240_pynest2d_transitive_dependencies/inst/):
This matches (https://cmake.org/cmake/help/latest/command/find_package.html#search-procedure): but none of the search paths for Windows (W, W/U).
Filed an issue for libnest2d: tamasmeszaros/libnest2d#36 You can either patch libnest2d, or extend the search patch in pynest2ds ExternalProject_Add:
|
The current code breaks your second requirement. What are you going to do about it? |
Since the current code works on a developer's computer and our build servers, I think you mean that it doesn't work on an external contributor's computer. At least, not for you, because we did have two other external contributors to this repository for which it did work. I think the best approach would be to make a change to libnest2d so that it installs the config file to the proper directory on Windows. But both fixes can be applied for maximum compatibility. Would you like to edit your PR? |
I think the problem on Windows is caused by the non-typical installation path. Normally, libnest2d would go into something like See https://gitlab.kitware.com/cmake/cmake/-/issues/18453#note_470670 , paragraph "Side note ..." For curas build, the install directory should be changed from |
Instead of setting include paths and libs manually, just use the imported target.
All required properties are set Libnest2DTargets.cmake.
This also adds the otherwise missing libpthread to the link libraries.