Date: Tue, 25 Jun 1996 20:18:01 -0700 From: "Jordan K. Hubbard" <jkh@time.cdrom.com> To: Nate Williams <nate@mt.sri.com> Cc: Bruce Evans <bde@zeta.org.au>, freebsd-current@freebsd.org, nate@sri.MT.net Subject: Re: Building inside of /usr/src? Message-ID: <16051.835759081@time.cdrom.com> In-Reply-To: Your message of "Tue, 25 Jun 1996 20:12:30 MDT." <199606260212.UAA01934@rocky.mt.sri.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> Tell me *what* was broken about the old way that required the fix you
> did other than you couldn't take a system and do a make world on it?
I've already discussed this to death. You know exactly what was
broken with the old system.
> Pre-create the obj directories and have at it. That's one of the
And they'll be blown away again immediately by a make world, or at the
least it will try and fail miserably if the medium is not writable.
Are you sure you know what you're talking about? :-)
> But the things you complain about weren't related to your fixes on the
> obj directory. You complain and moan about the whole pmake paradigm and
> it not being standard, so why even work with it at all. You haven't
Yes they were, Nate! I've already clarified exactly how and when they
got in my way and, for the record, I *never* said "the pmake paradigm
isn't standard" - there is no standard for this so I wouldn't even
contemplate such a statement. What I said was that it was broken in
several major respects.
> Because what you 'fixed' wasn't broken. And, what you complained about
> still isn't fixed (the requirement of dealing with obj/no-obj dirs,
Yes it is, modulo *two* places in /usr/src/release/Makefile which
bogusly traverse through obj rather than using a specialized target.
I'll get to those later.
> having to Bmake tools, and the paradigm of where the install stuff
Uh, you're mixing arguments here. None of this has anything to do
with the need for bmaking tools.
> I've given you 4-5 examples I use on a regular basis, but since they
> aren't relevant to you then they aren't relevant. Bruce has given you
You've given me 2 examples of things you needed to do and I gave you a
way to do them. You cited the need to have obj symlinks and I gave
you selectable links. You cited the need to move obj links out of the
way and I made what I thought was the entirely reasonable suggestion
that you could just as easily move the directories if that's what you
wanted. I'm not aware of any other examples that were directly from
your experience. Mostly I've heard arguments like "you've broken the
multiple-architecture model", despite the fact that it didn't really
work before AND that we've no other architectures to speak of. If we
were to suddenly get one, you may rest assured that I'd make sure it
worked.
> easily reproducable examples yet you ignore them as well. You haven't
> shown any inkling to listen, so what does it matter? They will be blown
Oh I'm willing to listen, I'm just not willing to turn handsprings
over someone's contrived failure mode. Again, the two clear examples
that were broken _anew_ (e.g. not always broken) I've fixed.
See my other reply for what I feel to be a reasonable "final position"
on this. If someone cares to do this better, I'm not wedded to my own
implementation. Just don't bring back:
@echo "--------------------------------------------------------------"
@echo " Cleaning up the source tree, and rebuilding the obj tree"
@echo "--------------------------------------------------------------"
@echo
here=`pwd`; dest=/usr/obj`echo $$here | sed 's,^/usr/src,,'`; \
if test -d /usr/obj -a ! -d $$dest; then \
mkdir -p $$dest; \
else \
true; \
fi; \
cd $$dest && rm -rf ${SUBDIR}
find . -name obj | xargs rm -rf
Whatever you do, PLEASE!
Jordan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?16051.835759081>