In message <[EMAIL PROTECTED]> "David O'Brien" writes:
: [stable dropped, this should have only been in a single list to start with!!]

Agreed.  My summary:
        o We disagree about the support impact
        o Peter's stuff may OBE this whole thread
        o My change shouldn't be committed until we know it will have no
          support impact, or it can be fixed to be more robust.

: On Tue, Nov 14, 2000 at 01:27:32PM -0700, Warner Losh wrote:
: > : I'd rather take a major compile time hit and be deterministic than not.
: > 
: > I'd rather not.  We don't do an implicit make obj in the rest of the
: > tree.  
: It is in `make world' if /usr/obj exists.  Otherwise how does all the
: .o's get in /usr/obj/ ?

I should have stated this more clearly.  We don't have an implicit
make obj anywhere else in the tree for the default "all" target.  We
do have it for other, special targets.

: > If I go build the world, and then someone adds a new program to
: > the tree, you are in the same boat.
: Nope, `make world' will DTRT.

No.  Not if you compile that one file.  Also, make all won't do the
right thing.  That's my point.  We have extra special targets that are
all singing all dancing that do the right thing, but the plain vanilla
ones act in a plain vanilla way.

Again, make world isn't the default target.  It is an extra special
target that does special things.

I've been burned by the example that I sighted.

: > If you cd to that program and type make it will wind up in . rather
: > than /usr/obj.
: Yes, and how many times do we have to tell people to run
: ``make cleandir && make cleandir'' or 
: ``rm -rf /usr/obj/* ; cd /usr/src ; make cleandir ''

A few, but a lot less than I'd expect :-).

: > Completely deterministic, the same thing will happen every time you do
: > the scenario.
: Ok, completely deterministic given enough detail -- detail which 99% of
: the time will not be provided in email to the lists saying this and that
: is broken.

True.  But it would be rare enough that people would have two
different kernels, with different revs of the sources in the same
source tree and that those differences would cause problems.  It would
sure be hard to find it, I'll grant that.

I think it would be rare enough that we won't get mail on it, but I
could be wrong about that.

: > But before making major changes to this, let's see Peter Wemm's new
: > all singing all dancing config work does for us.  I'd rather see what
: > he's come up with than argue further on this.
: Earlier today, I too I was wondering if his plan makes all this OBE.

He sure has been silent on all of this. :-)

I do think that we're all in agreement that make obj all should be
changed to make obj\n make all to make the parallel case work.  The
rest shouldn't be committed until we have it more robust.

I'll take alook to see if there's a robust way to know if we need to
run make obj or not.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to