Taking the hatchet to crosstool

Martin Guy martinwguy@gmail.com
Wed Mar 8 14:00:00 GMT 2006


Hi
  I finally had enough of all those horrid files in crosstool's top
directory (following the principle that no meaningful "ls" listing
should be more than 80x25 :), and in my own copy of 0.42 have:
 * Moved *.dat to data/
 * Moved *.config to config/
 * Moved demo-*.sh to demo/
 * Moved *.sh to scripts/
 * Edited (bin/)all.sh, crosstool.sh and most of the other scripts to
conform to this, adding
         SCRIPT_DIR=${SCRIPT_DIR-$TOP_DIR/scripts}
   in every script where TOP_DIR is set. This also paves the way for
the idea of installing this stuff somewhere one day instead of always
having to work in the source directory.

So far I've only tested the modification with the one regular build
that I do; making this real means moronically editing every demo file
and trying all the various scripts, which i can't do myself for lack
of CPU.

This creates a few problems:
- This isn't the sort of upheaval that can be expressed in a patch set
to the original crosstool for feeding-back purposes, so Kegel would
have to make this change too and impose it on everyone in the next
release
- Some scripts are meant to be run from outside the crosstool directory as
   crosstool-0.42/buildrpms.sh   or   crosstool-0.42/regtest.sh
  or whatever, and I can't test them to see if I've missed anything,
cos I don't have enough cpu here
- It affects just about every script with a load of changed lines that
do not really have any meaningful significance. Would this create
embarassment for people who have their own sets of patches to
crosstool that they apply to each release?

How do people feel about this reorganisation? Is the fresh air it
creates worth the hassle?

    M

--
For unsubscribe information see http://sourceware.org/lists.html#faq



More information about the crossgcc mailing list