Subject: Re: [bug#50052] [PATCH] Add prusa-slicer

From: Daniel Trujillo Viedma <[email-masked]>
Date: Mon, 16 Aug 2021 22:09:14 +0200

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