Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Subject: Re: SableVM & Cygwin (was: Re: sablevm + windows) From: "Grzegorz B. Prokopski" To: "Gerrit P. Haase" , SableVM-devel ML Cc: Peter Lovell , cygwin AT cygwin DOT com Content-Type: text/plain Organization: SableVM - LGPL'ed Free Java VM http://sablevm.org Message-Id: <1097907484.2667.610.camel@localhost.localdomain> Mime-Version: 1.0 Date: Sat, 16 Oct 2004 02:18:32 -0400 Content-Transfer-Encoding: 7bit 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 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/