This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: SableVM & Cygwin (was: Re: sablevm + windows)


On Wed, 2004-10-13 at 11:57, Gerrit P. Haase wrote: 
> 1.
> I have a stripped down standalone libffi package with a shared libffi
> now.  This version is based on the sources from the cygwin release of
> gcc-3.3.3. You can take this package and maintain it, that means update
> it when Cygwin GCC is updated and integrate the changes happened in the
> libffi subdirectory.

I like this idea.  Because history shows we cannot count on having
independant releases of libffi from upstream, I having a separate
package of libffi (or libffi-derived/rebranded/whatever) library makes
sense.

I am perfectly fine with the idea of starting making idependant releases
of libffi within Cygwin.  This sounds little crazy that somebody who
just wants to compile SableVM has to fetch whole gcc-java package (which
is not small and actually does not contain everything we need).  This is
IMNSHO very good reason to have such releases within Cygwin.

Besides having this library available in Cygwin, we would also make _the
same sources_ available for people for independent download.  This way
we would not need to point people "Go, fetch huge GCC sources, maybe
hack a bit the build system, and compile yourself libffi".  This
involves no additional work over what's required to maintain Cygwin
package.

> 2.
> Include this stripped down libffi version with the SableVM sourcetree
> and link libffi into the main DLL as a convenience library.

Now I am seriously risking confusing everybody, so I'll try to explain
it clearly.  We're going to "merge" sablevm-classpath and sablevm into
one .tar.gz.  According to latest agreements and first tests (results
are in my sandbox) this "super-sablevm" tar.gz will actually contain
sablevm-x.y.z.tar.gz and sablevm-classpath-x.y.z.tar.gz plus a build
system with configure/Makefiles (from user POV it'd be just as natural
as the current system, with the difference that it'd require single
configure and single "make" invocation).  I see no reason why we could
not (at some later point) include "independant-libffi.tar.gz" into such
super-tarball of SableVM.  Note that this is much different from
including libffi code into sablevm itself.  (I hope I didn't confuse you
too much).

> IMO it would be easier to keep it uptodate when it is included with the
> SableVM sources and also distributed this way.  So one can continue when
> you or me are gone.

You know, this is like with Linux kernel.  The fact that something gets
merged in mainline does not necessarily mean it'll be always better
maintained.  There's many examples of things that got merged in Linux
and "died" and thing that have never been merged (because ex. they do
not "belong" to Linux kernel), but are well and alive.

On the organizational side, as I said before - we'll provide all the
necessary support, at least as good as SableVM itself has.

> I have a patch I can send you, there is the stripped down libffi
> integrated in the SablVM build.  The standalone libffi is available as
> separate package from my webserver:
> http://anfaenger.de/cygwin/cygwin-1.5/libffi-cygwin-standalone/

Great.  This might be something to start from.

> Ready compiled SableVM binary and source package:
> http://anfaenger.de/cygwin/cygwin-1.5/sablevm/
> 
> The source package includes also the patch and uses a statically libffi,
> so it doesn't need a FFI DLL.  Could you verify that this SableVM works
> as expected, please?

*2*MB diff that puts libffi in SableVM? Ouch!

............

I took a quick look at the non-libffi part of your patche.  In general
our approach is to integrate all reasonable changes required
by ports, so that SableVM worked on them out-of-the-box.  (2MB patch
hardly qualifies as reasonable, at least at the first sight)

Would it be possible to separate the changes you really had to do to
SableVM (and SableVM Classpath - on which changes I haven't looked yet)
from the rest, so that we could see clearly what the changes were?

Such cleaned-up diffs would really be very helpful.  Given the amount
of great work you put in porting SableVM to Cygwin - why not have an
out-of-the box support for Cygwin in the official SableVM?  This is
somethings that surely "belongs" to SableVM proper.

Thanks for helping us so much,

			Grzegorz B. Prokopski
-- 
Grzegorz B. Prokopski           <gadek@sablevm.org>
SableVM - Free, LGPL'ed Java VM  http://sablevm.org
Why SableVM ?!?                  http://sablevm.org/wiki/Features
Debian GNU/Linux - the Free OS   http://www.debian.org



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]