[Bf-committers] a FreeBSD bootstrap run

[Frederick Lee]

On Wed, Dec 11, 2002 at 06:13:52PM +0100, Hans Lambermont wrote:
> 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 ?
> > 
> > Some sites insist on using /opt.  Or a subtree under /opt.  Or, in the
> > case of IRIX, perhaps /freeware.  Or was it /usr/freeware?  Or is that
> [more blah deleted]
> > The question is, then, should we also squeeze in "/opt" and
> > "/usr/freeware"?  Anything else we should throw in?
> 
> You have the wrong multi-platform development hat on /me thinks. If you
> wish not to make a 'configure && make' run without extra parameters for
> all but Linux just work on the shortlist of 8 supported platforms I'm
> afraid this blender development group will quickly become a Linux-only
> party. And that's a Bad Thing IMO. I hope you agree ;-)
> 
> regards,
>   Hans Lambermont
> -- 
> http://lambermont.webhop.org/

I'm surprised this already segued to "Linux-only".  I know of Slackies
and Gentooites that insist on placing "non-vendor" stuff in /opt.  I
know of Red Hat users that avoid /usr/local like the plague for some
reason.  I've heard of users that place "non-vendor" stuff in completely
bizarre places like /var/opt/local or ~/local.

For me, personally, compiling blender isn't just a matter of a simple
"configure && make".

I have other libs installed in /usr/local.  When some [other] package
fails to find a lib, or uses the wrong version (*cough*openal*cough*), I
have taken to setting environment variables C_INCLUDE_PATH and
LD_LIBRARY_PATH, rather than munging the makefiles.

I also have a chroot jail, where packages don't necessarily stay
synchronized with the non-chroot filesystem.  If I want to compile
something for the chroot fs, I'd like to use /chroot/usr/local instead
of /usr/local proper.  The use of "/usr" can already by changed with the
configure option "--prefix".  But when "/usr/local" is hard-coded?

Perhaps tack on "local" to $prefix?  Now how about, for space reasons, I
just throw all new packages into /chroot/usr/local for both chroot'd and
nonchroot'd (as I'm starting to do as of late)?  The $prefix would be
"/usr", while I want to use the stuff in "/chroot/usr/local".  But, hey,
"$prefix/local" => "/usr/local" has been hard-coded in configure.  Hrm.

This isn't a matter of "out-of-the-box compile just for Linux".  It's a
matter of keeping the build system clean(er), avoiding clutter, and
leaving matters of site-specifics out of the scope of the system-
independent configure script.  Even the autotool system doesn't assume
everyone *will* have a "/usr" (q.v. "--prefix").

-Fred <phaethon>