Compiling slic3r from source is a total pain. I somehow got it to compile with the 5.24 64 bit version of strawberry perl, but it crashed every time I ran it. Now I’m trying the 5.22 32 bit version and it fails to compile (some unresolved boost:: symbols or something).
This stuff really isn’t meant to run on Windows.
(fyi the reason I’m compiling from source is all the pre-packaged dev versions are missing AMF support, missing xml::sax)
How open source is something if someone of your intelligence level can’t get it to compile?
Eh, Slic3r can be a pain to compile for sure. Cura is way harder to compile on the Mac, to give another example. It’s not open source because it fulfills every whim or desire. Open source developers do it because they want to, and I can tell you that not having it work super well or be easy to use can be frustrating.
When you figure it out, can you document your approach and let us know what the issue was, I’m curious now.
@ThantiK that almost sounds like an insult. But yeah I followed the directions on the wiki, at least the 2nd time. The 5.24 seemed to succeed until I tried running it, then it crashed without any warning.
Now the trouble is looking through the buildscript to find exactly where it’s failing.
I might go back and try the 32bit version of 5.24
@Stephanie_A , I’m saying you’re very intelligent. Anyone who follows you knows that. If YOU can’t manage to get it to compile (someone who has designed multiple machines, etc) – then how can regular joe-schmoe do it? It wasn’t meant to sound insulting.
Lol I know. But hardware is one thing. I choose hardware because software becomes this giant unmanageable mess of libraries and code that has been hacked together so many times that it looks like a dog ate it.
But don’t worry, I appreciate the compliment (i meant to compare slic3r to some other open source project that is impossible to compile).
What kills me is how it’s written in 2 languages. You should never do that. Write it in one, then use an API that allows another language to use it. Mixing languages now makes your prospective developers require to learn 2 dev environments and 2 languages, and manage both. Throw in the dependencies and libs for each and it’s no wonder the web is filled with questions like “how to compile slic3r?” and “slic3r compilation failed, help”
RE: writing it in one language. I could tell you horror stories about major Microsoft Office apps that have been around for 20+ years… 
@Stephanie_A There are valid reasons for writing the slicing engine in a natively-compiled language and implementing the GUI in something else.
Slic3r does it, Cura does it. For comparison, Skeinforge doesn’t and the performance difference is obvious.
With clearly defined, and well documented, interfaces these implementations can be done by development teams with differing and specialised skill-sets.
Don’t forget, many web-UI fronted systems feature a backend written in a different language e.g. Smoothieware.
Addendum: My preference is to use a single natively-compiled language. I don’t like interpreted or JIT-compiled languages. C, C++, Ada or Pascal (I use Lazarus quite a lot) are my preferred ones. I’m also happy to use assembly language when it’s warranted.
Cura is written in 2 languages because it’s 2 projects. The GUI and the Engine. The have very clear different requirements and thus also different programming language requirements.
Saying that they both should be the same language is shortsighted from your end IMHO.
I am a fan of not using an external library unless you really really have to. And I refuse to use anything that requires boost, as that’s always a compile problem unless you are on Linux. (and even then you hit problems)
(Cura for Mac is simply a beast due the the idiocracy that is OSX)
While many projects may use a separate language for the backend and frontend, they should not be distributed as a single package. Slic3rs build scripts for the backend use perl. The build scripts for the frontend use perl, but call the backend which is cpp. It’s all packaged together, so it’s not independent development.
I know why guis are written in a different language (multi platform guis are a devil to do), but it doesn’t make it any easier.
That’s why in Cura the backend and frontend are different executables. You can call/replace/use the backend without touching any of the frontend code.
Rebuilt boost from scratch, now it compiles, but crashes every time I run slic3r. Rolling back versions not helping, different perl versions not helping. I’m now recompiling boost with different settings.
This is seriously messed up.
@Stephanie_A Actually, slic3r is a bunch of Perl modules with an accompanying library accessed through a Perl XS interface.
The compiled code is not general-purpose and intended to be called through XS. It is quite acceptable to bundle them both together.
It’s not going against convention rather it is following Perl conventions. Even on fedora (which is noted for its un-bundling of libraries and package splits) slic3r is a single RPM package.
well, it still doesn’t run. it compiles, but crashes every time I try to run.
You could install fedora 24 on a virtual machine and install slic3r. It has AMF support built in.
Current version is 1.2.9. Do you specifically need a development version?
yes I need the dev version because of some pretty big bugs in the 1.29, like thin wall detection and overextruding on gapfill.