[Bf-committers] a FreeBSD bootstrap run

[Frederick Lee]

On Fri, Dec 06, 2002 at 06:20:46PM +0100, Hans Lambermont wrote:
> Kent Mein wrote:
> > In reply to Hans Lambermont (hans@lambermont.dyndns.org):
[snip first section to which I lack comment]
> 
> I removed all from my blender_cvs01 dir that was not in cvs and reran;
> that helped :)
> 
> Some new configure output:
> 
>     checking sys/mount.h usability... no
>     checking sys/mount.h presence... yes
> what does this mean ? what doesn't mount.h do ?
> 
>     checking for sys/statfs.h... no
> statfs.h is a libc *internal* header file, why is it required ?

It's not required.  The configure script is checking if the system libc
is one of those that would require including it at all.  Not all libcs
have it internal.

> 
>     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.

> 
> 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).  These function do exist at link time,
though, where -lm pops up.  The not-found messages are sort of annoying
and disconcerting, but anyhoot...

> 
> pthread,ssl,png,sdl remarks are still the same.
> 
> Next step: make
> 
> blender_cvs01_obj> make
[snip make output]
> > > I see bootstrap generates the Makefiles in the source dirs, this breaks
> > > multi-OS NFS builds. Is that what we want ?
> > 
> > the makefiles do not get touched(at least on the systems I've used)
> > the Makefile.in's are platform independant bootstrap should not affect 
> > platform dependancy at all.
> 
> 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.
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.
Admittedly, this doesn't lend itself very well to preserving multiple
parallel trees of platform-specific binaries...

I suppose one thing we could add is building the libs and bin with a
platform specifier (Loki-style), e.g. "blender-linux-x86-glibc-2.3.1" or
"libblender_intern-linux-x86-glibc-2.3.1.la".  While this preserves
multiple platform-specific binaries, it still fills up the source tree.
But, hey, that's what "working directory" means.

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


-Fred <phaethon>

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?