GNU bug report logs -
#50052
[PATCH] Add prusa-slicer
Previous Next
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
Your bug report
#50052: [PATCH] Add prusa-slicer
which was filed against the guix-patches package, has been closed.
The explanation is attached below, along with your original report.
If you require more details, please reply to 50052 <at> debbugs.gnu.org.
--
50052: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=50052
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
Closing this in favor of Ivan's 49713
(https://debbugs.gnu.org/cgi/bugreport.cgi?bug=49713), which is more
complete and advanced than mine.
Thanks to Xinglu Chen and Ivan Gankevich (and everyone interested) for
their time and their valuable feedback, I learned a lot.
Hope to see you soon with a (hopefully not WIP) new package!
Cheers,
Dani.
[Message part 3 (message/rfc822, inline)]
[Message part 4 (text/plain, inline)]
Hi! I'm Daniel Trujillo,
This is my first-time-ever contribution to GNU Guix, so please, don't
hold any nitpick to yourself!! :)
I don't know if these kind of packages are of interest, but this is
PrusaSlicer [0], a software to prepare 3D printings (hence I put it in
engineering.scm).
The packaged version, 2.3.3 is the latest stable available at this
moment. But this version has as important problem [1]: It cannot be
invoked just naming the executable (through $PATH), because then, it
can't locate the resources directory. I learned **the hard way** that
the fix was applied *after* the release of the 2.3.3 version, so I
decided to backport the fix adding a patch because it's a show-stopper
to have to type the path to the executable in /gnu/store/... That's the
reason why the patch attached to this email contains, not only the
additions to engineering.scm, but also a patch that implements the
solution in the version 2.3.3 codebase (It's quite simple, it uses a
boost function to determine the path to the executable rather than
relying on argv[0]).
Known improvable things:
* It's configured to use GTK3. After many attempts to compile it under
GTK2 in a guix environment, sometimes it detected GTK right away, and
some ether times I had to add more includes. It wasn't quite reliable
and, according to the convention followed in gtk+ packages, probably it
would be better that prusa-slicer uses GTK3, and a hypothetical future
GTK2 version would be called prusa-slicer-gtk2.
* In order for the above $PATH issue fix to work, it's crucial that the
cmake variable SLIC3R_FHS is set to off. This is the default value
according to the CMakeLists.txt, but because it's so important, probably
it should have been included in the configure-flags argument? Just for
clarity.
* Currently, the version displayed in the title bar is
"....2.3.3+UNKNOWN". This is because of another cmake option not set. It
doesn't have any influence in the software, as far as I know, but it's
arguably ugly. The version I currently use, doesn't display that in the
title bar, but it does in the "About" window, and it says
".....2.3.3+linux-64". Maybe something like "GNU Guix" would be
prettier. But if I have to include the arch, I would have to dig deeper
into package definitions ^_^'''
I hope everything is in order, I'm looking forward to see your comments,
and hope I can start contributing more packages to Guix!!
Cheers,
Dani.
[0] https://www.prusa3d.es/prusaslicer/
[1] https://github.com/prusa3d/PrusaSlicer/issues/5542
[0001-Add-prusa-slicer.patch (text/x-patch, attachment)]
This bug report was last modified 4 years and 6 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.