[PATCH] Add prusa-slicer

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:

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.

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.

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

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

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

in the future.

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

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

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.

These packages are already included in the ‘cmake-build-system’ by

default, no need to add them explicitly.

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?

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

Hello, Daniel!

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.

This issue is fixed by adding “-DSLIC3R_FHS=1” to #:configure-flags.

No need to patch the source code.

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

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.

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

Sorry, forgot to include debbugs...

El 15/8/21 a las 13:02, Xinglu Chen escribió:

Great point, I'm doing it!

Sorry!!! I have yet to be familiarized with that format, I'll see this

article and examples before submitting the fixes, thanks for notice!

Thanks for noticing, it will be added in the next submission.

I thought the checkout directory was temporary, but yes, even in the

"origin reference" section of the Manual it says that it's a good idea

to set it up when working with VCS. Added!

Yes, I've verified that the package still builds successfully and the

program launches. Thanks!

Absolutely agree. "Perfect" slicer is far from the state-of-the-art. I

took this description from their web page, but if we can adapt it to be

more objective, I would say: "PrusaSlicer (formerly known as Slic3r

Prusa Edition or Slic3r PE) is a 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

print files for your 3D printer.". Is this OK?

I'm not sure. Probably you guys know more than me about licenses, but it

seems to me that this is only AGPL3, because if I `rgrep "any later

version"` the entire source code tree, I get 128 hits, mostly from

dependencies. And the 3 matches from the LICENSE file are on a

conditional voice (""If the Program specifies that a certain numbered

version [...] "or any later version" applies to it, you have the option

.......""), and the last match is just the instructions that says to put

the notice at the start of every source code file (which I think they

didn't do. rgrep "GNU Affero General Public" gives me 57 coincidences,

mostly from resources, and no one of them mentions "or any later

version", so I think it's only AGPL-3).

Yes, I have suffered this also. To build this in a 16GB RAM machine I

had to low the number of cores to 2 (guix build -M1 -c2 prusa-slicer).

This prevents more than 2 programs running at the same time, and the

memory doesn't get full. I think the hardest part is at the end of the

process, when the GUI executable is being linked.

I've seen in some packages that there's a comment with the package size.

Maybe I'll do the same as a warning that the build process can take up

all the RAM available easily.

Thank you for your feedback!

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ó:

Thanks! Lets hope it will be accepted soon.

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.

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.