[Bf-committers] a FreeBSD bootstrap run

[Hans Lambermont]

Frederick Lee wrote:

> On Fri, Dec 06, 2002 at 06:20:46PM +0100, Hans Lambermont wrote:
> >     checking for jpeglib.h... no
> > It is in /usr/local/include/jpeglib.h
> > Same for png.h GL/gl.h GL/glu.h X11/Xlib.h
> > Why don't we add /usr/local/include and /usr/X11R6/include to the search
> > path ?
> 
> Mostly the same reasons we don't put "." into PATH, iirc.  The superuser
> on some system may not necessarily want to inadvertantly include
> /usr/local/include/rootkit.h (symlinked) that some rogue, disgruntled,
> or 0wn3d (compromised-login) staff group member snuck in.

hehe :) that's nonsense IMHO. /usr/local/include access rights are on
all systems I know equal to /usr/include and that one definitely is
included in the search.

Besides, trying to improve your system security this way won't help you
much.

I strongly suggest the build system should *just work* on all current
supported blender platforms like the NaN one does. 

> > floor, pow, sqrt are also still not found. all are in libm of course.
> 
> This isn't fatal (I get it, too).  There isn't any code in Blender yet
> that conditionally compiles on the existence of these functions (#ifdef
> HAVE_FUNC_POW or somesuch).

Ah, I didn't know that. I thought all the configure tests were actually
used already.

> > Ok, sounds good. I just personally dislike stuff being written in a
> > source tree at all ;-)
> 
> I see the autotools and rcs/cvs as having grown up alongside each other.

Ehhm rcs/cvs is way older than the autotools, right ?

> In this regard, the I see the autotools as understandably assuming the
> source tree is the working directory, and thus is free game for creating
> and deleting object files and binaries -- if the source tree wasn't
> supposed to be scribbled all over, that's what a repository is for.

This must be why all those people inadvertedly commit files to
repositories that don't belong there :-P
I hope my viewpoint is clear as well; the source tree should be
read-only to the build process. It helps a lot with parsing 'cvs update'
output too ;-) I've seen temporary files and leftovers from OS#1 break
the build on OS#2 often enough.

> P.S. I wonder if we can tag up on (ex-)Loki folks to see how they
> handled building multiple binaries from the same source tree?

Good idea, I suggest also to have a look at mozilla's build system, very
multi platform too :) I found it inspiring.

Hans
-- 
http://lambermont.webhop.org/