[Bf-committers] a FreeBSD bootstrap run

[Hans Lambermont]

Kent Mein wrote:
> In reply to Hans Lambermont (hans@lambermont.dyndns.org):
> >     libtoolize: `configure.in' does not exist
> > Sounds serious :-( Shouldn't configure.in be generated from configure.ac ?
> 
> If I had to guess version of libtool doesn't know about the newer name
> configure.ac  (If someone wants to take a crack an making a configure.in to
> go with things go for it, a good place to start would be just
> cp configure.ac configure.in then start working on the problems you get) :)

Ok, it now says:

./bootstrap
    Running aclocal ...
    aclocal: both `configure.ac' and `configure.in' present: ignoring `configure.in'
    Running automake --gnu --add-missing...
    automake: both `configure.ac' and `configure.in' present: ignoring `configure.in'
    configure.ac: 27: installing `./config.guess'
    intern/ghost/Makefile.am:48: warning: automake does not support conditional definition of BUILDPS in libblender_GHOST_la_SOURCES
...
    Running autoconf ...
    autoconf: warning: both `configure.ac' and `configure.in' are present.
    autoconf: warning: proceeding with `configure.ac'.
    configure.ac:174: warning: do not use m4_patsubst: use patsubst or m4_bpatsubst
    configure.ac:362: warning: do not use m4_regexp: use regexp or m4_bregexp

Ok, part 2:

../blender_cvs01/configure
    checking build system type... i386-unknown-freebsd4.7
...
    configure: error: source directory already configured; run "make distclean" there first
    Exit 1

Well ok, let's do that:

cd ../blender_cvs01/
make distclean
    make: don't know how to make distclean. Stop

hmpf :-/ This is not going the easy way.

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 ?

    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 ?

floor, pow, sqrt are also still not found. all are in libm of course.

pthread,ssl,png,sdl remarks are still the same.

Next step: make

blender_cvs01_obj> make
cd .  && CONFIG_FILES= CONFIG_HEADERS=config.h  /bin/sh ./config.status
config.status: creating config.h
config.status: config.h is unchanged
config.status: executing default-1 commands
make  all-recursive
Making all in intern
Making all in string
source='intern/STR_String.cpp' object='STR_String.lo' libtool=yes  depfile='.deps/STR_String.Plo' tmpdepfile='.deps/STR_String.TPlo'  depmode=gcc /bin/sh ../../../blender_cvs01/depcomp  /bin/sh ../../libtool --mode=compile g++ -DHAVE_CONFIG_H -I. -I../../../blender_cvs01/intern/string -I../..     -g -funsigned-char -c -o STR_String.lo `test -f intern/STR_String.cpp || echo '../../../blender_cvs01/intern/string/'`intern/STR_String.cpp
test: =: unexpected operator

Interesting. test -f is of course supported. Any idea what's wrong here ?

> All my systems have the later versions of things I would have to go
> through alot of effort to downgrade them

Well, I'm using the latest versions of things as well, for my OS that
is. So I'm afraid we'll see these problems pop up on all non-Linux
systems. I hope it's easy to make things more generic when stuff is
running right for the first few OSes.

> > 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 ;-)

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