How do I build Cura?

[nubnubbud 7]

IT WORKED!...sorta.
well, it didn't, till I did something. every step other than protobuf changed a bit, so here's the explanation:

1. I kept getting errors like "access denied" and "could not find directory" from using nmake install on sip, which meant something was wrong in its makefile (lucky guess I swear)
2. I went into the sip makefile that popped up after using configure.py, and one of the lines... looked a little screwy. so I removed it and it worked with no issues. it seems that line was just to make/read a text file? weird. (see included image and tell me if I shot myself in the foot.)
3. then I built Arcus. no errors, other than that I needed to use the cmake gui and build from within visual studio. It kept making .a files and doing other weird things when I followed the directions.
4. CuraEngine stumped me till I faffed about with cmake gui till I found it wasn't finding its own lib files, that explained why clipper and rapidjson aren't listed as dependencies.
5. after that (thank you vcpkg for having my back for protobuf and cppunit) I was able to open CuraEngine in visual studio, and immediately found some of the files and code I'd need!(cool!)

Now, I have one last hurdle before the engine's out of the way...


does this mean I have to put arcus somewhere  inside curaengine's directory, or am I just really bad at system variables or something? The header files listed exist, but not directly inside the arcus directory. they're in layer lower than arcus/, in LibArcus/src/.

Edited May 22, 2019 by nubnubbud

[rburema 26]

Great! Thanks for reporting back.

 

I remember going back and forth a few times between these instructions and I had to change a few things as wel (and changed the document), but I don't think I had to touch that particular makefile. But whaterver works 🙂

[nubnubbud 7]

2 minutes ago, rburema said:

Great! Thanks for reporting back.

 

I remember going back and forth a few times between these instructions and I had to change a few things as wel (and changed the document), but I don't think I had to touch that particular makefile. But whaterver works 🙂

I still haven't been able to compile cura yet. whenever I try to run or build CuraEngine, those errors at the top show up, and because it's not my code, I don't know how it's "supposed to be". right now, all my files are just kinda set in the "c:/dev" directory. it feels kinda wrong, but I've never had to build dependencies of dependencies before.

I did try to just take a curaengine.exe to a cura repo clone, but I got stuck trying to build uranium, 'cause there are no instructions at all for that one. libSavitar worked perfectly in the first try, though!...but it is self-contained, meaning my computer/setup has loads of issues finding dependencies.

[nubnubbud 7]

Update: when recompiling Arcus, I ran across this in VS.

it seems to directly correlate to this, which is stopping me from being able to build the engine.
  

has anyone come across this before, and should I open an issue? I looked around, and this error seems to hint that some of the code is written in a very nonstandard, risky way where it exports. it seems doing things like this causes issues in any case where compiler, compiler settings, or compiler version change at some point in the project... which does happen. a lot.

reference: https://stackoverflow.com/questions/24511376/how-to-dllexport-a-class-derived-from-stdruntime-error

Edited May 23, 2019 by nubnubbud

[rburema 26]

I've never built it completely in VS, just relied on the tools.

 

Please get rid of the 'cannot open' errors first, it just means that VS is looking in the wrong places for these files. I don't think you can rely on the other errors if those aren't fixed.

 

ETA: For the engine, libArcus should be compiled into a static library.

Edited May 23, 2019 by rburema

[nubnubbud 7]

2 minutes ago, rburema said:

I've never built it completely in VS, just relied on the tools.

 

Please get rid of the 'cannot open' errors first, it just means that VS is looking in the wrong places for these files. I don't think you can rely on the other errors if those aren't fixed.

Well, I would rely on the tools, if they actually worked more than half the time. 😞I'm new to in depth builds like this,(I have built blender and slic3r before but they both use allmost no external libraries)  so I'm not exactly sure what to do when the tool fails, then refuses to work even after I set a viable output. (Cmakegui tells me it "considered" arcusconfig.cmake, but decided not to use it.) For VS I've tried putting the .h files in with the others in Curaengine but it still doesn't find them, and I think that some linkage is messed up, and as this is my first time dealing with that kind of thing. Is this just a windows thing?

 

I've been able to fudge arcus into working, but for some reason nmake and cmake from command line only really make .a files. For example, when I used the VS2015 command prompt to build arcus like in the tutorial, I never got a Libarcus.pyd file. I only got it after using cmakeGUI to build the solution files and then building build_all, but when I do that, I just get a release folder, and then there's nothing to install, but I have all the .py, .pyd, cpp, and .h files

 

I did find a good tutorial on more advanced linking practices in VS so l'll get back once I confirm or deny that it's visual studio/my computer/technique that's janky. If that doesn't work I'm setting up a virtual machine and trying from scratch on debian/mint.

[rburema 26]

I remember what I eventually did was just start up cmake-gui for each time I had to use cmake, then manually fill in each entry I could find, press configure, repeat until no more entries showed up, then generate (you may have to do a 'show all' on the settings). This didn't always make it into the document, I see now.

 

Could you maybe show the settings you have configured in cmake-gui?

 

 

[nubnubbud 7]

9 hours ago, rburema said:

I remember what I eventually did was just start up cmake-gui for each time I had to use cmake, then manually fill in each entry I could find, press configure, repeat until no more entries showed up, then generate (you may have to do a 'show all' on the settings). This didn't always make it into the document, I see now.

 

Could you maybe show the settings you have configured in cmake-gui?

 

 

yeah, here's the most recent one. I forget what I did before that made it actually find and build with arcus, but I've tried 
C:\dev\libArcus\install_dir\lib\cmake\Arcus
and
C:\dev\libArcus\build
the only two cmake files you can end up with: one used the cmakegui to build, the other was built and installed with nmake.

[rburema 26]

The first location should be correct. I see you're building everything in 32-bit, are you sure you've also build libArcus as a 32-bit library? The error seems to indicate that this might be the reason that it's 'considered' but not actually used.

[nubnubbud 7]

Just now, rburema said:

The first location should be correct. I see you're building everything in 32-bit, are you sure you've also build libArcus as a 32-bit library? The error seems to indicate that this might be the reason that it's 'considered' but not actually used.

...I'm not sure how that would end up leaving out exactly 2 files, but oh well... that said, 32 bit hurts my soul.

might I ask... how you build in 64 bit? I followed the directions blindly until they didn't work, then fiddled around till I got the right output, so it seemed, but there was no clear indication of what causes things like mingw32, cmake, and visual studio to build 64 bit programs. I was assuming they did, because as  far as I know, it's the standard now.

[rburema 26]

@nubnubbud Are you using the 64-bit version of the mingw compiler & linker? ( https://stackoverflow.com/questions/17988904/compile-64-bit-binary-with-mingw-dev-c )

 

If you're in VS itself you need to go to 'Manage Configurations'.

[nubnubbud 7]

36 minutes ago, rburema said:

@nubnubbud Are you using the 64-bit version of the mingw compiler & linker? ( https://stackoverflow.com/questions/17988904/compile-64-bit-binary-with-mingw-dev-c )

 

If you're in VS itself you need to go to 'Manage Configurations'.

actually, I've been using the last couple days to learn about/how to use debian/linux. I'm running it on a virtual machine, and I've got everything going right on the first try! (I knew it wasn't just me being dumb! it was the OS that made it nearly impossible to both link and set up dependencies.)

 at this point all I need to figure out is how to cross-compile a windows 64 bit distribution on linux (i'm using codeblocks. is there an easier solution?), and I'll be set. maybe there's a way to do it from command line? I really don't know the various mingw make commands, and using them on linux just adds another layer of confusion for me, though XD.

[rburema 26]

@nubnubbud Yeah the linux build process is a bit easier ...

 

As for cross compiling or CodeBlocks, I'm afraid I can't help you with that. I've always just just the OS that the build is for, and I've only used CodeBlocks once, years ago.

 

Just remember that you'd probably still need to build libArcus twice in any case.

[nubnubbud 7]

Just now, rburema said:

@nubnubbud Yeah the linux build process is a bit easier ...

 

As for cross compiling or CodeBlocks, I'm afraid I can't help you with that. I've always just just the OS that the build is for, and I've only used CodeBlocks once, years ago.

 

Just remember that you'd probably still need to build libArcus twice in any case.

build it twice? what for? If cura and curaengine both need it, just building and installing once should do it... maybe that's what I was doing wrong before?

and like I said, I'm not in love with codeblocks yet, so if you  know the command line commands to build using mingw-w64 in debian/mint (I have it installed already) feel free. I'll look it up, though if  you know any caveats for cross-compiling, some tips would be  appreciated.

[rburema 26]

libArcus for Cura needs to be compiled in such a way that it is compatible with python libraries (on Windows), which is what the 'Visual C libArcus and Python bindings build' heading is a guide to.

 

libArcus for the engine is build with mingw ('MinGW libArcus build and install')

 

I suppose you could do it all at once if you also build the engine with VS (or its command line equivalents/tools), but I haven't found time to make that work myself (yet).

[nubnubbud 7]

2 minutes ago, rburema said:

libArcus for Cura needs to be compiled in such a way that it is compatible with python libraries (on Windows), which is what the 'Visual C libArcus and Python bindings build' heading is a guide to.

 

libArcus for the engine is build with mingw ('MinGW libArcus build and install')

 

I suppose you could do it all at once if you also build the engine with VS (or its command line equivalents/tools), but I haven't found time to make that work myself (yet).

ah, so that's what's so important about the arcus.pyd. basically, you need to compile the c++ into both python and normal c++. That totally explains why I was getting deja vu when I was Following the build guide. so nmake for python, and cmake for c++...

so I... supposedly compiled curaengine in linux, but from what I understand, you just drop it into cura proper to make cura runnable... but all it seems to have made are these lib_CuraEngine.a files and this 4.1 mb CuraEngine file. that seems like the one, but it's 1.7mb smaller than the main release's, and because debian is super protective I can't just drop it into an appimage and try running it with cura. like I could with the exe in windows.

I'll see if the cura-build or cura-env are better for linux. I'd prefer to build all on windows, but windows really, really needs a folder just  for libraries to be installed. this is getting silly.

[rburema 26]

Yeah, Cura + CuraEngine is not exactly the easiest to build. We're ramping up our efforts with C.I. as well, so eventually people (at the very least on Linux) should just be able to use cura-build / cura-build-environment.

 

The CuraEngine file should the one. The file-size difference is maybe becasue we optimize for speed, not size?

 

I think you might be able to unpack an AppImage, then sneak it in, then repack it. See https://superuser.com/questions/1301583/how-can-i-extract-files-from-an-appimage for inspiration.

 

[nubnubbud 7]

19 hours ago, rburema said:

Yeah, Cura + CuraEngine is not exactly the easiest to build. We're ramping up our efforts with C.I. as well, so eventually people (at the very least on Linux) should just be able to use cura-build / cura-build-environment.

 

The CuraEngine file should the one. The file-size difference is maybe becasue we optimize for speed, not size?

 

I think you might be able to unpack an AppImage, then sneak it in, then repack it. See https://superuser.com/questions/1301583/how-can-i-extract-files-from-an-appimage for inspiration.

 

that's probably the reason.  in any case, I tried just taking it all and putting it into a folder, then using the apprun and it worked for all of .2 seconds! I saw the ultimaker logo, and it brought me to the same send crash report popup. Both my compile and the appimage (when deconstructed) did this, so I can probably assume it's working? maybe? probably not.

(one day later)
...linux being what it is, provides no GUI or any guided method of doing so, I learned. I try to run the new appimage, but I just get execv error: Permission denied, even though I'm root and own it.

I think I just need to learn to cross-compile the whole thing from linux to windows, to know if it's working, though tell me when you guys get that cura-build/cura-build-environment working. I wasn't aware it was in progress the first time I tried.

[burtoogle 513]

On 5/29/2019 at 3:10 PM, rburema said:

Yeah, Cura + CuraEngine is not exactly the easiest to build. We're ramping up our efforts with C.I. as well, so eventually people (at the very least on Linux) should just be able to use cura-build / cura-build-environment.

 

And that's how I build my releases, using (very slightly modified) cura-build-environment / cura-build. Works for me for Linux and Windows. No longer works for OS X but that's because the Mac Book I have is ancient.

 

 

[rburema 26]

Good point @burtoogle 

 

@nubnubbud Those repo's are here:

https://github.com/Ultimaker/cura-build

https://github.com/Ultimaker/cura-build-environment

if you want to try it that way.

 

[nubnubbud 7]

5 hours ago, rburema said:

Good point @burtoogle 

 

@nubnubbud Those repo's are here:

https://github.com/Ultimaker/cura-build

https://github.com/Ultimaker/cura-build-environment

if you want to try it that way.

 

I know where it is, no need to babysit me quite that much XD... though I do appreciate you guys being my safety helmet. I was able to use cmake on cure-dev-environment, but when I use make I get "make: *** No targets specified and no makefile found.  Stop.
" and sure enough, there are actually no makefiles in build, just cmakecache, lib64, and all the dependency files. lib64 is only 3 bytes, so I can't imagine everything worked perfectly.

[rburema 26]

It's not _just_ to babysit you, it's also nice for future reference, if anyone else stumbles on this thread 🙂

 

One of the reasons I didn't recommend this route in the first place is that the migration to our new system(s) isn't fully done yet (I don;t even know if the branch is already merged ... it should be), and the documentation might be out of sync with what we currently have.

 

What you _could_ do, I suppose, is see what we did in the docker-files and replicate that without docker? That's a whole other rabbit-hole though...

[nubnubbud 7]

18 minutes ago, rburema said:

It's not _just_ to babysit you, it's also nice for future reference, if anyone else stumbles on this thread 🙂

 

One of the reasons I didn't recommend this route in the first place is that the migration to our new system(s) isn't fully done yet (I don;t even know if the branch is already merged ... it should be), and the documentation might be out of sync with what we currently have.

 

What you _could_ do, I suppose, is see what we did in the docker-files and replicate that without docker? That's a whole other rabbit-hole though...

And considering all that, I think the wisest choice may be simply to wait until you guys are done migrating it. As you can guess, I'm no career developer. I've only really compiled Blender and Slic3r before. Unless I can get this working by following the directions mostly blindly, (or at least fail with a descriptive error message) I'm not going to have much luck troubleshooting. I'll keep trying through the normal workflow.

 

I've found some alterntate ways to make prints just a little clearer without overextruding, but all of this was for the purpose of adding "iron every layer" and a few settings to make PETG and other "boogery" materials print better- essentially temperature modulation depending on the structure (lower/higher temps on supports may help.)

 

i also want to take a look at the delayed layer code to see if anything's up because it doesn't seem to work for me, and see if running the side of the print head around the outer edges can change surface quality somehow.

[rburema 26]

Allright, fair enough.

I'll bring up the build-instruction clarity with the other dev's sometime soon.

[nubnubbud 7]

Just now, rburema said:

Allright, fair enough.

I'll bring up the build-instruction clarity with the other dev's sometime soon.

That would be great. It's not just for me I imagine. A large number of the issues on github are build issues, and in any case, the easier it is to work on, the more features casual users will begin to work on... hopefully. The most confusing parts for me are cross-compiling (if it's easiest to build in linux but most users have windows this is important I think) and what happens to CuraEngine once it's made. It doesn't seem like it's properly installable, so do you move it to some folder in Cura or is there some step where you point the compiler at it? I haven't gotten that far yet but it's aomething that I haven't figured out after reading everything.