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