Best branch to pull for doing testing?

[DoubleStrike]

Hi there,

I have seen a lot of merges being done on the dev branch, but much more consistent commits on the dev-nightly branch. If I was interested in cloning down a branch to be able to just test with the current state of the build, would dev-nightly be the right branch to use for that?

[supermerill]

yes.
. dev is my dev branch, currently on the 2.7 debug (with slic3r skin).
. dev-nightly, it the current 2.5 updates (with Susi skin), it's used to create nightly. note that often, i force-push it to fix a previous commit.
. master-dev is the latest beta release. I don't force-push this one (unless maybe if really necesary for a version jump)
. master is the latest stable release.

[DoubleStrike]

I see. I did not realize that dev-nightly was based on 2.5. So given what you are saying, I think the dev branch will likely be the one for me to play around with. Thanks!

[Paradisebaker]

github-noob question here, if I wanted to also play around with the new 2.7 dev, how do I build this for Windows?
or is the link for slic3r in the dev branch (fresh build) the one where I can check the latest ?
thanks for forgiving my ignorance

[DoubleStrike]

github-noob question here, if I wanted to also play around with the new 2.7 dev, how do I build this for Windows? or is the link for slic3r in the dev branch (fresh build) the one where I can check the latest ? thanks for forgiving my ignorance

I folllowed the PrusaSlicer build instructions and just triaged any errors that came up after the fact.

[Jbori347]

I tried to build it but must be doing something wrong

[supermerill]

For building, it's best to folow the doc/ how to build.
For linux, the shell script should work.
for windows:
install : visual studio 2019 (not 2022, not compatible with 2.5 boost), cmake, git

• git clone
• create a superslicer/deps/build_25 dir
• create a c:\local\superslicer_deps_25 dir
• open a cmd and go to superslicer/deps/build_25
• cmake .. -G "Visual Studio 16 2019" -DDESTDIR="c:\local\superslicer_deps_25"
• open the .sln in deps/build_25 and compile the solution, it should finish without any bug. You may have to modify things if you have vs 2022 installed (see doc in the master_dev branch)
• create a build superslicer/build_25
• open a cmd and go to superslicer/build_25
• cmake .. -G "Visual Studio 16 2019" -DCMAKE_PREFIX_PATH="c:\local\superslicer_deps_25\usr\local"
• open the .sln in build_25
• now you can compile. the project should be already on Slic3r_app_console (the one to launch the slicer with a console)
• after the first compile, it should fail to launch, as there is some dll missing (libgmp-10.dll libmpfr-4.dll), copy them from a release to your build_25/src/[Debug/RelWithDebinfo] dir
• relaunch, should work.

[Jbori347]

would that be the same process for the 2.7 dev build?

[supermerill]

yes.
And visualstudio 2022 should be possible then.

[mstrakl]

Can you please prepare a Linux .AppImage for the current 2.7 dev version?

[Paradisebaker]

I definitely dont want to burden more work on you than you already have and I really appreciate all the hard work you are doing.
But for simple users like me, who just enjoy the results of your work, it would be super great, if there were builds for pre-release versions. While your instructions above seem straightforward, to me it is daunting and I would prefer a simple .zip to download and start.
Orcaslicer has some automatic nightly builds for non-released code (https://github.com/SoftFever/OrcaSlicer/releases/tag/nightly-builds).

Since I am not a developer, I have no way of judging how much additional work or resources this would mean.
But having this maybe on a weekly basis (even with all the bugs that still exists in dev versions) would be already super cool.
And it would allow your huge fan base to get a glimpse of the upcoming version.
I am sure that everybody would be aware that this should not be used for production, but for playing around.

If this would be too much work for you or would be taking too many resources away from your development, then please forget I even asked. (However, maybe this could be done by some of the other community members who are not as inapt as me?)

Thanks again for this great piece of software.

[lessbones]

Honestly Paradisebaker, I think you've kind of written up a good explanation of exactly why he's not releasing it in this manner yet. There are nightly builds for the other improvements that have been made in tandem to the 2.5 base version on the git actions page (as explained on the main page) but I think the entire point of not releasing the dev version in an easy to use "play around" manner for non-developers is because of the extra headaches it would introduce when people start asking or complaining about why such-and-such is broken or crashing. Therefore the ability to build the 2.7 base yourself is the "you must be this tall to ride this ride" barrier to entry until he's ready to unleash the unwashed masses upon the new code.

That said, I would also love to play around with it-- if I can successfully build it myself I'll send you a binary, but otherwise, we've just gotta wait till he's ready.

[Paradisebaker]

That is a very fair point you make.
in my naivity, I assumed that everybody would take it for what it is, a dev branch without any promises. (I would).
but you are probably right, many people might then cause a lot of negative vibes and steal energy from the development.
as I said in my previous post, nothing is further from my mind than to hinder Merril in his great work.
thanks for pointing out this side of the medal.

[kainz]

I see the branches in motion is a little different currently, what branches are what nowadays?

[supermerill]

master: 2.5.59.13
master_25: 2.5.59.13
master_27: wrong position when the 2.7 alpha will be out, it will reference it.
dev: my current 2.7 unstable that is forced-pushed every week. (slic3r skin)
master_dev: was in a wrong position, now set it back to 2.7.60.1 beta build
nightly_dev: currently on a random 2.7 commit, or the 2.5.60 whatever needs building. don't use it.

note that the dev branch has the "slic3r-skin" and can be pushed to slic3r git.
The "master_XXX" should point to the superslicer-themed one, made for the superslicer git. I also try to not force-push them.
I work on the slic3r branch and merge with the superslicer skin when I need to ask it to compile.

[kainz]

Thanks for the update! Whats the difference between the skins? UI widgets, just look & feel?

[supermerill]

Whats the difference between the skins?

• github integration (like the build script, readme)
• color: yellow-brown vs blue
• name: Slic3r vs SuperSlicer

[DoubleStrike]

One gotcha I found is that for the OCCT depedendency to properly build you need to have Doxygen installed in its default path under Program Files. Its build step requires that and if that doesn't exist, OCCT will not fully build, leading to other dependency failures. Rather annoying they added that as part of their build frankly.