svn commit: r185499 - head

[Alfred Perlstein]

* M. Warner Losh <imp at bsdimp.com> [081204 08:39] wrote:
> : > 
> : > I think you ignored the discussions that said that 'universe' should
> : > be modified to exit with an error when there was an error, but
> : > shouldn't bail out EARLY.  There were even patches to do this.
> : 
> : Interesting, I didn't see them and they weren't committed.
> : 
> : The owner/maintainer of universe hasn't really stepped up to
> : provide anything and ask me "hey Alfred, would this be helpful?"
> : and the owner/maintainer of tinderbox has not either.
> : 
> : Mostly the two of them have told me "you do it, or shut up", so I
> : did it.
> 
> Except in public there were others involved that had also done it.

That's great, and the patches I saw posted didn't work.

> : > Based on that, why do something completely new and different?
> : 
> : New and different?  What?
> : 
> : Maybe you can explain to me what's so earth shattering new and
> : different about having a make target behave like most any other
> : sane make target and have a name that is self-documenting?
> 
> It invents a completely new target to do what the originator of
> universe said was the right behavior for universe.  bz had even posted
> patches to make universe work this way.

1) New target?
  - Yes, even an alias target is good if the name is self-documenting.
2) 'tinderbox' is bz's target, except (no offense to bz) mine works.

> : There is a 'tinderbox' target, which is named so that when someone
> : says "gee, I wonder how to satisfy the tinderbox" they do not need
> : to read a wiki, blog, handbook, manpage, check IRC, news group
> : or mailing list archive to figure out, they can just run it and
> : get something that makes sense.
> 
> 'Tinderbox' makes no sense to me because the tinderbox that's run only
> does one architecture.  Your 'tindrebox' target does all the
> architectures, which doesn't make any sense to me.

Really? Which arch does tinderbox check?  I saw all this stuff going
out that said:

TB --- 2007-10-04 16:25:01 - tinderbox 2.3 running on freebsd-stable.sentex.ca
TB --- 2007-10-04 16:25:01 - starting RELENG_6 tinderbox run for sparc64/sparc64
TB --- 2007-10-04 16:25:01 - cleaning the object tree
TB --- 2007-10-04 16:25:37 - checking out the source tree
TB --- 2007-10-04 16:25:37 - cd /tinderbox/RELENG_6/sparc64/sparc64
TB --- 2007-10-04 16:25:37 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -rRELENG_6 src

TB --- 2007-06-05 21:49:46 - tinderbox 2.3 running on freebsd-stable.sentex.ca
TB --- 2007-06-05 21:49:46 - starting RELENG_6 tinderbox run for i386/pc98
TB --- 2007-06-05 21:49:46 - cleaning the object tree
TB --- 2007-06-05 21:50:54 - checking out the source tree
TB --- 2007-06-05 21:50:54 - cd /tinderbox/RELENG_6/i386/pc98
TB --- 2007-06-05 21:50:54 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -rREL
ENG_6 src


Maybe this is old?  It looks like tinderbox requires more than just
i386...

Here's a more recent one...

: On Tuesday 04 November 2008, FreeBSD Tinderbox wrote:
: > TB --- 2008-11-04 18:31:04 - tinderbox 2.3 running on
: > freebsd-current.sentex.ca TB --- 2008-11-04 18:31:04 - starting HEAD
: > tinderbox run for powerpc/powerpc TB --- 2008-11-04 18:31:04 - cleaning the
: > object tree
: > TB --- 2008-11-04 18:31:29 - cvsupping the source tree
: > TB --- 2008-11-04 18:31:29 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s
: > /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2008-11-04 18:31:37 -
: > building world (CFLAGS=-O -pipe)
: > TB --- 2008-11-04 18:31:37 - cd /src
: > TB --- 2008-11-04 18:31:37 - /usr/bin/make -B buildworld

Are you sure tinderbox is only i386?

I also have some mails from DES saying stuff like:

[[ DES ]]
> It's not mine, and Poul-Hennning has clearly stated that he doesn't want
> it changed.  I *have* provided a build-testing system that notifies you
> of any breakage, and repeatedly encouraged people to use it instead of
> 'make universe'.
>
> If you don't want to wait for 'make universe' or the tinderbox to
> finish, there are other, faster ways of testing other architectures.
> For instance, to verify that your code does not break sun4v:
>
> $ make toolchain TARGET=3Dsun4v
>
> This builds a cross-toolchain; you only need to do it once.
>
> $ make buildenv TARGET=3Dsun4v
>
> This will start a shell with the environment set up for a cross-build.
>
> $ cd where/my/code/is/located
> $ make obj && make depend && make
>
> You only need to do 'make obj' once, but you have to re-run 'make
> depend' any time you add or remove a source file or an #include
> directive.
>
> If you're working on the kernel:
>
> $ make kernel-toolchain TARGET=3Dsun4v
>
> Again, you only need to do this once.  Furthermore, kernel-toolchain is
> a subset of toolchain, so you don't need to do the former if you've
> already done the latter.
>
> $ make buildkernel TARGET=3Dsun4v KERNCONF=3DGENERIC
>
> (you can specify a customized config file instead of GENERIC, but make
> sure it's in /sys/sun4v/conf)
>
> If what you're working on doesn't affect any modules, specify
> -DNO_MODULES to speed things up.  If something breaks and you need to
> run it again, specify -DNO_KERNELCLEAN, and -DNO_KERNELDEPEND if you
> haven't added or removed any source files or #include directives or
> changed the config file.




> : Anyhow, I don't really care what's done so as long as there's a 
> : top level target that does what I just committed, so if someone wants
> : to redo how I did what I did in order to get the exact same results
> : they can be my guest.
> : 
> : I would hope that they have better things to do though.
> 
> Why duplicate a bunch of code in the toplevel makefile and make it
> even more complicated than it already is?  That way leads to long-term
> problems...

It's not duplicated, it leverages the universe target by having
a few ifdefs.  Something I was nervous enough doing because I
wasn't sure what phk was going to say about that.

Anyhow, if someone wants to unifdef (or wants me to do it) such
that what I've done becomes the tinderbox target and the same
stuff is leveraged by "universe" (error exit + summary of failures
at the end).  I'm more than happy to do so.

-- 
- Alfred Perlstein