search

slic3r / Slic3r

Open Source toolpath generator for 3D printers
https://slic3r.org/
GNU Affero General Public License v3.0
3.33k stars 1.3k forks source link

Offer: restructure the Perl support into new repo, put that on CPAN #4782

Open mohawk2 opened 5 years ago

mohawk2 commented 5 years ago

Hi, I'm a Perl person and current maintainer of ExtUtils::CppGuess, which recently gained clang and other support.

I noticed this project uses that, but generally says the Perl stuff is deprecated. Also, Slic3r seems not to be available on CPAN, is that a conscious choice?

My thought is to make this main repo be C++ only, with a capability to build a dynamic library. Then the Perl stuff could be separated out into a more conventional CPAN distro in another repo, that consumes an Alien::* one to get/build the library, and not have a Build.PL that runs cpanm, which is not the normal or currently-considered "best" practice.

If that seems useful, let me know and I will assemble a PR!

lordofhyphens commented 5 years ago

I don't know the design decisions well from back then. I am not myself a Perl person, but @alranel is.

Slic3r at present is moving away from Perl. Most of the slicing functionality is indeed in libslic3r (which should probably have an Alien:: package).

A lot of my effort has been to pull the UI out of perl as well, so I have zero interest in maintaining the XS bindings.

lordofhyphens commented 5 years ago

Once the I have support working I would be more amenable to such a refactor.

mohawk2 commented 5 years ago

So would it be useful to start by isolating the libslic3r into a separate repo and CPAN Alien distro, and consume that within current repo?

lordofhyphens commented 5 years ago

@mohawk2 Probably? I mean, it's most useful to me to not have any Perl or CPAN usage at all in Slic3r. It has been a headache for me for years (not being particularly interested or skilled with Perl and its ecosystem).

In organizational terms, splitting the repo involves also splitting the issue tracker (afaik), which I'm not particularly keen on doing. I already get issues pertaining to Slic3r-Manual here.

So long as it's someone else maintaining it, I'm fine with someone else packaging the perl bindings and making libslic3r available as a CPAN distribution.

I'll be in #slic3r on freenode for the next few hours if you want to chat realtime.

mohawk2 commented 5 years ago

My summary of the IRC conversation, plus further research: it's still not entirely clear which bits of code etc to split off first. The top-level perl tests are still important to exercise the C++ code, and would need converting to C++ (which tests live under src/test).

My reading is also that the CLI is running a Perl script, which then drives the other C++. If the Perl is to get externalised, that would need to change.

My first move is to reorganise the building of the Perl stuff, which from the wiki seems to be what drives the rest of the build. The current version does lots of things that aren't normal for module-building, so I've stripped it down somewhat - still a work in progress, in a branch on my fork.