skaller wrote:
The key thing for the building portability is that the C and C++ compilers are represented by Python classes. There is a pre-programmed class for gcc, and another for MSVC++.
(a) Pick a portable scripting language which is readily available on all platforms. I chose Python. Perl would also do. If I had time to look into improving the GHC build system I'd definitely use Haskell as the scripting language. What's the point of having to learn more than one language to accomplish a task? Surely it is more
I suggest (for GHC) a Haskell class with instances for the different combinations of compilers and platforms and optimization levels. productive to add functionality to a single language (especially when it's only a case of writing some libraries) rather than grappling with the different syntaxes and limitations and quirks of a multitude of languages/tools and the problems of trying to get them all to work harmoniously together on different platforms? In concrete terms, for each sub-project within GHC ie each directory of source files I'd have a little Haskell program that was responsible for building that sub-project. Kind of like CM.make or the ML Basis system, except with the full power of Haskell so that complicated things such as building successive boot levels could easily be automated. (Ie instead of having a special tool like make that is invoked on "dead" data (supplied by autoconf etc) to drive the build process, instead use Haskell as a scripting language.) The top level build would be done by another Haskell program which delegated responsibility to the sub-programs in each directory. I'd include the complete source code for all the Haskell tools like Alex and Happy so they could be built the same way. In other words, the entire GHC project would be built by running a single Haskell program, and every single piece of source would either be a Haskell module or a file that is the input to a Haskell program that the main build-driver has built first (from Haskell sources). Therefore there would be no dependency on anything except GHC itself. To port GHC to a completely new platform, you'd of course need a Haskell compiler or interpreter already. However to bootstrap the process only a slow interpreter would be needed so as long as a portable pre-built bytecode version was available for download the only thing left to port would be a byte code interpreter which could just be a single file of c code. Perhaps this is too long-term a vision for solving the short term problems, but maybe it could be the basis of some future projects? Best regards, Brian.