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-
_______________________________________________ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool