Mark We must make sure to properly document the way someone can grab
Mark the upstream sources in case we want to pull in bug fixes later.
Tom I'll handle this as part of the import.
I've got the import working here. I'm going to wait for 0.93 to
branch before committing it. Meanwhile, if
RMS wrote:
That license is GPL-compatible, so it is ok to use the code
and ok to import it as a package that is not part of GCC
but distributed with it.
--
--Per Bothner
[EMAIL PROTECTED] http://per.bothner.com/
Hi Tom,
On Tue, 2006-11-28 at 15:42 -0700, Tom Tromey wrote:
Tom Ideally we could just import the ASM sources. I thought this idea was
Tom rejected, but I can't find a link. I'd like to revisit this, since
Tom this is the simplest way to solve the problem.
And unfortunately it seems
Mark Wielaard writes:
Hi Tom,
On Tue, 2006-11-28 at 15:42 -0700, Tom Tromey wrote:
Tom Ideally we could just import the ASM sources. I thought this idea was
Tom rejected, but I can't find a link. I'd like to revisit this, since
Tom this is the simplest way to solve the problem.
Hi Andrew,
On Wed, 2006-11-29 at 10:50 +, Andrew Haley wrote:
I would import whatever version currently works. Later we could
import newer versions, as desired, and update our code to match.
What is the exact version that works with all our tools atm?
Implementation-Title:
Mark Wielaard writes:
Hi Andrew,
On Wed, 2006-11-29 at 10:50 +, Andrew Haley wrote:
I would import whatever version currently works. Later we could
import newer versions, as desired, and update our code to match.
What is the exact version that works with all our
Mark == Mark Wielaard [EMAIL PROTECTED] writes:
Mark Thanks. I cannot find that as a source download. But it seems they have
Mark at least tagged their CVS with ASM_2_2_3 so we could pull the code from
Mark there.
Updating to the latest release would also be an option for us.
Moving our code
Andrew == Andrew Haley [EMAIL PROTECTED] writes:
Andrew Having gcj depend not only on ASM but also on a *specific version* of
Andrew ASM is intolerable. If gnu.bytecode will do the job, we should use
Andrew it.
I suppose it would be best to import some bytecode library source into
Classpath's
Tom Tromey writes:
Andrew == Andrew Haley [EMAIL PROTECTED] writes:
Andrew Having gcj depend not only on ASM but also on a *specific version* of
Andrew ASM is intolerable. If gnu.bytecode will do the job, we should use
Andrew it.
I suppose it would be best to import some bytecode
Andrew Haley wrote:
Tom Tromey writes:
Andrew == Andrew Haley [EMAIL PROTECTED] writes:
Andrew Having gcj depend not only on ASM but also on a *specific version* of
Andrew ASM is intolerable. If gnu.bytecode will do the job, we should use
Andrew it.
I suppose it would be best
Mark asked me to send some more info about this:
Tom Ideally we could just import the ASM sources. I thought this idea was
Tom rejected, but I can't find a link. I'd like to revisit this, since
Tom this is the simplest way to solve the problem.
The code is available from asm.objectweb.org.
Only part of RMIC (direct bytecode generation) is really dependent from
ASM. That part which supports the source code generation is not
dependent, was a separate compiler in the past and can be easily
separated apart again. If we do not like ASM, this should make using the
alternative
I recently tried to build Classpath and discovered that to build
gjavah and grmic, ASM is required. No problem, thought I, and
downloaded the latest version. Oddly, that didn't work.
So, I downloaded a few more versions of ASM until I found a version
that did work: version
Audrius Meskauskas wrote:
Only part of RMIC (direct bytecode generation) is really dependent from
ASM. That part which supports the source code generation is not
dependent, was a separate compiler in the past and can be easily
separated apart again. If we do not like ASM, this should make
Andrew Haley wrote:
Per, if you're listening: may we incorporate gnu.bytecode within
classpath?
Absolutely. Might as well get the most recent version from svn:
http://www.gnu.org/software/kawa/Getting-Kawa.html
However, Tom does have a point that sticking with ASM is probably
easier. Kawa
Thomas Fitzsimmons writes:
Audrius Meskauskas wrote:
Only part of RMIC (direct bytecode generation) is really dependent from
ASM. That part which supports the source code generation is not
dependent, was a separate compiler in the past and can be easily
separated apart again. If
Andrew Haley wrote:
Having gcj depend not only on ASM but also on a *specific version* of
ASM is intolerable. If gnu.bytecode will do the job, we should use
it.
While gnu.bytecode (along with gnu.math) has been fairly stable
for quite a while, and it probably has been the most stable part of
I recently tried to build Classpath and discovered that to build
gjavah and grmic, ASM is required. No problem, thought I, and
downloaded the latest version. Oddly, that didn't work.
So, I downloaded a few more versions of ASM until I found a version
that did work: version 2.3. This looked
18 matches
Mail list logo
