[Bf-committers] a FreeBSD bootstrap run

[Frederick Lee]

On Fri, Dec 06, 2002 at 11:06:51PM +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 ?
> > 
> > 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. 

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
entirely optional (I'm real fuzzy on IRIX...)?  Then the cygwin stuff
are installed in strange places under MS-Windows... unless you use the
cygwin posix emu libs, in which case a sane filesystem is presented
where /usr/local may actually be meaningful, but may otherwise be
something like E:\CYGNUS\CYGWIN32\USR\LOCAL.  Or C:.  Or D:.  Or any of
the other 21 letters in the 7-bit Latin-1 alphabet.  23 if someone is
sadomasochistic enough to squeeze cygwin onto floppies...

And that ridiculously long include path for OSX also comes to mind.

The question is, then, should we also squeeze in "/opt" and
"/usr/freeware"?  Anything else we should throw in?  What's the
filesystem layout like for targeting iPaq?  Also have includes for
cross-compiling (/usr/lib/gcc-lib/m68k-linux/2.8.1/include)?

The closest I could find to standardization on the meaning of various
paths is FHS (http://www.pathname.com/fhs/).  Both /usr/local and /opt
qualify as destinations for "Extra stuff".

Here's another thing: if the user doesn't *want* /usr/local listed, how
would the path be taken out?  Rehack configure.ac and rerun bootstrap?

I want to get across the point that including "/usr/local" by default is
not a good idea -- raises a host of extra questions.

I think something like this could be done before running configure (this
is off the top of my head):
export C_INCLUDE_PATH=/usr/local/include:/opt/include
export CXX_INCLUDE_PATH=/usr/local/include:/opt/include
export LD_LIBRARY_PATH=/usr/local/lib:/opt/lib

The point being that the extra paths can be specified elsewhere outside
of configure[.ac] and still be seen/used by configure and make.

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

Yeah.  I meant more of autotools growing up centered around rcs/cvs.  My
point was that autotools was likely to be developed more with rcs/cvs in
mind rather than nabbing live source files across NFS.

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

The way I see it, each OS should be getting it's own copy of the
repository in a local working directory.  While grabbing src files over
NFS is a neat trick, I seriously doubt the majority of "the peons" out
there have multiarchitectural intranet NFS.  Even if they do, there's
hardly any reason to keep the working directory on a shared NFS volume.
On my local box, the sources alone take up 48MB, and the bins after
compilation occupy an extra 123MB.  If someone has a machine with local
storage running so close to full that they can't spare another 200MB for
unpacking and compiling Blender, I'd say there are bigger problems than
trying to get Blender compiled from a shared NFS volume.

CVS already deals with polluting the src tree by only checking files
that exist in the repository.  If for some bizarre reason we dropped the
NaN build system on the floor right now and went all-autoconf, all the
Makefiles would be removed from cvs and be a moot point wrt committing
modified Makefiles (well, I assume this is what the "inadvertant commit"
refers to...).

I can see your point about the verbosity of cvs's output for extraneous
files.  There are options to pass to cvs to ignore certain path names.
In particular, the "-I" option to cvs update, ~/.cvsignore file, or per
directory .cvsignore file.  I can see how this would still be something
of a wart, but verily, most of the cvs readers are going to be busy
updating and compiling, not making extensive patches and checking
merges/conflicts.  And even if they are modding/patching, I doubt coming
across dozens of lines prefixed with '?' will turn out to be a
showstopper for most of them.

The only real advantage I can think of for a shared NFS src tree is
instantly propagating source changes across multiple archs and firing up
compilers in parallel.  But then, cvs and the CVS repository are there
for a reason.

I can see why you would _want_ the src tree read-only, but I don't see
why it _should_ be so for *everyone*.

Executive summary: unpolluting src tree is rather low-priority.

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

Ah, thanks.  Mozilla totally slipped my mind  8(

-Fred <phaethon>