As some of you may have read, I’ve been busy over the past few days trying to build blender. And now, I’ve finally succeeded!
A while ago, I had tried to build blender using cygwin. It failed as I had placed a file in the wrong place.
Fast forward to early this week. I decided to have another go at compiling. This time, I used mingw and scons. It’s been nothing but trouble. Even though the compiler worked faster under mingw, I seemed to be buggy, as the furthest I got with it was having all the bits of the src directory compiled, but not linked! It just refused to link!
So, over an hour ago, I gave cygwin another chance. This time, I realised why it hadn’t worked the previous time. I had placed the user-defs.mk file in the wrong place! As soon as that was done, it worked perfectly, albeit a lot slower than mingw/scons, and also less user-friendly (very long and ugly invocation splattered all over the place).
Thanks mstram for hinting that the makefiles were the way to go. I guess they should be the most reliable, for as far as I know, ton uses them
Now, time to solve that outliner scrolling… and sleep.
Okay, I’m not sure if this is a good idea, but…
What are the problems that occur while compiling something like Blender?
Keep in mind that you’re speaking with someone, who has minimal knowledge of coding (that means C) and can only make programs that have no GUI at all and are mainly for mathematical purposes (it’s a course at the university - they want us to learn C, especially pointers and structures, in like 4 weeks…).
So, I’m interested in that subject, coding seems to be fun but as you can see, I have like no experience at all. Therefore, if you think you can explain the problems you had in a way that I can probably understand them, it would be really cool
And again, I’m sorry if this sounds like an impossible task…
Some of the main problems I encountered while building blender were:
bits of the source not updated correctly by cvs (one page I was using as reference for how to build blender gave a command that took ages, and only seemed to update part of the source tree)
there were several errors in the code that the compiler alerted me to. I later found that blender could possibly be compiled with them in, but nevertheless, I had gone through and culled the problems that were simplest to fix (unused variables - delete and comment out line where variable is declared; implicit declarations of functions - search through source, find *.h file where it is defined, add that file to the includes at the start in the block where similar ones are and in alphabetical order.) One error I am not sure how to fix yet is an error about something to do with initialisation and casts in blender/source/blender/src/vpaint.c
By the way, my coding knowledge is mainly in Python and VB (ages ago. gave it up when it started acting really strangely at one point - handling of collections). My C knowledge at the moment is at best knowing how to read the code and make minor changes but not really writing any major blocks from scratch.
For those interested to know, I have now got the outliner to have horizontal scroll as well as vertical! The downside is, that there are two main problems at the moment that stop me from sending a patch for it:
contents of outliner currently are drawn starting out of the space horizontally. This is the most critical bug to fix IMO, as it will be confusing for new blender users prompting many “the outliner doesn’t work” cries for help. I’m currently lost for ideas on how to fix this. Hopefully broken will see this sometime and help me.
old files with outliner windows don’t automatically get these benefits. You have to create a new outliner window in these files to actually get the benefits. It might be just a matter of changing something in the file loading.
One other problem I’ve noticed is that when only part of an icon or name of something is off the side of the space, the whole thing is not drawn. This is a behaviour found throughout blender, but it has a bad effect on the outliner. Whole names of datablocks are disappearing as a result of this, which in a way, ruins the point of outliner scrolling. I know that fixing it would most likely be a bit too much for me to tackle at the moment, but I’ll look into it as a afterthought. The main problem here is that it’ll require actual openGL coding, which I’ve zero experience with and may not work on all 3d cards.
Well I first tried with ms/.net, then tried cygwin, and finally got it to work with mingw (makefiles ). The only minor problem I had was with not having perl installed so that the ‘makesdna’ build process didn’t execute, and I have to do it manually.
Re: fixing errors in code, (in your other post), that seems strange. I didn’t get any errors with mingw, … or if I did I didn’t capture the ouput messages (<g>), I’ll try that next time I compile it.
Since you’re playing with outliner code, I’d love to see :
a “search” function (have you seen 3dsMAX’s “outliner”)
have the “zoom” (periodkey) zoom right to the specific bone when it’s selected in the 3d window. I found the “zoom/periodkey” code in space.c (actually was referred to it by someone on IRC … ;), and maybe I’ll give it a try.
So far, I’ve only made one change (and have the program still run), that was, following the “add a new constraint” tutorial on the blender.org. I started with that becuase I was interested in how the buttons and gui work.
I suspect the easiest O.S. to build it on is Linux. (Maybe I’ll fire up a Linux install and try it. just to be a glutton for punishment ).
The hardest part on my XP box was getting the build environment (compiler) setup … (after finding out which programs to download). Mingw is what I have working, and I should have started with it. Mingw is a “fake Unix/Linux” that runs on windows btw, that lets you run Unix/Linux programs.
The compiler and tools is only about a ~20meg download compared to hundeds of megs of MSoft stuff I downloaded and installed (and I’m on dial-up :eek: ), only have all kinds of cryptic errors when I tried to compile it.
For building large programs like Blender, the most common method is to rely on a utility called “make”. Make, reads it’s own “makefiles” which have instructions on which files depend on what. For blender there are approx 3,000 source files in many directories ! The good news, is that when you are in the “top” directory, all you have to do is type “make” and everything gets compiled “automagically”. The Makefile’s are included and already setup when you download the source.
The only minor problem I had was at one stage ‘make’ was trying to build a program called ‘Dna.c’, which it actually does by running another program called Perl. Although I have a Windows version of Perl on my system it doesn’t seem to want to co-operate with the ‘make’ utility, so I had track down (via the helpful #blendercoders IRC channel), how Dna.c is created. After I found out the details, I ‘manually’ created the Dna.c file and then everything worked ok.
As for the Gui, Blender has it’s own gui which is documented in a text file that comes with the source. By following a very good tutorial at blender.org on adding a new constraint, and looking through the code and reading the documentation, I was able to make a fairly very simple (but useless ) change in the buttons window.
Another good resource I’m using is the CVS commit changelog
which is a text database that records the changes that have been made by the programmers. Each commit-record has a descriptoin of what was changed, and the files that were used to make the change.
If I make any meaningful changes eventually, they’ll probably fall into the “user-interface / uitlity” category, and maybe I’ll look for any (simple) bugs or improvements. I don’t know anything about 3d coding / vertices / matrixes or rendering etc etc (yet anyway ) I’m basically just doing it for fun right now
Congrats, algorith. Another instantiation of my belief that “If one chimp can do it, so can another”.
Truth be told, blender is not that hard to compile if
a) you have some idea of what you are doing
b) more importantly, you have ALL the needed pieces
The hybrid platforms, mingw and cygwin are the hardest to setup if you have never done it before. Using the MS toolsets only add to the grief. Mingw and cygwin are not something I would recommend your first time out.
A side note: ton uses make because it rebuilds faster. Scons is more fussy about doing proper builds. If you find yourself doing
make clean; make
to get everything built, you are starting to grasp the problem.
Actually, i think MSVC7.1+Scons is easiest, because you get a full set of precompiled libraries (except Quicktime AFAIR) from CVS, on Linux you have to search like a dozen devel-libs in your package system first. Though setting up MSVC can be a pain on the other side if you don’t have a nice full Visual Studio install but only some crappy free toolkit or “express edition”…then you probably quickly wish you’d have chosen Linux…
stivs: yea i had problems on my projects with Dev-C++ (uses GNU make from MinGW) when only header files changed for example, so i alway had to do “rebuild all”. Possibly bad makefile creation, though I don’t know how scons does it, but it never missed such things so far without doing anything special other than telling it the source files for each target, it even seems to automagically solve all build dependencies…
And scons rebuild is still faster than “make clean” + “make” i assume…
Only the scons documentation doesn’t help me too much usually, very cluttered
Thanks for the explanations, I did not get all of it but at least I now know much more than before about the problems
I’m definitely not going to try it myself anytime soon but I was interested to know why it is that hard…now I can figure out why!
Only the scons documentation doesn’t help me too much usually, very cluttered
Do you mean the two blender-scons*.txt files in the …/doc source directory or the scons documentation itself?
Their wiki has some most useful speedup tips, btw. /me uses
scons BF_FANCY=0 BF_QUIET=0 BF_DEBUG=1 -j4 --implicit-deps-unchanged --max-drift=1
Bad builds with make when headers change are a sign that the dependencies are not correct in the makefiles themselves. Using makedepend can help here, but it is still a PITA.
I meant the documentation of the scons itself…maybe i’m to stupid for it, but i never know where to search for an answer. But yea seems their wiki is finally getting into shape…
can you please outline steps (step-by-step)?
I need that for some old pIIIs which will run 89se/lite (need windows software) and I would like to use my gcc cxxflags.
Grrrr… no matter what I do, I can’t seem to fix the problem of the outliner contents being drawn out of the space on first draw. Some combinations of changes kill the horizontal scrolling completely, while others make blender act funny. Getting dumps of variables reveals some very strange things going on.
For x values:
G.v2d->mask has small/normal values min: 16 and max: 324 (or something)
while
G.v2d->cur has large/weird values min:0 and max: +/- 170000000 (or thereabouts). Positive when outliner is in what I’d call normal position, negative when out of screen to the right
and
G.v2d->tot stays put on 0 and 0
Maybe this is why there is no support for horizontal scroll in the outliner. As for the other problem, I’ve read that blender keeps a history of each space type used in a space and all the settings of each. This makes this other problem hard to fix.
I’ve finally got horizontally scrolling in the outliner working as it should. The final/major problem that needed to be fixed in order for it to be usable has been fixed. Therefore, I will be submitting a patch when I get home tommorrow evening…
). The only minor problem I had was with not having perl installed so that the ‘makesdna’ build process didn’t execute, and I have to do it manually.
