[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