[Bf-committers] a FreeBSD bootstrap run

John K. Walton bf-committers@blender.org
Fri, 6 Dec 2002 19:39:06 -0500 (EST)


I hate making sparce comments with long included text, but i thought
snipping it would distract anyone. 

On Fri, 6 Dec 2002, Frederick Lee wrote:

> 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

sgi built freeware gets installed (by swmgr or inst, which do dependency
checks, and installation logging) gets installed in /usr/freeware. 

> 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

iPAQ, or pocket pc, or wince 3.0, mostly uses "/program files"

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

you can use NFS mounted directory for local storage too, so there are no
issues there.

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

yes, you can roll each platform back independently.
 
> 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>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers@blender.org
> http://www.blender.org/mailman/listinfo/bf-committers
>