Re: dotnet platform support / gnu config.sub (long)
Jim Pick wrote: Anyways, the config.sub name is just going to be used to define a target - so it makes sense to call the target Java, since it's only going to be used by tools generating Java byte code, which will run on Sun's JVM. Of course it will still run on other virtual machines that can't use the Java trademark, but that shouldn't be of any concern to the tools generating the code, IMHO. Yes, in the java world it is pretty strict what there is as names for the machine and language. My original mail was asking for a similar thing in the dotnet world where microsoft has used il internally for its vm, it was submitted as cil to ecma, the binaries get executed with ilrun, the class platform is now named dotnet, and the language is not strictly specified but csharp being new to the flock and sent in for standard in in the dotnet world as well. While java does have mostly its own toolchain from .java to .jar parts, there are tools in the ilvm world that convert .c/.cpp to an ilrun .exe, including free tools. That spawned the idea to make the platform be recognized as a crosscompile build target by the usual gnu build tools that also handle .c/.cpp input sources, and with config.sub heading off and trying to get a canonic form of whatever of the dozen of names is given on the commandline. We could as well clean out the java canonicalization from the patch that I would like to see put into gnu config, - yet as far as the discussion has shown the current scheme would still be good and usable around and in free projects as well. In consequence, the proposed scheme to identify vm-type platforms would be better supported by its examples living in config.sub from there on, calling them a *vm-* something $host. That would be great. BJE, what do you get from the discussion? Revised patch attached. cheers, -- guido http://google.de/search?q=guidod GCS/E/S/P C++/$ ULHS L++w- N++@ d(+-) s+a- r+@+++ y++ 5++X- (geekcode) Index: config.sub === RCS file: /cvsroot/config/config/config.sub,v retrieving revision 1.289 diff -u -r1.289 config.sub --- config.sub 3 Oct 2003 00:17:36 - 1.289 +++ config.sub 3 Oct 2003 11:05:04 - @@ -3,7 +3,7 @@ # Copyright (C) 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999, # 2000, 2001, 2002, 2003 Free Software Foundation, Inc. -timestamp='2003-08-18' +timestamp='2003-10-03' # This file is (in principle) common to ALL GNU software. # The presence of a machine in this file suggests that SOME GNU software @@ -218,6 +218,8 @@ basic_machine=m68k-atari os=-mint ;; +-jdk | -j2*) +os=-java$os esac # Decode aliases for certain CPU-COMPANY combinations. @@ -602,6 +604,22 @@ basic_machine=i386-unknown os=-vsta ;; +cil | ilvm | ilrun) +basic_machine=ilvm-pc +os=`echo -ilrun$os | sed -e 's/ilrun-ilrun/ilrun/'` +;; +cil32 | ilvm32 | ilrun32) +basic_machine=ilvm32-pc +os=`echo -ilrun$os | sed -e 's/ilrun-ilrun/ilrun/'` +;; +cil-* | ilvm-* | ilrun-*) +basic_machine=`echo $basic_machine | sed -e 's/^[^-]*/ilvm/'` +os=`echo -ilrun$os | sed -e 's/ilrun-ilrun/ilrun/'` +;; +cil32-* | ilvm32-* | ilrun32-*) +basic_machine=`echo $basic_machine | sed -e 's/^[^-]*/ilvm32/'` +os=`echo -ilrun$os | sed -e 's/ilrun-ilrun/ilrun/'` +;; iris | iris4d) basic_machine=mips-sgi case $os in @@ -616,6 +634,14 @@ basic_machine=m68k-isi os=-sysv ;; +jvm | java | jvm-java) + basic_machine=jvm-unknown +os=`echo -java$os | sed -e 's/java-java/java/'` +;; +jvm-* | java-*) +basic_machine=`echo $basic_machine | sed -e 's/^java/jvm/'` +os=`echo -java$os | sed -e 's/java-java/java/'` +;; m88k-omron*) basic_machine=m88k-omron ;; @@ -824,6 +850,14 @@ basic_machine=i586-unknown os=-pw32 ;; +pyvm | python) + basic_machine=pyvm-unknown +os=`echo -python$os | sed -e 's/python-python/python/'` +;; +pyvm-* | python-*) + basic_machine=`echo $basic_machine | sed -e 's/^python/pyvm/'` +os=`echo -python$os | sed -e 's/python-python/python/'` +;; rom68k) basic_machine=m68k-rom68k os=-coff @@ -1143,7 +1177,8 @@ | -storm-chaos* | -tops10* | -tenex* | -tops20* | -its* \ | -os2* | -vos* | -palmos* | -uclinux* | -nucleus* \
Re: [kaffe] Re: dotnet platform support / gnu config.sub (long)
Stephen Crawley writes: [EMAIL PROTECTED] said: Sun has a lot of lawyers, and they've been pretty aggressive than most about staking their claims on the linguistic turf (so they can sell it off). That's a rather twisted interpretation of Sun's use of trademarks, IMO. Another way of interpreting this is that Sun is trying to ensure that third-party Java vendors don't destroy Java's reputation for platform independence by shipping incompatible implementations. It doesn't matter what their motivation is. What we do know is that we can't call our system Java. Instead we have to call it something like The GNU Compiler for the Java[tm] Programming Language. As long as we stick to that, we're OK. It's useful for us to know that JVM is a trademark so we may not use it for our own work. This is a good thing for everyone ... apart from unscrupulous vendors like Microsoft. Because they claim Java Compatible(tm) as a trademark, it makes it hard to use a normal noun+verb sentence to say that we're compatible with Java -- we are, by most dictionary definitions, but we're not Java Compatible(tm), under Trademark law. Maybe we can say that we're interoperable? :-) A dictionary definition of compatible is useless to users of our software because it is too vague. We cannot plausibly claim our software to be compatible in all respects with Sun's Java. So any claim of compatibility must be qualified in some way to be meaningful. Yes. By trademarking Java Compatible, and restricting its use to implementations that pass the JCK tests, Sun is doing users of Java a big favor. It prevents shonky vendors from tricking end users with misleading claims of Java compatibility. All that we have to know is what we may and may not do. And that seems to be quite well-defined. Andrew. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [kaffe] Re: dotnet platform support / gnu config.sub (long)
[EMAIL PROTECTED] said: Sun has a lot of lawyers, and they've been pretty aggressive than most about staking their claims on the linguistic turf (so they can sell it off). That's a rather twisted interpretation of Sun's use of trademarks, IMO. Another way of interpreting this is that Sun is trying to ensure that third-party Java vendors don't destroy Java's reputation for platform independence by shipping incompatible implementations. This is a good thing for everyone ... apart from unscrupulous vendors like Microsoft. Because they claim Java Compatible(tm) as a trademark, it makes it hard to use a normal noun+verb sentence to say that we're compatible with Java -- we are, by most dictionary definitions, but we're not Java Compatible(tm), under Trademark law. Maybe we can say that we're interoperable? :-) A dictionary definition of compatible is useless to users of our software because it is too vague. We cannot plausibly claim our software to be compatible in all respects with Sun's Java. So any claim of compatibility must be qualified in some way to be meaningful. By trademarking Java Compatible, and restricting its use to implementations that pass the JCK tests, Sun is doing users of Java a big favor. It prevents shonky vendors from tricking end users with misleading claims of Java compatibility. IMO, the only point against Sun is their unwillingness to make the JCKs available under conditions that don't exclude typical Open Source java projects. -- Steve ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: dotnet platform support / gnu config.sub (long)
Guido Draheim wrote: For the java machine, the term `jvm` is used universally. I do not remember there were any dependency on pointer lengths, it runs in managed mode always. JVM, JDK, Java, etc. are all trade marks with associated conditions of use. http://www.sun.com/suntrademarks/#J . Are you sure you want/need to use them? Since ilvm64 may be run on a 32bit system, we do set the two cpu/vm types of ilvm and ilvm32 for the dotnet binaries and libraries. Alongside we use jvm for jar binaries A virtual machine capable of executing programs written in java programing language usually executes only classes stored in class files. Some virtual machines also have the capability of executing programs stored in zip archives, or jar archives. So 'jvm' is a misleading term here. Therefore, for jvm we do usually paste 'java' as interpreter and 'jdk' as basic service series. Likewise the dotnet binaries are given as 'ilrun' for the interpreter and 'mono' for the service series (or something alike). Not all java interpreters are called 'java'. there is gij, sablevm, kaffe, wonka, and a ton of others, that don't necessarily fit into this naming scheme. While some of them provide java-named wrapper scripts, I'm not sure if all of them do. jvm-sun-java-jdk jvm-sun-java-j2me jvm-sun-java-j2se jvm-sun-java-j2ee uh, what's that sun doing there? ;) what's the difference between jvm-sun-java-jdk and jvm-sun-java-j2se supposed to be? and so on ... I believe it would be better if you got in touch with kaffe, gcj, sablevm, classpath, debian-java etc. developers before you try to push something as big as this through as some kind of a GNU convention. I don't know much about .net yet, and being a kaffe developer, I'm more focussed on the java side of things. AFAIK, similar definitions have been tried before on debian-java, and failed. On the other hand, if the virtual machine implementors of varios GNU projects have already been consulted, and this is the concensual proposal, I'd like to have the reference to the mailing list threads ;) If that's not happended, then let's discuss this first, as it's a good idea, but it needs to be discussed in a broader, more realted audience, than the libtool mailing list, which, sincerely, doesn't seem like a good pick to debate the finer details of naming vm systems. ;) cheers, dalibor topic ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: dotnet platform support / gnu config.sub (long)
Guido Draheim wrote: Dalibor Topic wrote: Guido Draheim wrote: For the java machine, the term `jvm` is used universally. I do not remember there were any dependency on pointer lengths, it runs in managed mode always. JVM, JDK, Java, etc. are all trade marks with associated conditions of use. http://www.sun.com/suntrademarks/#J . Are you sure you want/need to use them? Yes. Actually, if the target is a java'ish machine then they will have to take care of any of that legalese themselves. The config.sub thing is not a java'ish thing itself here. - Furthermore, the use context is obviously talking about compatiblity with a certain vm type and not identity, as expressed in a lot of corners and we know that config.sub simply trying to get a canonic variant of certain arguments given. jvm, java and similar names _are_ the canonic variant of anything quite like it but not the product (trademark!) itself. AFAIK sun has quite strict rules about claiming compatibility with any of their Java products. Basically, you can't do it, unless you shell out big bucks for a license to their code. But I may misunderstand what you want to say. No, I've been trying to get a decent cc list for dotnet targets as it is a platform target that can have C/C++ source code as input - IOW a target that can be different than the primary target of that software. That's not the same for java. - I was including java (and python) in the description in an attempt to establish guidelines for (any) other VM-type target platforms. It's just that all those java'ish runtimes are all somehow different in my experience, so trying to put some kind of 'it's all mutually compatible java' cover on it doesn't really fit. A 'abstract machine'-'runtime' mapping only works as long as there are only a few runtimes available. In java's case, those days are long gone, and the number of options is quite huge, so fitting all of them under the same cap is quite complicated, if not impossible. I assume that in few years, c# will have the similar problem ;) cheers, dalibor topic ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: dotnet platform support / gnu config.sub (long)
Dalibor Topic wrote: Guido Draheim wrote: Dalibor Topic wrote: Guido Draheim wrote: For the java machine, the term `jvm` is used universally. I do not remember there were any dependency on pointer lengths, it runs in managed mode always. JVM, JDK, Java, etc. are all trade marks with associated conditions of use. http://www.sun.com/suntrademarks/#J . Are you sure you want/need to use them? Yes. Actually, if the target is a java'ish machine then they will have to take care of any of that legalese themselves. The config.sub thing is not a java'ish thing itself here. - Furthermore, the use context is obviously talking about compatiblity with a certain vm type and not identity, as expressed in a lot of corners and we know that config.sub simply trying to get a canonic variant of certain arguments given. jvm, java and similar names _are_ the canonic variant of anything quite like it but not the product (trademark!) itself. AFAIK sun has quite strict rules about claiming compatibility with any of their Java products. Basically, you can't do it, unless you shell out big bucks for a license to their code. But I may misunderstand what you want to say. Exactly that - there is no product here. It's a different thing whether addon software wants to be compilable for java licenced only or even java lookalikes. The difference is often not important during compiling (of source), it may only be interesting during advertising of a product (the binary). No, I've been trying to get a decent cc list for dotnet targets as it is a platform target that can have C/C++ source code as input - IOW a target that can be different than the primary target of that software. That's not the same for java. - I was including java (and python) in the description in an attempt to establish guidelines for (any) other VM-type target platforms. It's just that all those java'ish runtimes are all somehow different in my experience, so trying to put some kind of 'it's all mutually compatible java' cover on it doesn't really fit. A 'abstract machine'-'runtime' mapping only works as long as there are only a few runtimes available. In java's case, those days are long gone, and the number of options is quite huge, so fitting all of them under the same cap is quite complicated, if not impossible. I assume that in few years, c# will have the similar problem ;) *LOL* there are so many i*86 compatibles, and we still put them under the same umbrella for autoconf'iguring software. You know, here we speak about addon software that wants to configure itself to the _specifics_ of a _platform_. It is not important how many derivatives are there, or even lookalikes, - however for the task of getting at the specifics, and well, we _need_ a general guideline of the platform family in which we want to test for specifics. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [kaffe] Re: dotnet platform support / gnu config.sub (long)
On Wed, 24 Sep 2003 23:38:38 +0200 Dalibor Topic [EMAIL PROTECTED] wrote: JVM, JDK, Java, etc. are all trade marks with associated conditions of use. http://www.sun.com/suntrademarks/#J . Are you sure you want/need to use them? Yes. Actually, if the target is a java'ish machine then they will have to take care of any of that legalese themselves. The config.sub thing is not a java'ish thing itself here. - Furthermore, the use context is obviously talking about compatiblity with a certain vm type and not identity, as expressed in a lot of corners and we know that config.sub simply trying to get a canonic variant of certain arguments given. jvm, java and similar names _are_ the canonic variant of anything quite like it but not the product (trademark!) itself. AFAIK sun has quite strict rules about claiming compatibility with any of their Java products. Basically, you can't do it, unless you shell out big bucks for a license to their code. But I may misunderstand what you want to say. Sun has a lot of lawyers, and they've been pretty aggressive than most about staking their claims on the linguistic turf (so they can sell it off). Because they claim Java Compatible(tm) as a trademark, it makes it hard to use a normal noun+verb sentence to say that we're compatible with Java -- we are, by most dictionary definitions, but we're not Java Compatible(tm), under Trademark law. Maybe we can say that we're interoperable? :-) Anyways, the config.sub name is just going to be used to define a target - so it makes sense to call the target Java, since it's only going to be used by tools generating Java byte code, which will run on Sun's JVM. Of course it will still run on other virtual machines that can't use the Java trademark, but that shouldn't be of any concern to the tools generating the code, IMHO. Cheers, - Jim ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: dotnet platform support / gnu config.sub (long)
On Tue, 23 Sep 2003, Guido Draheim wrote: Guido Draheim wrote: * 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. Apart from some link-related discussions on the libtool-ML, there was not more than a single reply about the configtype name. No real interest in the canonic name of dotnet platforms for free software? Well, let's push it with a specific proposal. It shouldn't be supprizing that there was no libtool discussion on this topic. The libtool list is for discussions of libtool. While libtool does distribute a copies of the config.guess and config.sub files, it is not otherwise responsible for them. It does not look like libtool will serve a purpose at all for building MSIL binaries and libraries. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
dotnet platform support / gnu config.sub (long)
* 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:
Re: dotnet platform support / gnu config.sub (long)
On Thu, 11 Sep 2003, Guido Draheim wrote: * 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. Your very *long* posting failed to describe in which way the dotnet target varies from traditional targets. Microsoft's Visual Studio handles building for .net very similarly to traditional binaries. It uses normal object files and normal DLLs. These apparently normal files have had their format extended to support .net. For the C language, Microsoft's Visual Studio is able to link with traditional binary libraries. If the Unix dotnet target uses a similar paradigm, then compiling for dotnet could be as simple as adding some CPPFLAGS, CFLAGS, LDFLAGS, and LIBS, options. What does compilation of a dotnet library (.net assembly) and compilation of dotnet dependent programs look like under Unix? Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [Visionaries] dotnet platform support / gnu config.sub (long)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Guido Draheim [EMAIL PROTECTED] wrote: How to name the platform in config.sub? How about ecma335 ? Greetings, Norbert. - -- Founder Steering Committee member of http://gnu.org/projects/dotgnu/ Free Software Business Strategy Guide --- http://FreeStrategy.info Norbert Bollow, Weidlistr.18, CH-8624 Gruet (near Zurich, Switzerland) Tel +41 1 972 20 59Fax +41 1 972 20 69 http://norbert.ch -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/YK0MoYIVvXUl7DIRAjudAJ90st84sm8Y8juBKoIWq7XSelrT7wCbBLrO /kX3hx/E6ovjowi+mqMuw7g= =I5CU -END PGP SIGNATURE- ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
