[Visionaries] dotnet platform support / gnu config.sub (long)

[Guido Draheim]

* short

The world has changed - there are commandline tools for unixish systems
that take a C program (not C#!) and compile them into a MSIL binary or
library. This makes it a valid crosscompile target for free software.
The free projects for the dotnet platform - mono, dotgnu, portablenet
and others - have developed runtime services that are usable now. Very
soon now, these will be installed in parallel to JVM in distros.

Looking into config.sub, libtool, automake etc., you'll notice that
there is not even minimal support for that platform. This e-mail is
just asking a thing that sounds simple but may turn out controversial:
            How to name the platform in config.sub?
That will have consequences when support for that crosscompile target
platform is being added to libtool and friends.

* long

Microsoft has been submitting its specifications to ECMA and the
free software projects are working hard to provide a portable
implementation of the services - being not bound to MS platforms
but especially usable on unix/X11 type systems. What is interesting
about the dotnet platform: it can process multiple different input
languages and compile into the dotnet intermediate language binary.

This is radically different from java history: there we had only
one input language (java source code in .java) and one output
binrary format (java byte code, linked into a .jar). That made
only for a minimal need of integration into gnu autotools. The
source language was created for one target platform, and the
source code was not quite able to get a benefit from autoconf'd
pieces.

The dotnet platform allows many input languages, including but
not limited to C/c++. Theoretically it is possible to pick up
traditional C software and spice them up with hints that will
make a dotnet compiler happy to create a dotnet binary from it.
That dotnet binary may be installed and packaged to be run on a
target system. Furthermore note the mono attempt of using a
GTK dotnet library, which perhaps makes porting of traditional
gui software easier - but in fact dotnet is not the least bound
to a gui, simple commandline programs are fine with dotnet too.

That situation calls for autotools support: a configure script
shall detect the (crosscompile) target platform and allow the
software to add options for that target. The same source might
be used for direct compilation to a cpu binary or being compiled
into an intermediate language binary. Note that dotgnu is also
working on targetting the java intermediate language. Anyway,
consider that the C/c++ frontend can read config.h #defines. I
am personally not sure however if that is all too reasonable
but we do not even have the first step.

The first step would be to actually _recognize_ the platform
and canonicalize the name of different projects and runtime
platforms into a name-triplet that build software can use to
select different build paths. That is definitely not limited
to gnu autotools. However, how to name the beast? What shall
be the common name, and how to disperse the platform variant
parts into the traditional config.sub platform triplet?

* technical

The list is not complete, be sure of that, and may or may
not turn out to be correct, including the information to be
outdated already the day you read this mail. The developments
in this area are _fast_, pushed by the industrial backup. As
of August 2003, Ximian is now part of the Novell group, with
Novell heads to assure that it does support the developments.

http://www.go-mono.org is affiliated with Ximian, there is
a C# compiler, the gtk# gui interface, and large parts of the
ecma provided dotnet libraries in the works. The commandline
tool is called 'csc' for 'c sharp compiler'. See also its page
at http://www.go-mono.org/c-sharp.html - the compiler takes
options and switches compatible with the microsoft compilers.

http://www.gnu.org/projects/dotgnu/ is affiated with, err,
the GNU project. There is C# compiler and since a short time
also a C compiler. The commandline tool is called 'cscc' for
'c sharp compiler collection' similar to gcc backronym. The
compiler takes options compatible with the gcc compilers. Via
links of portableNet one can reach the portableNet faq at
http://www.southern-storm.com.au/pnet_faq.html

The name for the target platform varies throughout, the term
dotnet is more or less seen as a marketing name, but with that
it has seen widespread awareness as a `name`. The binary
format is dubbed 'cil' in microsoft speak (common intermediate
language) but there are crossreferences with historic 'cil'
binary formats not related with dotnet at all. Hence some
prefer ms/cil or ms/il or short as 'msil'. However, there is
no specific bond with 'ms' especially for the free projects
building on the ecma specs, and so this might be inapropriate.

Note that the 'cscc' allows for '-mjvm' option to target the
java intermediate language. But there is no cousin to
explicitly set -mnet or similar. So, no tales of prior art:
http://www.southern-storm.com.au/docs/pnettools_2.html#IDX94
However, the savannah CVS has a modified config.sub available
in pnetC that sets basic_machine='cli-unknown' and os='none',
and the suite sets a #define __cli__

Other prior art in this respect would be the commandline tools
themselves which do start with "il*" when handling the binary
format, most prominently 'ilasm'. That'd be similar to some
elf tools or coff tools or pe/coff tools which use that
binary format as a prefix. However, config.sub has the tendency
to put the binary package variants into the 'os' part, and in
fact, 'il' is mostly a cil section wrapped into pe/coff, AFAIR.

That's all. Please contribute further references if you have
some. My personal preference would say to put "il" (or "cil")
as 'os', the project name as middle (vendor) part, and a
cunning "dot" in front making for a dot-mono-il platform
or a dot-pnet-il-gnu, or... :-)

-- guido                        http://google.de/search?q=guidod
GCS/E/S/P C++/++++$ ULHS L++w- N++@ d(+-) s+a- r+@>+++ y++ 5++X-