Date: Wed, 19 Jun 1996 12:06:15 -0700 From: "Jordan K. Hubbard" <jkh@time.cdrom.com> To: Mark Murray <mark@grondar.za> Cc: Nate Williams <nate@sri.MT.net>, Poul-Henning Kamp <phk@freebsd.org>, current@freebsd.org Subject: Re: tcl -- what's going on here. Message-ID: <25290.835211175@time.cdrom.com> In-Reply-To: Your message of "Wed, 19 Jun 1996 20:37:54 %2B0200." <199606191837.UAA00804@grumble.grondar.za>
next in thread | previous in thread | raw e-mail | index | archive | help
> How about meeting the problem half way?
>
> I see it sorta like this; folks are objecting to this large invariant file
> in the repository, and the alternative is being suggested as bmaking tcl.
>
> I say, why not _not_ bmake tcl, let it "all hang out" in its original
> format, except untarred and with patches applied, and let its own
> build do the work (modulo some makefile diffs (destdir etc)). diffs
> can easily be generated with 'cvs diff'. Further versions {c|sh}ould
> be imported on vendor branches.
There are problems with this too, unfortunately. The essential
problem is the obj dir, bane of our existance and utter hack into make
(did you know that bmake has inbuilt knowledge of the obj directory
and how to use it? Yuck! Talk about a policy layering violation).
To make obj work in the scenario where the package isn't actively
bmake'd (e.g. it still uses its original makefiles) for example isn't
easy. Take a read-only /usr/src and a package which would like to
modify or remove certain files during its configure stage - how do you
do that? The only technique I can think of which would work as a
general rule would be to make a link tree in ${.OBJDIR} pointing at
the patched sources, doing your builds there. Instead of extracting
the tarball as we do now, you'd create a link tree to some source
location. Pretty gross, no matter how you slice it!
If obj wasn't such a gross hack then I'd feel better about going the
extra mile to accomodate it, but all I can think about is how to drive
a stake through its heart once and for all. The obj links have caused
me serious and ongoing hassles with trying to keep multiple machines
up to date from one single NFS mounted source tree, and they actually
_break_ our read-only source paradigm since you can't do a `make
world' in a read-only tree. The attempt to remove and rebuild the obj
links (which should only serve as further proof, if any was lacking,
that this is a DEEPLY FLAWED mechanism of separating source and
objects) will fall over.
I think instead that each bmake'd package needs to have some concept
of a non-optional (yes, *non* optional) "build aside" area where it
can work and get at its sources through the already well-defined VPATH
mechanism, not some cheesy symlink. As the first action before
building anything, a package would do some equivalent of a
`mkdir -p ${OBJTREE}/${.CURDIR}' to construct its build-aside area
before cd'ing over there for the build.
There would then be no need for a comprehensive "build all the obj
links from the top before making the world" run - those dirs being
made instead as they were needed - and make would have no magic
special handling going on, the "obj policy" would be entirely done
through the macros as it should have been from the very beginning. Oh
yeah, the tree would also finally be sharable and read-only since you
could set ${OBJTREE} to whatever you wished in /etc/make.conf.
Perhaps once we've fixed this wart I'll be more optimistic about grand
architectures again, but for now I think it's simply too much in our
way.
Jordan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?25290.835211175>