Subject: Re: CVS commit: basesrc
To: Bill Studenmund <email@example.com>
From: Simon Burge <firstname.lastname@example.org>
Date: 12/06/1999 00:11:14
Bill Studenmund wrote:
> On Sat, 4 Dec 1999, Simon Burge wrote:
> > Bill Sommerfeld wrote:
> > > hmm. i certainly would leave it in there, since new dirs get added to
> > > the source tree all the time, and i rarely if ever switch around to
> > > using a different obj tree with the same source tree..
> > I meant the same obj tree with different source trees. Ok, I agree that
> > this might not be a common case. Is it easier to just not handle it?
> Probably. Though couldn't you just fix things with a make obj when you
> decide to use the new tree?
As I mentioned just a moment ago in reply to another message, I'll try
not to get myself in that situation again anyways.
> > It removes and re-creates the symlink (if you're using symlinks) for
> > each obj directory. This is noticebly slow especially when using a NFS
> > v2 fileserver for the source tree. To make things run faster, it'd be
> > nice to have a clean-obj-includes or obj-clean-includes target, but this
> > is obviously overboard.
> Actually an "objdependall" target might be reall cool. Charles was telling
> me what needs to happen for it, but I didn't do it. It seemed quite
(I'll use depend-all instead of dependall to hopefully make it clearer.)
Hmm, haven't we got cases where "make includes" actually makes the
.h file (which should go in the objdir) - some xdr-type files maybe?
Under these circumstances obj-depend-all isn't too usefull, and we
can't do depend-all until includes is done. That's why I suggested
> > How about (leaving out all the .if/.endifs):
> > make share/mk
> > make cleandir
> > make obj
> > make share/tmac
> > With this, any new tmac's get created in the tmac obj dir (if it exists)
> > and not in the source directory, which is one thing I was trying to
> > stop. In fact, because we build the libraries with MKMAN=no we could
> > move the "make share/tmac" to after the libraries are built...
> That would probably be good. :-)
I've done this now (well a while ago).