On 24.04.25 00:24, Noé Lopez wrote:
"nomike (they/them)"<nom...@nomike.com> writes:
Hi nomike!
Thanks for your efforts, here are my thoughts but please note that I am
not too experienced with Guix so feel free to disagree and make sure to
doubt!
Hi Noé!
I appreciate you stepping in here. I started using guix a few weeks ago
after Danny dragged me to FOSDEM and constantly praised it since then.
He helped me a lot with this package already (ang guix and emacs in
general, so I added him to this email as well.
prusaslicer-2.6.0-dont-force-link-to-wayland-and-x11.patch doesn’t seem
like a good idea in our case. Since you mention it is from Gentoo, they
might have done that because they want to add the libraries with USE
flags but in the case of Guix we want to support all usages (aka all USE
flags).
For the cgal 6.0 patch, it would be better if we could use a version of
CGAL that upstreams expect, since this is a big patch (so big
maintaining burden).
For the other patches, I’m not really sure what they are for so please
add comments in them to explain.
Thanks for the input. I will have a look at those patches again. My plan
is though, to first get the thing building successfully and then I want
to look at cleaning everything up, including the patches.
For example I'm pretty sure it's not necessary to add
=find_package(hidapi REQUIRED)= in both =src/slic3r/CMakeLists.txt= AND
=src/CMakeLists.txt=.
But I just had an idea:
The component where the linker complains about not finding hidapi is
=tests/slic3utils=.
I found a piece in the
[[https://github.com/libusb/hidapi/blame/master/BUILD.cmake.md#using-hidapi-in-a-cmake-project][hidapi
documentation]] which says to use this in CMake:
#+BEGIN_EXAMPLE c
target_link_libraries(my_application PRIVATE hidapi::hidapi)
#+END_EXAMPLE
So I've added another substitute to the package definition:
#+BEGIN_EXAMPLE scheme
(substitute* "tests/slic3rutils/CMakeLists.txt"
(("target_link_libraries\\(\\$\\{_TEST_NAME\\}_tests
test_common")
"find_package(hidapi
REQUIRED)\ntarget_link_libraries(${_TEST_NAME}_tests test_common")
(("libseqarrange")
"libseqarrange hidapi::hidapi"))
#+END_EXAMPLE
I'm currently running a build, but this will also take quite some time
on my machine, so I will know whether that did the trick when I get up
tomorrow.
Please send your logs as attachment!
I'm collecting the logs of the build I just started in a file and will
attach it tomorrow if the build still fails.
CMake can use non-cmake dependencies, so you should be able to get away
with using normal hidapi and the find_package() call you have.
Danny told me so, but nontheless, as we didn't understand what was going
on at first, we tried switching hidapi o CMake just in case this is
causing issues.
At the end it was this substitude which fixed the compilation error we
had on Monday:
#+BEGIN_EXAMPLE scheme
(substitute* "src/slic3r/GUI/Mouse3DController.hpp"
(( "#include \"hidapi.h\"")
"#include \"hidapi/hidapi.h\""))
#+END_EXAMPLE
Also, there are a lot of trailing spaces in your patch. Make sure to
clear them up!
I have messed around with this to a degree where I don't feel
comfortable with the code anymore. I will get everything up and running
and will then start from a fresh branch, copying over the package
definition, running =guix lint= and = guix style= and doing all the
necessary due diligence, to be able to submit clean patches. I will also
re-visit the =hidapi-cmake= package to figure out whether this is really
necessary and will have a look at whether the dependencies of
prusa-slicer look okay.
I also saw that there was a patch recently for the prusa-slicer@7.4.3
package, fixing some segfaults during startup and I will have a look
whether this is needed for the new version as well.
I will keep you posted tomorrow, and if I don't find enough time during
the day, I will hopefully be able to write you in the evening (I'm
located in Europe/Vienna (UTC+01:00)).
Thanks again and have a nice day as well!
nomike
