buildworld may be unstable tomorrow morning

[Matthew Dillon]

    It's too late tonight, but monday morning I will likely be committing
    a major revamping of the buildworld code.  It will do a number of things:

    STAGE1:

    * It compartmentalizes the bootstrap/buildtools from the cross-build
      setup from the world stage.  Instead of unfathomable subdirectory
      names in /usr/obj/usr/src/* the stage directories are now flattened
      out and better named .  e.g. btools_<currentarch> for bootstrap and
      build tools, ctools_<currentarch>_<targetarch> for the cross compiler
      tools, and world_<targetarch> for the main buildworld.

    * The build-tools will contain all tools required by the build, not
      just the ones which might have version/portability problems.  This
      is so I can remove the base system path (e.g. like /usr/bin) from 
      the main world build, which in turn prevents buildworld from
      accidently using programs that it isn't supposed to be using.  I'd
      like to remove it from the cross-build stage too but I'd have to
      build the compiler in the build-tools stage to be able to do that and
      I haven't decided whether its worth the extra time yet or not.

    * The buildworld target will properly remove the entire buildworld
      object hierarchy.  It turns out that it was only removing the world
      stage before, it wasn't removing the build tools and cross tools stages.

    * New targets to make incremental buildworlds easier will be introduced,
      e.g. quickworld and realquickworld.  quickworld skips the build and 
      cross tools, realquickworld skips the build tools, cross tools, and
      depend step.

    * The concept of platform-native compiled programs which are uneffected
      by the cross-build, and all Makefile's that generate these little
      helper programs now use the new concept.  New suffixes have been
      introduced: '.no' for 'native object module' and '.nx' for
      'native executable'.  This is replacing the build-tools: target that
      existed in the tree.  The problem is that the build-tools stage in
      the old build was polluting the world stage's namespace a bit more
      then it should have.

      This will primarily make cross-building less hackish, once we start
      doing cross builds.

    * Fix a bug in 'wmake', which simulates the buildworld environment for
      piecemeal compilation/testing.  It was not using /usr/src/share/mk.

    * Additional .ORDER: constraints (not finished)

    STAGE2:

    * Fix .c.o and friends in sys.mk (specify -o ${.TARGET} instead of 
      assuming that the target is named the same).

    * Continued messing around with .ORDER for -j N builds.

    * Cleanup passes

						-Matt