[Bf-committers] CMake build options

[Tony Agee]

1. all I know is renaming /usr/local/include/freetype, which did not have
the required files, got me past freetype errors. 
2. I tried it again and it worked. I realized I typo'ed in my previous
attempt, so I recreated the error. The real problem is the formatting of the
error message from cmake. Try entering a path that doesn't exist to see what
I mean. But that's not your issue, sorry. :)
3. If I let it choose the default, or specify the correct path (the default)
to libpython2.4.a I get to linking blender, then for every .o file, I get
'undefined reference' errors for every symbol Py*. Using the .so file makes
it work. I'm prepared to provide any info that might help. Scons links the
.a file, my scripts all run. Using gcc 4.1.1. (I'll try again with 3.4.6)
4. The problem with python (that maybe only I'm having) is an example of why
a local config file that won't cause cvs conflicts is needed in my opinion.
I'm just looking to avoid the situation where I sit through a long build,
only to have it fail on the last step, over something that I could just set
and forget. But aside from that you have a number of important features
defaulted to OFF in CMakeLists.txt. That may help first time cvs compilers
to have first time success, and that's nice. But it also means I have to
remember to change all those every time I configure a build. With scons I
can "cvs up;scons clean;scons" and get blender built to my local specs very
easily. 

Thanks for your interest, and for CMake integration. :)
Tony.

-----Original Message-----
From: bf-committers-bounces at projects.blender.org
[mailto:bf-committers-bounces at projects.blender.org] On Behalf Of Jacques
Beaurain
Sent: Tuesday, November 21, 2006 4:11 AM
To: bf-blender developers
Subject: Re: [Bf-committers] CMake build options

Okay responding to a couple of issues at once, so I'll just enumerate them:

1. Freetype 1 found in /usr/local instead of FreeType 2 elsewhere: I
don't see how this is possible as the UNIX section of the
CMakeLists.txt  only looks for freetype2 in those places.

2. The comment to redefine the PYTHON stuff from the command line
works fine for me here on Linux. What is the error message you do it?

3. So by default it tries to link Python statically (PYTHON_LIBRARY =
/usr/lib/python2.4/config/libpython2.4.a) and you need to change it to
.so to get it to work? Looking at the Scons configs, this seems to be
exactly what should happen.  Strange though it does not on my Linux
(Ubuntu 6.10). I think I will get rid of the automatic find and just
do what Scons does with a version define. BTW mine builds both ways
with no errors.

4. Different build configurations and shared config files. I am with
Chris on this one, but I guess I could look at  implementing a system
for having overrides in the source dir if it is deemed necessarry. Any
others for this? My reasoning is that it may be better to just change
the file in CVS here if this is what you want, because then you see
possible conflicts on the CVS merge with your own settings.

Cheers,
Jacques




On 11/20/06, Tony Agee <tonyagee at cox.net> wrote:
> <quote>
> > But I stand by what I said earlier, there should be a "CMake-config.txt"
> in
> > the blender dir, that is not under source control, that contains the
> primary
> > options for the makefile generation phase.
>
> No, I think this is a bad idea. It means that you will only
> want one config for every build you make with that source dir.
> </quote>
>
> No, it means I have one set of initial defaults (that suit ME and MY
system)
> for any build dir I choose to configure later, so that when I run ccmake I
> only have to change the things that are relevant to THIS build.
>
> <quote>
> > # cmake -D PYTHON_LIB=/usr/local/lib/python2.3/config/libpython2.3.so -D
\
> > PYTHON_INC=/usr/local/include/python2.3 -G "Unix Makefiles" ../blender
>
> I don't use that at all.
> </quote>
>
> The only reason I tried it was to tshoot why python wasn't getting linked
> with the default configuration, which should have worked! But the main
> reason I brought it up, is that -like many people I suppose- I consider
> comments in the makefiles to be a form of documentation, and when the
> documentation is bogus, that's bad.
>
> <quote>
> ccmake ../blender
> </quote>
>
> Well, doing it that way (instead of cmake ../blender first, then ccmake to
> change things) is better. It eliminates the need to know what
CMakeCache.txt
> is for. I started off doing it the way I did, because that's what the few
> hints I was able to find seemed to indicate.
>
> Thanks much for the feedback!
> Tony.
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at projects.blender.org
> http://projects.blender.org/mailman/listinfo/bf-committers
>
_______________________________________________
Bf-committers mailing list
Bf-committers at projects.blender.org
http://projects.blender.org/mailman/listinfo/bf-committers