How do I build Cura?

[nubnubbud 7]

I've been trying to build the program so I could add some functionality that's sorely needed, but I've been sitting here for 2 days, building dependency after dependency, so that I can use those to build the dependencies for cura's dependencies, only to learn something is wrong from an indecipherable error. I'm at wit's end and now is as good a time as ever to ask:

What am I doing wrong, from a  technique standpoint?
am I using the wrong build?
why are there 4 different ways to build it, and which is the correct/current one?
do I build the environment, and how do I manage that when following the directions don't produce any results?
do I build all the dependencies manually like it says in the other guides?

[burtoogle 509]

Hello @nubnubbud. In theory it's just a matter of cloning the cura-build-environment  repo and following the instructions to build that and then cloning the cura-build repo and following the instructions to build that. However, I have found that I cannot build a working cura using the master branches of those repos. In my forks of those repos I have my own branches that I work from (mb-linux, mb-windows and mb-osx). I am no longer able to build a working OS X binary but the mb-linux and mb-windows branches work with the current master branches of the cura sources. So, you could try cloning my repos and trying to build from them. See https://github.com/smartavionics/cura-build-environment and https://github.com/smartavionics/cura-build. Hope this helps.

[nubnubbud 7]

7 hours ago, burtoogle said:

Hello @nubnubbud. In theory it's just a matter of cloning the cura-build-environment  repo and following the instructions to build that and then cloning the cura-build repo and following the instructions to build that. However, I have found that I cannot build a working cura using the master branches of those repos. In my forks of those repos I have my own branches that I work from (mb-linux, mb-windows and mb-osx). I am no longer able to build a working OS X binary but the mb-linux and mb-windows branches work with the current master branches of the cura sources. So, you could try cloning my repos and trying to build from them. See https://github.com/smartavionics/cura-build-environment and https://github.com/smartavionics/cura-build. Hope this helps.

That's great, and I'll try it in a few hours when I can, but how does it differ from Cura's masters, and will those differences make any issues for making commits or pull requests?

[burtoogle 509]

24 minutes ago, nubnubbud said:

That's great, and I'll try it in a few hours when I can, but how does it differ from Cura's masters, and will those differences make any issues for making commits or pull requests?

 

Ah, yes, my mb-linux and mb-windows branches in the cura-build repo reference my own repos for the source for Cura, CuraEngine and Uranium. You will probably want to modify the cmake files in the project directory to reference either Ultimaker's repo or your own fork and also to specify the desired branch you want to build.

[nubnubbud 7]

8 hours ago, burtoogle said:

 

Ah, yes, my mb-linux and mb-windows branches in the cura-build repo reference my own repos for the source for Cura, CuraEngine and Uranium. You will probably want to modify the cmake files in the project directory to reference either Ultimaker's repo or your own fork and also to specify the desired branch you want to build.

so, I tried it, and I'm getting the exact same result, cura or yours. I solved all the other issues, which turned out to be the combination of a misplaced mingw directory and needing both the previous and current python (2.7 as well as 3.5/6/7)

now I have the same issue on both versions. after I run either your fork or the main build environment, it runs into some kind of issue with python, which seems to be an environment variable thing, I have added python to my path, though, so it should all be working. here's some snapshots of the output, if it's familiar to you. any guesses as to what it could be?


it continues with those python  files for a good while, no other issues, till...

Edited May 20, 2019 by nubnubbud

[burtoogle 509]

Hello @nubnubbud, are you executing my run_cmake.bat script before doing the build?

[nubnubbud 7]

22 minutes ago, burtoogle said:

Hello @nubnubbud, are you executing my run_cmake.bat script before doing the build?

I had to double check, but the repo does not have that file, nor is it made by building it, and I can't seem to find a link from your account to anything that looks like it. if you're talking about running env_win64.bat and then using cmake with the directory and build type arguments, I'm doing that already.

were you also having that "python is not recognized" issue too?

[nallath 1,117]

In order to develop Cura, you don't actually need to build it (apart from Cura Engine, which is C++ so it needs building).

 

The build script is what we use to actually make a release, which isn't actually needed for your use case.

[burtoogle 509]

In my cura-build-environment there is a branch called mb-windows and it has a file called run_cmake.bat which I call before invoking nmake.

[nubnubbud 7]

24 minutes ago, nallath said:

In order to develop Cura, you don't actually need to build it (apart from Cura Engine, which is C++ so it needs building).

 

The build script is what we use to actually make a release, which isn't actually needed for your use case.

Then... I'm terribly confused once again. don't I need the solution files? I can't get those without building the dependencies, and that's what I've been pulling my hair out over for days, and I do intend to work on the engine a bit.

just, when I try to use cmake to build the solution files, it needs uranium, and protobuf, and arcus, and all of those have dependencies, etc, and they themselves don't compile, so I went to the environment, thinking it was where to get all the dependencies at once? if you can't tell, this is only the third open source project I've poked my nose in.

Edited May 20, 2019 by nubnubbud

[ahoeben 1,851]

It depends what you want to change. If it is all frontend stuff, you might be able to just edit python files in the released version.

[nubnubbud 7]

2 minutes ago, ahoeben said:

It depends what you want to change. If it is all frontend stuff, you might be able to just edit python files in the released version.

it's probably not all frontend, and I imagine I might need to touch the engine a bit. basically, I want to add an  option under ironing that will make it iron every layer, since that produces stronger, clearer prints (yes, I've been on about it for a long time now)

Edited May 20, 2019 by nubnubbud

[ahoeben 1,851]

Couldn't you do that with a postprocessing script though? Duplicate each layer, adjust the extrusion.

[nubnubbud 7]

ironing isn't an extrusion multiplier or something quite that simple. it requires moving the printhead back and forth over the entire layer, in passes smaller than the extrusion width. as well, the print head does not rise, and even keeps extruding the slightest amount, to fill in any texture in the top surface.

it already exists, and works wonderfully!... just it can only be enabled for exposed upper sections of layers wider than the extrusion width. I've proven results with handmade gcode, but then it just kinda fell off to the side of the road... but I want the feature because it's useful for me right now.

Edited May 20, 2019 by nubnubbud

[nallath 1,117]

I've never used the cura-build scripts on the laptop I do all the development work on.

 

I basically did the following things;

- Check out libArcus
- Create build folder, run cmake &&  make && make install
- Check out Cura Engine
- Create build folder and run cmake && make
- Check out Uranium
- Check out Cura
- In the cura folder use python3 cura_app.py to start Cura.

At that point, it is likely to complain about missing a number of dependencies, which I install with pip until it runs.

Edited May 20, 2019 by nallath
Fixed the order in which things need to be done

[ahoeben 1,851]

You need to do libArcus before CuraEngine, because CuraEngine requires libArcus (right?).

[nallath 1,117]

Derp. Yeah you're right. Fixed it

[nubnubbud 7]

this, right  here, gives me hope, and is exactly what I needed- and what I think a lot of source code needs. a one to two sentence breakdown of getting it set up in the right order (and places?), and how much fiddling you should expect. 

also, I'm curious about that too. I'm no expert (of that we can all agree) but it seems like there should be both an order and a place for all the files to go. How do I make sure everything sees each other properly, for build/running purposes? is there some kind of standard directory setup, are they set up to look out of their own directory to the ones in the same folder, or  is there some setup I need to know, like placing libarcus or curaengine somewhere in cura?

Edited May 20, 2019 by nubnubbud

[nubnubbud 7]

I was able to set up protobuf, though only through vcpkg, and now cmake is asking for sip cmake files for arcus, because I'm using vcpkg's toolchain, even though I have it installed in python.... here's the error. I can't find sip cmake files wherever I go, so I can only assume they don't exist?

I installed sip and qt5 with "pip3 install", but are 

python3-dev (3.4+)

python3-sip-dev (4.16+)
as listed in the arcus build guide the same, or something I don't know how to get?

I'm on windows, and this bit in the arcus guide looks like it's for ubuntu or something, but there is no windows guide!
 

• $ mkdir build && cd build
• $ cmake ..
• $ make
• # make install

 

EDIT 2
alright. after some careful searching and looking,

pip3 install sip

does not install the needed files, and I can't find python3-dev or python3-sip-dev anywhere.

Edited May 21, 2019 by nubnubbud
typos-noticed the directions may not be for windows/edit2 electric boogaloo: found a likely issue

[nallath 1,117]

You might want to check in the cmake-gui where it's looking for the sipconfig files and manually point it to the right spot.

[nubnubbud 7]

1 hour ago, nallath said:

You might want to check in the cmake-gui where it's looking for the sipconfig files and manually point it to the right spot.

I am using the GUI- but that's not the issue, I think. I've installed sip, but... there's not a single file with sipconfig in its name on my entire computer. note that I am completely unable to install python3-sip-dev or python3-dev because those are not released or otherwise available for windows, as far as I can tell, and that probably gives me issues.

it's always just said SIP_DIR = SIP_DIR-NOTFOUND

Do you know what's going on here? it seems someone somewhere knew about it, because there is no guide to building libarcus in windows, unlike all the other repos. it just says
"Building the Python bindings on 64-bit Windows requires you to build with Microsoft Visual C++ since the module will fail to import if built with MinGW."

but gives no other help. I've tried building with the visual studio dev command prompt, but nmake finds nothing to work with anywhere in C:\sip-4.19.17 (where I slapped the python-sip-dev source files).

Edited May 21, 2019 by nubnubbud

[rburema 26]

@nubnubbud Maybe the following will help (snippet from an internal page):

 

Quote

 

* SIP Build

 * Download sip sources. https://www.riverbankcomputing.com/software/sip/download/ 4.19.12

 * Open up cmd.exe, in sip sources run `python configure.py`

 * Run `nmake`

 * Run `nmake install`

 

 

[nubnubbud 7]

1 hour ago, rburema said:

@nubnubbud Maybe the following will help (snippet from an internal page):

 

 

alright, so I went through everything, set path where it was supposed to be, and it seems to get one step further and nmake actually runs now that it knows to find nmake in the VS 2015 tools, but there's still the issue of nothing being built. SIP still isn't being found.

As well, I saw the error, and in a fit of gall I tried to run it with various settings, like trying to install it to the 32bit python, 2.7 python, and with/without the VS dev command prompt. I also uninstalled all other pythons just in case. I also tried the 2017 nmakes(x86 and x64) to the same result. no dice. I did however get it to say 

cd sipgen
        "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.16.27023\bin\Hostx86\x86\nmake.exe"
Microsoft (R) Program Maintenance Utility Version 14.16.27031.1
Copyright (C) Microsoft Corporation.  All rights reserved.
NMAKE : fatal error U1073: don't know how to make 'sip.h'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.16.27023\bin\Hostx86\x86\nmake.exe"' : return code '0x2'

using the 2017 nmake x86 version.

I got this every other time. it seems to reference that  I'm using a 64bit system, but shouldn't that be compatible with installing/compiling 32bit files?

 

Edited May 21, 2019 by nubnubbud
more tests

[rburema 26]

Quote

 

I got this every other time. it seems to reference that  I'm using a 64bit system, but shouldn't that be compatible with installing/compiling 32bit files?

 

 

64-bit _systems_ are, in general*, compatible with (~= can still run) 32-bit _programs_. Mixing and matching 64- and 32-bit object code when linking isn't really possible for compiled code.

 

I think there are separate 'VS 20XX tools' cmd-windows for both 32- and 64-bit.

 

Rather than play ping-pong like this, it may be helpfull just to give a large part of the internal document (for building on Win) to you, so you can try it out for yourself (see attachment**). Why it's not official documentation will become clear when read ... it's in a rather rough state to say the least :-) So no guarantees, etc. etc.

 

*) At least if we're talking about the intel-compatible chips that are in most PC's right now.

 

**) Attachment zipped because the forum doesn't accept `.txt` files? 🙂

 

 

cura_windows_buildsteps.zip

[nubnubbud 7]

17 minutes ago, rburema said:

Rather than play ping-pong like this, it may be helpfull just to give a large part of the internal document (for building on Win) to you, so you can try it out for yourself (see attachment**). Why it's not official documentation will become clear when read ... it's in a rather rough state to say the least :-) So no guarantees, etc. etc.

Huh... I  see why this isn't standard, but it's better than the standard in my opinion, friendlier to people who've inevitably messed up their entire computer for this not to work, like me. 

is python 3.5.0/6 absolutely required?I have 3.6.6... or will installing it via visual studio work? the only difference I see is physical location.

also, before I go through this chain of builds, rapidjson in when using cmake for CuraEngine has the exact same issue that sip did! (I build arcus without any python  dependencies to check if there was any more to worry about). I didn't see RapidJson listed under any dependencies, so it might be good to list it somewhere.

for protobuf, I was unable to build it before, but the install from vcpkg worked perfectly for filling out the arcus cmake dependencies, it's basically pip for c++. If you added arcus to vcpkg, installing it would cascade, find and install protobuf and all of protobuf's dependencies, too... then again I might need more sleep because how would arcus get its python dependencies, but it's a nice thought.