GNU bug report logs -
#50052
[PATCH] Add prusa-slicer
Previous Next
Full log
Message #17 received at 50052 <at> debbugs.gnu.org (full text, mbox):
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
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.