Thread: [Sablevm-developer] Release progress - problems w/ 'make distcheck' of classpath
Brought to you by:
egagnon
Menu
▾
▴
sablevm-developer
|
From: Grzegorz B. P. <ga...@de...> - 2004-02-14 09:03:58
|
Hi all! Shortly. - Take a look at http://devel.sablevm.org/wiki/ReleaseProcess That's more less what I had in mind. Comments? - staging has now version '1.0.9+staging' - it should be less confusing (we'll make it 1.1.0+staging after 1.1.0 release, I guess). - I am missing only #3 to complete Prolog part, that is, I fixed SableVM 'make distcheck', updated INSTALL-DEVEL (which is both: Installation and Release Notes), but 'make distcheck' in classpath dies with this output: Found 2 semantic errors compiling "../../external/jaxp/source/javax/xml/transform/TransformerFactory.java": 94. throws TransformerFactoryConfigurationError ^----------------------------------^ *** Semantic Error: Type javax.xml.transform.TransformerFactoryConfigurationError was not found. 104. throw new TransformerFactoryConfigurationError(e); ^----------------------------------^ *** Semantic Error: A candidate for type "TransformerFactoryConfigurationError" was found, but it is invalid and needs to be fixed before this type will successfully compile. Found 3 semantic errors compiling "../../external/jaxp/source/javax/xml/transform/ClassStuff.java": 141. throw new TransformerFactoryConfigurationError (e, ^----------------------------------^ *** Semantic Error: A candidate for type "TransformerFactoryConfigurationError" was found, but it is invalid and needs to be fixed before this type will successfully compile. 145. throw new TransformerFactoryConfigurationError (e, ^----------------------------------^ *** Semantic Error: A candidate for type "TransformerFactoryConfigurationError" was found, but it is invalid and needs to be fixed before this type will successfully compile. 149. throw new TransformerFactoryConfigurationError (e, ^----------------------------------^ *** Semantic Error: A candidate for type "TransformerFactoryConfigurationError" was found, but it is invalid and needs to be fixed before this type will successfully compile. I guess some .java files aren't included in the tarball? or...? Help w/ this issue would be greatly apprieciated. GBP -> sleep -- Grzegorz B. Prokopski <ga...@de...> Debian GNU/Linux http://www.debian.org SableVM - LGPLed JVM http://www.sablevm.org Why SableVM ?!? http://devel.sablevm.org/wiki/WhySableVM |
|
From: Mark W. <ma...@kl...> - 2004-02-14 10:19:49
|
Hi,
On Sat, 2004-02-14 at 09:43, Grzegorz B. Prokopski wrote:
> but 'make distcheck' in classpath dies with this output:
>=20
> Found 2 semantic errors compiling
> "../../external/jaxp/source/javax/xml/transform/TransformerFactory.java":
>=20
> 94. throws TransformerFactoryConfigurationError
> ^----------------------------------^
> *** Semantic Error: Type
> javax.xml.transform.TransformerFactoryConfigurationError was not found.
>=20
>=20
> 104. throw new
> TransformerFactoryConfigurationError(e);
> ^----------------------------------^
> *** Semantic Error: A candidate for type
> "TransformerFactoryConfigurationError" was found, but it is invalid and
> needs to be fixed before this type will successfully compile.
>=20
> Found 3 semantic errors compiling
> "../../external/jaxp/source/javax/xml/transform/ClassStuff.java":
>=20
> 141. throw new TransformerFactoryConfigurationError (e,
> ^----------------------------------^
> *** Semantic Error: A candidate for type
> "TransformerFactoryConfigurationError" was found, but it is invalid and
> needs to be fixed before this type will successfully compile.
>=20
>=20
> 145. throw new TransformerFactoryConfigurationError (e,
> ^----------------------------------^
> *** Semantic Error: A candidate for type
> "TransformerFactoryConfigurationError" was found, but it is invalid and
> needs to be fixed before this type will successfully compile.
>=20
>=20
> 149. throw new TransformerFactoryConfigurationError (e,
> ^----------------------------------^
> *** Semantic Error: A candidate for type
> "TransformerFactoryConfigurationError" was found, but it is invalid and
> needs to be fixed before this type will successfully compile.
>=20
>=20
> I guess some .java files aren't included in the tarball? or...?
>=20
> Help w/ this issue would be greatly apprieciated.
Ugh, so it isn't my setup :{
I get the same with a clean "upstream" classpath.
Somehow one of the gnu jaxp .java files ends up in the root build dir!?!
I'll try to fix make distcheck for classpath soon (hopefully tonight).
Cheers,
Mark
P.S. To the Classpath hackers. Please do a make distcheeck from time to
time. Especially after you alter configure.ac, Makefile.am and/or added
a file.
|
|
From: Michael K. <kon...@gm...> - 2004-02-14 13:07:20
|
On Sat, Feb 14, 2004 at 11:17:25AM +0100, Mark Wielaard wrote:
> Hi,
>
> On Sat, 2004-02-14 at 09:43, Grzegorz B. Prokopski wrote:
> > but 'make distcheck' in classpath dies with this output:
> >
> > Found 2 semantic errors compiling
> > "../../external/jaxp/source/javax/xml/transform/TransformerFactory.java":
> >
> > 94. throws TransformerFactoryConfigurationError
> > ^----------------------------------^
> > *** Semantic Error: Type
> > javax.xml.transform.TransformerFactoryConfigurationError was not found.
> >
> >
> > 104. throw new
> > TransformerFactoryConfigurationError(e);
> > ^----------------------------------^
> > *** Semantic Error: A candidate for type
> > "TransformerFactoryConfigurationError" was found, but it is invalid and
> > needs to be fixed before this type will successfully compile.
> >
> > Found 3 semantic errors compiling
> > "../../external/jaxp/source/javax/xml/transform/ClassStuff.java":
> >
> > 141. throw new TransformerFactoryConfigurationError (e,
> > ^----------------------------------^
> > *** Semantic Error: A candidate for type
> > "TransformerFactoryConfigurationError" was found, but it is invalid and
> > needs to be fixed before this type will successfully compile.
> >
> >
> > 145. throw new TransformerFactoryConfigurationError (e,
> > ^----------------------------------^
> > *** Semantic Error: A candidate for type
> > "TransformerFactoryConfigurationError" was found, but it is invalid and
> > needs to be fixed before this type will successfully compile.
> >
> >
> > 149. throw new TransformerFactoryConfigurationError (e,
> > ^----------------------------------^
> > *** Semantic Error: A candidate for type
> > "TransformerFactoryConfigurationError" was found, but it is invalid and
> > needs to be fixed before this type will successfully compile.
> >
> >
> > I guess some .java files aren't included in the tarball? or...?
> >
> > Help w/ this issue would be greatly apprieciated.
>
> Ugh, so it isn't my setup :{
> I get the same with a clean "upstream" classpath.
> Somehow one of the gnu jaxp .java files ends up in the root build dir!?!
>
> I'll try to fix make distcheck for classpath soon (hopefully tonight).
>
> Cheers,
>
> Mark
>
> P.S. To the Classpath hackers. Please do a make distcheeck from time to
> time. Especially after you alter configure.ac, Makefile.am and/or added
> a file.
I do "make distcheck" on a daily basis in the daily build scripts on
Patrick Reali's server. They dont broke. I do this here locally too on a
regular basis and didnt broke.
I think this error occurs because of the compiler used to compile to
bytecode is buggy or configure did something strange. classpath uses
jikes (1.18) here locally to compile to bytecode and this works great.
Michael
|
|
From: Mark W. <ma...@kl...> - 2004-02-14 16:43:12
|
Hi,
On Sat, 2004-02-14 at 14:04, Michael Koch wrote:
> > > *** Semantic Error: A candidate for type
> > > "TransformerFactoryConfigurationError" was found, but it is invalid a=
nd
> > > needs to be fixed before this type will successfully compile.
> > >=20
> > >=20
> > > I guess some .java files aren't included in the tarball? or...?
> > >=20
> > > Help w/ this issue would be greatly apprieciated.
> >=20
> > Ugh, so it isn't my setup :{
> > I get the same with a clean "upstream" classpath.
> > Somehow one of the gnu jaxp .java files ends up in the root build dir!?=
!
> >=20
> > I'll try to fix make distcheck for classpath soon (hopefully tonight).
> >=20
>
> I do "make distcheck" on a daily basis in the daily build scripts on
> Patrick Reali's server. They dont broke. I do this here locally too on a
> regular basis and didnt broke.
>=20
> I think this error occurs because of the compiler used to compile to
> bytecode is buggy or configure did something strange. classpath uses
> jikes (1.18) here locally to compile to bytecode and this works great.
It wasn't the compiler. It seems to be my version of tar !?!?!
I just downgraded tar from 1.13.92-4 to 1.13.25-6
(Debian unstable to Debian testing version) and everything works again.
For some mysterious reason this newer version of tar puts
classpath-0.07+cvs/external/jaxp/source/javax/xml/transform/TransformerFact=
oryConfigurationError.java
in the tar file as plain "TransformerFactoryConfigurationError.java"
without any directory path. Can someone confirm that downgrading tar
helps.
It sounds fishy, but maybe it is because this path is just one larger
then 100 (101) characters. I read somewhere that tar handles file names
longer then 100 chars special (and different depending on Posix/GNU/etc)
Cheers,
Mark
P.S. I get much further now, but at the end I get the following error:
ERROR: files left in build directory after distclean:
./native/fdlibm/DEPDIR
./native/fdlibm/=3D
./native/jni/classpath/DEPDIR
./native/jni/classpath/=3D
./native/jni/java-awt/DEPDIR
./native/jni/java-awt/=3D
./native/jni/java-io/DEPDIR
./native/jni/java-io/=3D
./native/jni/java-lang/DEPDIR
./native/jni/java-lang/=3D
./native/jni/java-net/DEPDIR
./native/jni/java-net/=3D
./native/jni/java-nio/DEPDIR
./native/jni/java-nio/=3D
./native/jni/java-util/DEPDIR
./native/jni/java-util/=3D
./native/jni/gtk-peer/DEPDIR
./native/jni/gtk-peer/=3D
make[1]: *** [distcleancheck] Error 1
make[1]: Leaving directory
`/home/mark/src/classpath-obj/classpath-0.07+cvs/_build'
make: *** [distcheck] Error 2
Still investigating.
|
|
From: Michael K. <kon...@gm...> - 2004-02-14 16:55:58
|
On Sat, Feb 14, 2004 at 05:40:39PM +0100, Mark Wielaard wrote:
> Hi,
>
> On Sat, 2004-02-14 at 14:04, Michael Koch wrote:
> > > > *** Semantic Error: A candidate for type
> > > > "TransformerFactoryConfigurationError" was found, but it is invalid and
> > > > needs to be fixed before this type will successfully compile.
> > > >
> > > >
> > > > I guess some .java files aren't included in the tarball? or...?
> > > >
> > > > Help w/ this issue would be greatly apprieciated.
> > >
> > > Ugh, so it isn't my setup :{
> > > I get the same with a clean "upstream" classpath.
> > > Somehow one of the gnu jaxp .java files ends up in the root build dir!?!
> > >
> > > I'll try to fix make distcheck for classpath soon (hopefully tonight).
> > >
> >
> > I do "make distcheck" on a daily basis in the daily build scripts on
> > Patrick Reali's server. They dont broke. I do this here locally too on a
> > regular basis and didnt broke.
> >
> > I think this error occurs because of the compiler used to compile to
> > bytecode is buggy or configure did something strange. classpath uses
> > jikes (1.18) here locally to compile to bytecode and this works great.
>
> It wasn't the compiler. It seems to be my version of tar !?!?!
> I just downgraded tar from 1.13.92-4 to 1.13.25-6
> (Debian unstable to Debian testing version) and everything works again.
>
> For some mysterious reason this newer version of tar puts
> classpath-0.07+cvs/external/jaxp/source/javax/xml/transform/TransformerFactoryConfigurationError.java
> in the tar file as plain "TransformerFactoryConfigurationError.java"
> without any directory path. Can someone confirm that downgrading tar
> helps.
>
> It sounds fishy, but maybe it is because this path is just one larger
> then 100 (101) characters. I read somewhere that tar handles file names
> longer then 100 chars special (and different depending on Posix/GNU/etc)
Ah, yes. There is discussion about buggy tar in Debian unstable and
broken debs on debian-devel lately.
> P.S. I get much further now, but at the end I get the following error:
>
> ERROR: files left in build directory after distclean:
> ./native/fdlibm/DEPDIR
> ./native/fdlibm/=
> ./native/jni/classpath/DEPDIR
> ./native/jni/classpath/=
> ./native/jni/java-awt/DEPDIR
> ./native/jni/java-awt/=
> ./native/jni/java-io/DEPDIR
> ./native/jni/java-io/=
> ./native/jni/java-lang/DEPDIR
> ./native/jni/java-lang/=
> ./native/jni/java-net/DEPDIR
> ./native/jni/java-net/=
> ./native/jni/java-nio/DEPDIR
> ./native/jni/java-nio/=
> ./native/jni/java-util/DEPDIR
> ./native/jni/java-util/=
> ./native/jni/gtk-peer/DEPDIR
> ./native/jni/gtk-peer/=
> make[1]: *** [distcleancheck] Error 1
> make[1]: Leaving directory
> `/home/mark/src/classpath-obj/classpath-0.07+cvs/_build'
> make: *** [distcheck] Error 2
>
> Still investigating.
Hmmm, I dont get that either. What versions of autoconf/automake/libtool
are you using ?
Michael
|
|
From: Mark W. <ma...@kl...> - 2004-02-14 17:49:29
|
Hi, On Sat, 2004-02-14 at 17:53, Michael Koch wrote: > Ah, yes. There is discussion about buggy tar in Debian unstable and > broken debs on debian-devel lately. OK, then we are probably bitten by that one. Do you have a bug number? I couldn't find it immediately on bugs.debian.org. > > P.S. I get much further now, but at the end I get the following error: > >=20 > > ERROR: files left in build directory after distclean: > > ./native/fdlibm/DEPDIR > > ./native/fdlibm/=3D > > ./native/jni/classpath/DEPDIR > > ./native/jni/classpath/=3D > > ./native/jni/java-awt/DEPDIR > > ./native/jni/java-awt/=3D > > ./native/jni/java-io/DEPDIR > > ./native/jni/java-io/=3D > > ./native/jni/java-lang/DEPDIR > > ./native/jni/java-lang/=3D > > ./native/jni/java-net/DEPDIR > > ./native/jni/java-net/=3D > > ./native/jni/java-nio/DEPDIR > > ./native/jni/java-nio/=3D > > ./native/jni/java-util/DEPDIR > > ./native/jni/java-util/=3D > > ./native/jni/gtk-peer/DEPDIR > > ./native/jni/gtk-peer/=3D > > make[1]: *** [distcleancheck] Error 1 > > make[1]: Leaving directory > > `/home/mark/src/classpath-obj/classpath-0.07+cvs/_build' > > make: *** [distcheck] Error 2 > >=20 > > Still investigating. >=20 > Hmmm, I dont get that either. What versions of autoconf/automake/libtool > are you using ? Tried both automake 1.8.2 and 1.7.9. autoconf 2.59 and libtool 1.5.2 Cheers, Mark |
|
From: Michael K. <kon...@gm...> - 2004-02-14 19:07:23
|
On Sat, Feb 14, 2004 at 06:46:54PM +0100, Mark Wielaard wrote: > Hi, > > On Sat, 2004-02-14 at 17:53, Michael Koch wrote: > > Ah, yes. There is discussion about buggy tar in Debian unstable and > > broken debs on debian-devel lately. > > OK, then we are probably bitten by that one. > Do you have a bug number? I couldn't find it immediately on > bugs.debian.org. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=230910 I dont know if its related but it seems when downgrading helps you. Michael |
|
From: Chris P. <chr...@ma...> - 2004-02-14 17:31:53
|
Grzegorz B. Prokopski wrote: > Hi all! > > Shortly. > - Take a look at http://devel.sablevm.org/wiki/ReleaseProcess > That's more less what I had in mind. Comments? > > - staging has now version '1.0.9+staging' - it should be less confusing > (we'll make it 1.1.0+staging after 1.1.0 release, I guess). Seems okay. Except that staging changes frequently, so I suspect that when the version really does matter, we'll end up referring to it by revision number (e.g. staging-r1575). I'm not even sure if `1.0.9' or `1.1.0' is necessary in the name ... isn't it just obvious that staging is changes against bugfree at all times, which in turn is changes against the latest release? Then we never have to worry about naming the staging version. Similarly for sandboxes (my version is `chris') and bugfree. I don't know ... it's not a big deal. I think staging needs to be frozen with respect to SableVM functionality once the regression tests have started until the big merge into bugfree is made. But then I don't know -- do you want critical fixes to bugfree to happen on bugfree directly, and flow back into staging (or rather, be committed at the same time)? Because if not, it seems better to keep staging frozen until the actual release tag is made (I think freezing for the shortest amount of time is best). Anyway, whatever. In practice there are only a handful of developers, so it's not mission-critical whatever you do. The time spent figuring these things out and documenting them can offset the actual benefits. Chris |
|
From: Grzegorz B. P. <ga...@de...> - 2004-02-15 01:47:21
|
W li=B6cie z sob, 14-02-2004, godz. 12:30, Chris Pickett pisze:=20 > Grzegorz B. Prokopski wrote: > > Hi all! > >=20 > > Shortly. > > - Take a look at http://devel.sablevm.org/wiki/ReleaseProcess > > That's more less what I had in mind. Comments? > >=20 > > - staging has now version '1.0.9+staging' - it should be less confusi= ng > > (we'll make it 1.1.0+staging after 1.1.0 release, I guess). >=20 > Seems okay. Except that staging changes frequently, so I suspect that=20 > when the version really does matter, we'll end up referring to it by=20 > revision number (e.g. staging-r1575). I'm not even sure if `1.0.9' or=20 > `1.1.0' is necessary in the name ... isn't it just obvious that staging= =20 > is changes against bugfree at all times, which in turn is changes=20 > against the latest release? Then we never have to worry about naming=20 > the staging version. Similarly for sandboxes (my version is `chris')=20 > and bugfree. I don't know ... it's not a big deal. I tried to use the subversion's magic string substitution or even the svnversion utility to put the revision number there, but I am afraid it can't be done easily, unless we want to generate configure.ac from some other file or sth. like that (hmm... maybe use sed and generate it from itself in ./autogen.sh and on make dist? feel free to try it!) But I am sure staging shouldn't claim to be just "1.0.9" or any other release. I wanted to put "staging" name initialy, but I guess "1.0.9+staging" or (hopefuly soon) "1.1.0+staging" should at least give some more informations if we ask a user to do 'sablevm -V' for us. > I think staging needs to be frozen with respect to SableVM functionalit= y=20 > once the regression tests have started until the big merge into bugfree= =20 > is made. But then I don't know -- do you want critical fixes to bugfre= e=20 I agree. You should go and modify ReleaseProcess wiki page w/ this info. Other ideas/improvements are also appreciated. I tried to make it more a "checklist" so that we didn't forget about anything, and a guideline. Cheers, GBP --=20 Grzegorz B. Prokopski <ga...@de...> Debian GNU/Linux http://www.debian.org SableVM - LGPLed JVM http://www.sablevm.org Why SableVM ?!? http://devel.sablevm.org/wiki/WhySableVM |
|
From: Chris P. <chr...@ma...> - 2004-02-15 07:53:16
|
Grzegorz B. Prokopski wrote: >>Seems okay. Except that staging changes frequently, so I suspect that >>when the version really does matter, we'll end up referring to it by >>revision number (e.g. staging-r1575). I'm not even sure if `1.0.9' or >>`1.1.0' is necessary in the name ... isn't it just obvious that staging >>is changes against bugfree at all times, which in turn is changes >>against the latest release?> > > I tried to use the subversion's magic string substitution or even the > svnversion utility to put the revision number there, but I am afraid > it can't be done easily, unless we want to generate configure.ac from > some other file or sth. like that (hmm... maybe use sed and generate > it from itself in ./autogen.sh and on make dist? feel free to try it!) Okay, I'll try it if I need a break :) It seems like it could be quite useful ... > But I am sure staging shouldn't claim to be just "1.0.9" or any other > release. I wanted to put "staging" name initialy, but I guess > "1.0.9+staging" or (hopefuly soon) "1.1.0+staging" should at least give > some more informations if we ask a user to do 'sablevm -V' for us. Well, /only/ because I find this oddly interesting ... I see it as: staging == 1.0.9 + new changes == 1.0.9 + (staging - 1.0.9) == staging >>I think staging needs to be frozen with respect to SableVM functionality >>once the regression tests have started until the big merge into bugfree >>is made. But then I don't know -- do you want critical fixes to bugfree I meant, do you think the freeze should expire once the merge to bugfree is complete? Or once the release is made? Or once something else? It sounds like you're saying once the merge is complete. Cheers, Chris |
|
From: Etienne G. <gag...@uq...> - 2004-02-15 15:15:10
|
Chris Pickett wrote: >> But I am sure staging shouldn't claim to be just "1.0.9" or any other >> release. I wanted to put "staging" name initialy, but I guess >> "1.0.9+staging" or (hopefuly soon) "1.1.0+staging" should at least give >> some more informations if we ask a user to do 'sablevm -V' for us. > I think that sablevm staging should report: - SableVM version "Staging Sapshot" (optionally with a UTC date/time... but that would be a hassle as what we want is the svn revision checkin UTC date/time, not the "build or configure" date/time). Be warned: svn log reports "local" date/time. - it should also report about the status of "--disable-no-reorder-block" and all other "configure" options that were explicitly or implicitly selected. Etienne -- Etienne M. Gagnon, Ph.D. http://www.info.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ |
|
From: Mark W. <ma...@kl...> - 2004-02-14 23:24:20
|
Hi, On Sat, 2004-02-14 at 18:46, Mark Wielaard wrote: > > > P.S. I get much further now, but at the end I get the following error= : > > >=20 > > > ERROR: files left in build directory after distclean: > > > ./native/fdlibm/DEPDIR > > > ./native/fdlibm/=3D > > > [...] > > > ./native/jni/gtk-peer/DEPDIR > > > ./native/jni/gtk-peer/=3D > > > make[1]: *** [distcleancheck] Error 1 > > > make[1]: Leaving directory > > > `/home/mark/src/classpath-obj/classpath-0.07+cvs/_build' > > > make: *** [distcheck] Error 2 > > >=20 > > > Still investigating. > >=20 > > Hmmm, I dont get that either. What versions of autoconf/automake/libtoo= l > > are you using ? >=20 > Tried both automake 1.8.2 and 1.7.9. > autoconf 2.59 and libtool 1.5.2 Strange it now suddenly all works. I don't know what changed though. But with both automake 1.8.2 and 1.7.9 make distcheck works now. Yeah! Cheers, Mark |
|
From: Grzegorz B. P. <ga...@de...> - 2004-02-15 01:47:38
|
> > Tried both automake 1.8.2 and 1.7.9. > > autoconf 2.59 and libtool 1.5.2 > > Strange it now suddenly all works. > I don't know what changed though. But with both automake 1.8.2 and 1.7.9 > make distcheck works now. Yeah! Yup, downgrade of tar helped. We're at release 1.1.0 point now. Thanks a lot! Grzegorz B. Prokopski -- Grzegorz B. Prokopski <ga...@de...> Debian GNU/Linux http://www.debian.org SableVM - LGPLed JVM http://www.sablevm.org Why SableVM ?!? http://devel.sablevm.org/wiki/WhySableVM |
|
From: Chris P. <chr...@ma...> - 2004-02-15 18:38:02
|
Etienne Gagnon wrote: > Chris Pickett wrote: > >>> But I am sure staging shouldn't claim to be just "1.0.9" or any other >>> release. I wanted to put "staging" name initialy, but I guess >>> "1.0.9+staging" or (hopefuly soon) "1.1.0+staging" should at least give >>> some more informations if we ask a user to do 'sablevm -V' for us. >> > I think that sablevm staging should report: > - SableVM version "Staging Sapshot" (optionally with a UTC date/time... > but that would be a hassle as what we want is the svn revision checkin > UTC date/time, not the "build or configure" date/time). Be warned: > svn log reports "local" date/time. I don't think time is as meaningful as just revision number. $ svn info | grep "Last Changed Rev:" | cut -d' ' -f4 is a useful pipeline :) However, what's the best place to do the find and replace? In configure.ac? That way I think the number would make it into a tarball. > - it should also report about the status of "--disable-no-reorder-block" > and all other "configure" options that were explicitly or implicitly > selected. What if the binary / directory names simply reflect all non-default configure options, aside from the switch/direct/inlined choice? (so, sablevm-staging-rXXXX-inlined is the default) Otherwise, I'm not sure what you mean by "report". Where do you want this reported? $ cat config.log | grep '^#define _SABLEVM' seems pretty good -- I currently get the following: #define _SABLEVM_BIDIRECTIONAL_OBJECT_LAYOUT 1 #define _SABLEVM_COPY_GC 1 #define _SABLEVM_PACKAGE_NAME "sablevm" #define _SABLEVM_PACKAGE_VERSION "1.0.9" <-- becomes "staging-rXXXX" #define _SABLEVM_SWITCH_THREADED_INTERPRETER 1 Cheers, Chris |
|
From: Grzegorz B. P. <ga...@de...> - 2004-02-15 19:26:55
|
W li=B6cie z nie, 15-02-2004, godz. 13:36, Chris Pickett pisze:=20 > Etienne Gagnon wrote: > > - it should also report about the status of "--disable-no-reorder-blo= ck" > > and all other "configure" options that were explicitly or implicitl= y > > selected. >=20 > Otherwise, I'm not sure what you mean by "report". Where do you want=20 > this reported? $ sablevm -V SableVM version 1.0.9+staging - compile date and time: 2004-02-15 08:09:31 UTC - gcc version: 3.3.2 (Debian) - inlinability testing enabled - signal based exception detection - copying garbage collection - bidirectional object layout - inline-threaded interpreter Currently information about --disable-no-reorder-blocks is missing. GBP --=20 Grzegorz B. Prokopski <ga...@de...> Debian GNU/Linux http://www.debian.org SableVM - LGPLed JVM http://www.sablevm.org Why SableVM ?!? http://devel.sablevm.org/wiki/WhySableVM |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X