[bug#50052] [PATCH] Add prusa-slicer

[bug#50052] [PATCH] Add prusa-slicer

[Daniel Trujillo Viedma]

[-- Attachment #1: Type: text/plain, Size: 2567 bytes --]

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



[-- Attachment #2: 0001-Add-prusa-slicer.patch --]
[-- Type: text/x-patch, Size: 4536 bytes --]

From 522c1904cf62afac25a9d974091211adac760c25 Mon Sep 17 00:00:00 2001
From: Daniel Trujillo Viedma <danihacker.viedma@gmail.com>
Date: Sat, 14 Aug 2021 00:00:55 +0200
Subject: [PATCH] Add prusa-slicer

---
 gnu/packages/engineering.scm                       | 58 ++++++++++++++++++++++
 .../patches/prusa-slicer-backport-fix-5542.patch   | 31 ++++++++++++
 2 files changed, 89 insertions(+)
 create mode 100644 gnu/packages/patches/prusa-slicer-backport-fix-5542.patch

diff --git a/gnu/packages/engineering.scm b/gnu/packages/engineering.scm
index 33c124a2ea..047d99c0af 100644
--- a/gnu/packages/engineering.scm
+++ b/gnu/packages/engineering.scm
@@ -2863,3 +2863,61 @@ for hooking Linux system calls in user space.  This is achieved by
 hot-patching the machine code of the standard C library in the memory of
 a process.")
       (license license:bsd-2))))
+
+(define-public prusa-slicer
+  (package
+    (name "prusa-slicer")
+    (version "2.3.3")
+    (source
+     (origin
+       (method git-fetch)
+       (uri (git-reference
+             (url "https://github.com/prusa3d/PrusaSlicer")
+             (commit (string-append "version_" version))))
+       (sha256
+        (base32 "0w0synqi3iz9aigsgv6x1c6sg123fasbx19h4w3ic1l48r8qmpwm"))
+     (patches (search-patches "prusa-slicer-backport-fix-5542.patch"))))
+    (build-system cmake-build-system)
+    (arguments
+       `(#:configure-flags `("-DSLIC3R_GTK=3")))
+    (native-inputs
+       `(("pkg-config" ,pkg-config)))
+    (inputs
+       `(("perl" ,perl)
+         ("glibc-locales" ,glibc-locales)
+         ("adwaita-icon-theme" ,adwaita-icon-theme)
+         ("boost" ,boost)
+         ("tbb" ,tbb)
+         ("curl" ,curl)
+         ("zlib" ,zlib)
+         ("eigen" ,eigen)
+         ("expat" ,expat)
+         ("libpng" ,libpng)
+         ("mesa" ,mesa)
+         ("glew" ,glew)
+         ("cereal" ,cereal)
+         ("nlopt" ,nlopt)
+         ("openvdb" ,openvdb)
+         ("cgal" ,cgal)
+         ("gmp" ,gmp)
+         ("mpfr" ,mpfr)
+         ("qhull" ,qhull)
+         ("wxwidgets" ,wxwidgets-3.1)
+         ("coreutils" ,coreutils)
+         ("grep" ,grep)
+         ("sed" ,sed)
+         ("openexr" ,openexr)
+         ("glib" ,glib)
+         ("glibc" ,glibc)
+         ("gtk+" ,gtk+)
+         ("pango" ,pango)
+         ("dbus" ,dbus)))
+    (home-page "https://www.prusa3d.com/prusaslicer/")
+    (synopsis "G-code generator for 3D printers (RepRap, Makerbot, Ultimaker etc.)")
+    (description
+     "PrusaSlicer (formerly known as Slic3r Prusa Edition or Slic3r PE) is
+our own in-house developed slicer software based on the open-source project
+Slic3r.  PrusaSlicer is an open-source, feature-rich, frequently updated
+tool that contains everything you need to export the perfect print files
+for your Original Prusa 3D printer.")
+    (license license:agpl3)))
diff --git a/gnu/packages/patches/prusa-slicer-backport-fix-5542.patch b/gnu/packages/patches/prusa-slicer-backport-fix-5542.patch
new file mode 100644
index 0000000000..63d2a45be1
--- /dev/null
+++ b/gnu/packages/patches/prusa-slicer-backport-fix-5542.patch
@@ -0,0 +1,31 @@
+This patch backports a solution for the issue:
+https://github.com/prusa3d/PrusaSlicer/issues/5542
+that causes PrusaSlicer to crash when invoked
+from the command line by means of the $PATH variable.
+This fix is applied in:
+https://github.com/prusa3d/PrusaSlicer/commit/293f85b6cf9b805af93b9f79f5ff878b6d673969
+quite after the release of 2.3.3, so this backport is needed.
+
+diff --git a/src/PrusaSlicer.cpp b/src/PrusaSlicer.cpp
+index b0df2c99a..31e30af81 100644
+--- a/src/PrusaSlicer.cpp
++++ b/src/PrusaSlicer.cpp
+@@ -28,6 +28,7 @@
+ #include <boost/nowide/cenv.hpp>
+ #include <boost/nowide/iostream.hpp>
+ #include <boost/nowide/integration/filesystem.hpp>
++#include <boost/dll/runtime_symbol_info.hpp>
+ 
+ #include "unix/fhs.hpp"  // Generated by CMake from ../platform/unix/fhs.hpp.in
+ 
+@@ -612,7 +613,9 @@ bool CLI::setup(int argc, char **argv)
+     // Detect the operating system flavor after SLIC3R_LOGLEVEL is set.
+     detect_platform();
+ 
+-    boost::filesystem::path path_to_binary = boost::filesystem::system_complete(argv[0]);
++    // See Invoking prusa-slicer from $PATH environment variable crashes #5542
++    // boost::filesystem::path path_to_binary = boost::filesystem::system_complete(argv[0]);
++    boost::filesystem::path path_to_binary = boost::dll::program_location();
+ 
+     // Path from the Slic3r binary to its resources.
+ #ifdef __APPLE__
-- 
2.11.0

[bug#50052] [PATCH] Add prusa-slicer

[Xinglu Chen]

[-- Attachment #1: Type: text/plain, Size: 7131 bytes --]

On Sat, Aug 14 2021, Daniel Trujillo Viedma wrote:

> 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.

That’s probably a good idea, in case upstream changes the default value
in the future.

> * 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
>
>
> From 522c1904cf62afac25a9d974091211adac760c25 Mon Sep 17 00:00:00 2001
> From: Daniel Trujillo Viedma <danihacker.viedma@gmail.com>
> Date: Sat, 14 Aug 2021 00:00:55 +0200
> Subject: [PATCH] Add prusa-slicer
>
> ---

The commit message should be in the GNU ChangeLog format, see the commit
log for examples, or check the manual.

  <https://www.gnu.org/prep/standards/standards.html#Change-Logs>
  
>  gnu/packages/engineering.scm                       | 58 ++++++++++++++++++++++
>  .../patches/prusa-slicer-backport-fix-5542.patch   | 31 ++++++++++++

This patch should also be added to the gnu/local.mk file.

>  2 files changed, 89 insertions(+)
>  create mode 100644 gnu/packages/patches/prusa-slicer-backport-fix-5542.patch
>
> diff --git a/gnu/packages/engineering.scm b/gnu/packages/engineering.scm
> index 33c124a2ea..047d99c0af 100644
> --- a/gnu/packages/engineering.scm
> +++ b/gnu/packages/engineering.scm
> @@ -2863,3 +2863,61 @@ for hooking Linux system calls in user space.  This is achieved by
>  hot-patching the machine code of the standard C library in the memory of
>  a process.")
>        (license license:bsd-2))))
> +
> +(define-public prusa-slicer
> +  (package
> +    (name "prusa-slicer")
> +    (version "2.3.3")
> +    (source
> +     (origin
> +       (method git-fetch)
> +       (uri (git-reference
> +             (url "https://github.com/prusa3d/PrusaSlicer")
> +             (commit (string-append "version_" version))))

The ‘file-name’ field should be set to

  (file-name (git-file-name name version))

to give the git checkout, in the Guix store, a more descriptive name,
otherwise its name is

  /gnu/store/hc1slayzjz8xrw24q8wzgcs6xrzfk74q-git-checkout

which doesn’t really say much.  This usually only applies if some kind
of VCS repository is used, and not if ‘url-fetch’ is used.

> +       (sha256
> +        (base32 "0w0synqi3iz9aigsgv6x1c6sg123fasbx19h4w3ic1l48r8qmpwm"))
> +     (patches (search-patches "prusa-slicer-backport-fix-5542.patch"))))
> +    (build-system cmake-build-system)
> +    (arguments
> +       `(#:configure-flags `("-DSLIC3R_GTK=3")))
> +    (native-inputs
> +       `(("pkg-config" ,pkg-config)))
> +    (inputs
> +       `(("perl" ,perl)
> +         ("glibc-locales" ,glibc-locales)
> +         ("adwaita-icon-theme" ,adwaita-icon-theme)
> +         ("boost" ,boost)
> +         ("tbb" ,tbb)
> +         ("curl" ,curl)
> +         ("zlib" ,zlib)
> +         ("eigen" ,eigen)
> +         ("expat" ,expat)
> +         ("libpng" ,libpng)
> +         ("mesa" ,mesa)
> +         ("glew" ,glew)
> +         ("cereal" ,cereal)
> +         ("nlopt" ,nlopt)
> +         ("openvdb" ,openvdb)
> +         ("cgal" ,cgal)
> +         ("gmp" ,gmp)
> +         ("mpfr" ,mpfr)
> +         ("qhull" ,qhull)
> +         ("wxwidgets" ,wxwidgets-3.1)

> +         ("coreutils" ,coreutils)
> +         ("grep" ,grep)
> +         ("sed" ,sed)
> +         ("glibc" ,glibc)

These packages are already included in the ‘cmake-build-system’ by
default, no need to add them explicitly.

> +         ("gtk+" ,gtk+)
> +         ("pango" ,pango)
> +         ("dbus" ,dbus)))
> +    (home-page "https://www.prusa3d.com/prusaslicer/")
> +    (synopsis "G-code generator for 3D printers (RepRap, Makerbot, Ultimaker etc.)")
> +    (description
> +     "PrusaSlicer (formerly known as Slic3r Prusa Edition or Slic3r PE) is
> +our own in-house developed slicer software based on the open-source project
> +Slic3r.  PrusaSlicer is an open-source, feature-rich, frequently updated
> +tool that contains everything you need to export the perfect print files

Nit: “perfect” sounds a bit too much like marketing speak; instead of
“to export the perfect print files”, I suggest “to export to print
files”.

WDYT?

> +for your Original Prusa 3D printer.")
> +    (license license:agpl3)))

According the the LICENSE file, this should be agpl3+ (grep for “any
later version”).

  <https://github.com/prusa3d/PrusaSlicer/blob/master/LICENSE>


I didn’t manage to build the package because my machine ran out of
memory, but I assume that it built fine for you.  :-)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 861 bytes --]

[bug#50052] [PATCH] Add prusa-slicer

[Ivan Gankevich]

>Hi! I'm Daniel Trujillo,

Hello, Daniel!


>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).

I have submitted “prusa-slicer” together with “libigl” on July 23 but did’t get any
response: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=49713

We should probably check prior submissions to not duplicate our effort.


>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]).

This issue is fixed by adding “-DSLIC3R_FHS=1” to #:configure-flags.
No need to patch the source code.


>* 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.

Set it to ON and you don’t have to patch the code.


>I hope everything is in order, I'm looking forward to see your 
>comments, and hope I can start contributing more packages to Guix!!

Prusa slicer bundles a lot of third-party libraries. Most of them contain
prusa-specific modifications, but some don’t. “libigl”, “eigen” and “hidapi” can be
unbundled, so that we can use versions of these libraries provided by Guix.

>+         ("cereal" ,cereal)

You need to patch “cereal” library definition in order for Prusa slicer to find
this library. I have included this in my patch as well.


Regards,
Ivan

[bug#50052] [PATCH] Add prusa-slicer

[Daniel Trujillo Viedma]

Hi, Ivan!


You're completely right, I should have to searched more thoroughly any 
ongoing effort packaging prusa-slicer. At this point, the best thing I 
should do is to send an email to the list to discard my package and 
encourage to take a look at yours, since are way more advanced than mine.


You are also right with the -DSLIC3R_FHS=1. I thought that that will 
make the executable look for the resources outside the /gnu/stare 
folder, where nothing would be found, but it works, can you briefly 
point me to what is happening? Thank you so much!


El 16/8/21 a las 9:49, Ivan Gankevich escribió:
>> Hi! I'm Daniel Trujillo,
>
> Hello, Daniel!
>
>
>> 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).
>
> I have submitted “prusa-slicer” together with “libigl” on July 23 but 
> did’t get any
> response: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=49713
>
> We should probably check prior submissions to not duplicate our effort.
>
>
>> 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]).
>
> This issue is fixed by adding “-DSLIC3R_FHS=1” to #:configure-flags.
> No need to patch the source code.
>
>
>> * 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.
>
> Set it to ON and you don’t have to patch the code.
>
>
>> I hope everything is in order, I'm looking forward to see your 
>> comments, and hope I can start contributing more packages to Guix!!
>
> Prusa slicer bundles a lot of third-party libraries. Most of them contain
> prusa-specific modifications, but some don’t. “libigl”, “eigen” and 
> “hidapi” can be
> unbundled, so that we can use versions of these libraries provided by 
> Guix.
>
>> +         ("cereal" ,cereal)
>
> You need to patch “cereal” library definition in order for Prusa 
> slicer to find
> this library. I have included this in my patch as well.
>
>
> Regards,
> Ivan

[bug#50052] [PATCH] Add prusa-slicer

[Ivan Gankevich]

>You're completely right, I should have to searched more thoroughly any 
>ongoing effort packaging prusa-slicer. At this point, the best thing I 
>should do is to send an email to the list to discard my package and 
>encourage to take a look at yours, since are way more advanced than mine.

Thanks! Lets hope it will be accepted soon.


>You are also right with the -DSLIC3R_FHS=1. I thought that that will 
>make the executable look for the resources outside the /gnu/stare 
>folder, where nothing would be found, but it works, can you briefly 
>point me to what is happening? Thank you so much!

That is a good question for prusa slicer developers :-) My guess is that using file system hierarchy standard (-DSLIC3R_FHS=1) means that the project uses default procedure to install the package which is modified by Guix to install it to /gnu/store directory. But when this option is disabled the package is installed in the same directory using non standard procedure about which Guix knows nothing. It could also be a bug in prusa slicer build files.

bug#50052: [PATCH] Add prusa-slicer

[Daniel Trujillo Viedma]

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.