[CT-NG] Status and future of crosstool-NG

["Yann E. MORIN" <yann dot morin dot 1998 at anciens dot enib dot fr>]

Good {morning,afternoon,evening} all!

Sorry in advance for this long post... :-/

First of all, I'd like to thank every one of you who helped with enhancing
crosstool-NG, either with new features or fixes, with suggestions, with bug
reports, with sample configurations, and other ways... That's nice! :-)

Now, there are some issues reamining that should get fixed. I'll try to build
a list below, and if any one feels like it, he/she's welcome to pick one! :-)

POSIX compliancy
Some parts of ./configure are not POSIXly correct. The rest of the scripts
need not be POSIX compliant, because ./configure is here to check before-hand
that the needed /extensions/ are present.

./configure behavior
./configure only checks for the needed tools, using a crude heuristic to
check availability and version conformity. Although it did fit nicely in the
beginning, it now ultimately sucks, as it is not expandable. On the other
hand, one alternative (using autotools and the likes) really sucks in other
ways, and I'm inclined to accept all ideas fixing ./configure without
resorting to autotools... See the archives for a recent post about it.

Portability
crosstool-NG is mainly writen with a Linux build host in mind. This means
that other systems (Cygwin, Solaris, MacOS...) have issues. Making it work
on as many systems as possible will ensure portability, but as a side effect
will also make it more robust.

Target systems
As for the build host, crosstool-NG currently targets mostly Linux-based
systems. It has some basic support for (real) bare-metal compiler with no C
library at all, but this is wobbly at best (works for me TM). It would be
nice if alternative target systems be eventually supported (Cygwin, BSD,
Solaris...)

Code cleanup
Currently, glibc and eglibc are treated as two different libraries, when
in fact they are very similar. Merging the two code paths would be a real
gain in terms of maintenance.
Also, overall code audits and cleanups are welcome...

Test suite
At this point, crosstool-NG has still to get a test suite. Testing gets longer
with each fix, enhancement or new sample, so it is highly time we get a decent
test-suite. Currently it is possible to test-build all the samples (at least
with some trivial scripting), but a systematic, build-and-run test would be
better. This one is tough.

Patchset auditing
I've done my best to construct a sane patchset for each version of each
component, often vampirised from some distributions (Gentoo comes to mind),
from buildroot, or from random patches on-line and on this list. Hopefully,
each patch origin is acknowkedged, either in the patch, in docs/CREDIT, or
in the svn log. This should have gone directly in the patch header, sorry :-(
It would be nice to have a reason for each patch (PR, bug report, upstream
fix...)

Reproducibility
It would be nice to have a script installed alongside the toolchain that,
when fired, will rebuild the exact same toolchain (possibly in an other
directory). A sort of tarball of the crosstool-NG build scripts, with the
toolchain's .config file, and all the components tarballs. That would highly
help on a production system, where the build tools often gets archived on a
CDROM, and recovery procedures require the full source to the build tools.

Components versions update
Add the latest versions of all components, and try to have all samples use
the highest version as possible. Currently, some are lagging behind...

Alternate components
- new target architectures
- adding newlib should be quite straight-forward, as there already are
  three C libraries, and mimicking will be easier
- on the kernel side, see above for alternate target systems.
- for the compiler, we have little choice away from gcc:
  - tcc might be too limited and may not fit well,
  - llvm I don't know,
  - icc is x86-only and binary-only (AFAICR)
  - others, don't the BSD guys had a project on an alternative to gcc?
- others have no viable alternatives, or even none at all

Documentation
I'm afraid I made an awfull job at keeping the documentation up-to-date
with the code... :-( Also, the documentation format is un-suitable to a
modern software, but I don't grok docbook, xml, or any other known-to-me
documentation format.

Others
There are many other areas of enhancement throughout crosstool-NG! Plenty
of work to be done! :-)

Next release
I was planning a 1.4.0 release end of January 2009, but that may eventually
slip until at least ./configure gets fixed and enhanced.
Also, I'd like as much fixes to go in, essentially portability fixes, even
if there are not so much new features. That'll make a saner base to later
build up a more feature-full 1.5.0 version.

I have no plan on dumping crosstool-NG, but I can no longer sustain the
development pace. If anyone wants to coordinate one of the above points,
I'd be more than happy! There is no deadline, no pressure except for the
ones you'd impose yourself! :-)

Thank you for reading through this long mail. And again, thank you for all
your contributions! :-)

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +0/33 662376056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| --==< ^_^ >==-- `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
`------------------------------^-------^------------------^--------------------'


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