[MLton] MLton build system portability

[skaller]

On Thu, 2007-07-26 at 21:19 +0300, Ville Laurikari wrote:

BTW: I have set up a sourceforge project 'smk' with list:


smk-design at lists.sourceforge.net

to discuss a portable package based build system design.
This is a "no implementing anything yet" project.

I would like to be able to make something which can build
compilers like Felix, Mlton, Haskell, etc, so the bulk
of the build scripts work the same on all platforms.

It would be really good if some compiler implementors would
join the project, because they're usually smart and know
about nasty build processes, but mainly because such projects
have the greatest difficulty porting.

> Can you elaborate on how GNU make and bash are worse (for portability)
> than Python?  It seems to me that both GNU make and bash have been
> ported to an even larger collection of platforms than Python.

Bash isn't an executable that just runs. It requires an extensive
environment to operate. It contains quite a lot of intrinsics that
don't mean anything on Windows, or operate differently.

However, at least part of the issue here isn't just bash itself,
but bash scripts, which often do things that don't make sense
on Windows.

For example what the heck does it mean when you say

	myprog

when bash searches the PATH variable? Remember Windows PATH
and Unix PATH are different.. :)

The bottom line here is simple: bash CANNOT be ported because it
is heavily tied up with the Unix environment: even if the C program
'bash' compiles, it won't execute 'bash scripts' correctly.

> Python is of course a real programming language and superior in that
> sense.

Yes.

> Did you perhaps mean that it's easier to write a portable build system
> in Python rather than make+bash, not the portability of make+bash as
> such?

I don't mean 'easier' I mean 'possible at all' :)

Just because some hacked up version of bash *compiles* on 
Windows doesn't mean it will execute scripts with the same
semantics as on Unix: 'porting' means it actually has to work :)

To make that happen, you really need a proper environment
such as Cygwin (and even that is problematic).

For example Ocaml team gave up on MSYS ..
due to 255 character limit on command lines. *real* windows
shell tools use @response files to solve that problem.
Ocaml found it easier to build the gcc version of Windows 
Ocaml with gcc --nocygwin, which runs MinGW compiler,
and uses bash .. but it uses bash under a sophisticated Unix
emulation environment.

But the real point is as above: if you really want to get 
control of a complex build process, you have to recognize
that a complex build process is a programming problem and
solve it with tools actually designed for programming!

Dynamic programming language (like Python) seem best suited
to this task -- I think the dynamic *typing* is not good,
but I don't know many tools that are sufficiently dynamic
which have static typing.

I do not think 'building' is any different from any other
programming task. We advocate MLton because it provides
an implementation of SML which is a high level language.
I'm not saying it is suitable for a build system, but I am
saying the same kinds of issues that lead us to choosing a high
level programming language for writing software also apply
to building software.

Python is NOT ideal. The Felix build system is fairly close
to collapse, it really strains the scalability of Python already.
I suspect Erlang is a much better choice -- process oriented,
and purely functional is hard to beat .. it just isn't as readily
available as Python (and it may be a bit hard to set up,
I'm not sure).

-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net