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/
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 so
> "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
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 wor
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?
>
> Implementat
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
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 up
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.
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
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 im
> "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
C
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
K
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 aga
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 pro
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 using
> > 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
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 replaceme
17 matches
Mail list logo
