svn commit: r185499 - head

[Alfred Perlstein]

* Dag-Erling Sm??rgrav <des at des.no> [081204 09:25] wrote:
> Alfred Perlstein <alfred at freebsd.org> writes:
> > Really?  So a person on a i386 platform that touches let's say
> > src/sys/proc.h will have quality checked via "make buildworld"
> > to the degree that they know it won't break all other platforms
> > too?
> 
> You are trying to turn this into a developers vs. tinderbox issue.  It's
> not.  The kind of mistakes that break the tinderbox directly affect
> users and other developers.

No, I'm trying to get a simple target that makes sense that
will prevent people from breaking tinderbox.  (failing that
then turning tinderbox off because it's too complex)

There's a lot below that I won't really comment on because
I understand most of it and the parts I don't, I honestly
don't care to!

Here's something to consider:

Lets just say it takes a developer about an hour or two to be
"enlightened" as to a new system instead of just being told "hey
run this one liner", you've just soaked up $number_of_committers *
$enlightenment_time man hours.

How many hours of enlightenment do we have versus code?

That and, since the process requires "enlightenment", you've caused
that developer to "page out" whatever they had in their head to work
on, _every time they commit_.  Soooooo frustrating.

This adds up to frustration, mistakes and missed productivity.

And that is what I am trying to address.

And I'm done too!

-Alfred

> 
> If your changes affect MD code or relies on the size or endianness of
> specific types, you should cross-build to an architecture with different
> register width and endianness.  I wish I didn't have to point this out;
> it should be obvious to anyone.  After all, it's been almost ten years
> since we added our first non-i386 platform (alpha).  I created the
> tinderbox precisely because obrien@ got mad at me for repeatedly
> breaking the alpha build.
> 
> Most bit-width issues can be caught by cross-building to amd64 if you're
> working on i386, and to i386 if you're working on amd64.  However, the
> most common bit-width-related mistake is to assume that various types
> (long, size_t, time_t etc) are the same size as int, so you are far less
> likely to break i386 (where they are) when working on amd64 (where they
> aren't) than the reverse.
> 
> Endianness issues will usually only become apparent when you *run* the
> code, but they're usually a matter of network vs host order, and will
> therefore show up on both i386 and amd64.
> 
> The final class of problems is those that arise from the use of MD
> interfaces that are implemented only on i386 and amd64.  These two
> platforms are sufficiently similar that code written for one usually
> compiles and runs on the other, but it may not compile and run on, say,
> powerpc or sparc64.  For instance, certain atomic operations are not
> implemented on arm (or weren't, the last time I looked).  Therefore, you
> are probably better off cross-building to powerpc (32-bit big-endian)
> when working on amd64 (64-bit little-endian), and to sparc64 (64-bit
> big-endian) when working on i386 (32-bit little-endian).
> 
> Cross-building is easy.  It is described in build(7), which every
> committer should read.  If anything in that man page is unclear, feel
> free to ask me, or ru@ if I'm unavailable - and to update the man page
> once you've been enlightened.
> 
> DES
> -- 
> Dag-Erling Sm??rgrav - des at des.no

-- 
- Alfred Perlstein