From: Mark E. <ev...@pa...> - 2008-09-27 14:45:47
Attachments:
abcl-build.xml.diff
|
[Grrr! Somehow I lost a long reply to Ville about the build system: here's a shortened reply, but with a new conolidated patch.] 'build.xml' is not connected in any way to the 'autoconf' (i.e. the start a build by running './configure') way of building ABCL. There are actually three different ways of building ABCL, which I started to document in the lost post, but will write up again, and put on the [Google Code abcl-dynanmic-install wiki][1]. [1]: http://code.google.com/p/abcl-dynamic-install/wiki/BuildingFromSource Attached is a new patch to common-lisp.net code that is mostly complete from the perspective of building ABCL. The building J part of the patch is also more complete, but still doesn't make a satisfactory 'J' distribution that can be installed outside of the tree. Among other things, this patch creates a top-level 'abcl' wrapper, as Ville requested, on UNIX via the 'abcl.wrapper' target, i.e. unix$ ant abcl.wrapper will create a top-level 'abcl' script. Mark <ev...@pa...> -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now." |
From: Mark E. <ev...@pa...> - 2008-09-27 15:03:26
Attachments:
abcl-build.xml.diff
|
Please use the attached patch instead. The previous version failed to include the *.lisp source files in the JAR (I didn't realize this was necessary). Mark <ev...@pa...> -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now." |
From: Ville V. <vil...@gm...> - 2008-09-27 20:38:17
|
On Sat, Sep 27, 2008 at 6:03 PM, Mark Evenson <ev...@pa...> wrote: > Please use the attached patch instead. The previous version failed to > include the *.lisp source files in the JAR (I didn't realize this was > necessary). Works for me, runs ansi tests in the same amount of time as the lisp build. I previously had different results, but they were a result of personal brain damage caused by having java 1.6 around. I had a slight difference with running with the jar instead of with the class files, but that was a momentary load issue. According to my tests, the ant build result is equivalent to the lisp build result. Mark removed some install targets, I'm not sure if anyone needs those. Proper end-user installation would likely put the abcl.jar into some system-local part of the classpath and put the abcl script somewhere in the path. So, IMHO there's only one thing that needs to be examined; why are the lisp sources necessary to put into the jar? If they are not in the jar, abcl repl doesn't start. -VJV- |
From: Ville V. <vil...@gm...> - 2008-09-27 20:44:26
|
> So, IMHO there's only one thing that needs to be examined; why are the > lisp sources necessary to put into the jar? If they are not in the jar, abcl Also, we need to verify that the build/installation works with java homes that have spaces in the path, like "c:\program files\java\what ever". I received a request that this needs to be fixed. The lisp build used to have problems wrt that. |
From: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX - 2008-09-28 19:47:56
|
On Sat, Sep 27, 2008 at 10:44 PM, Ville Voutilainen <vil...@gm...> wrote: >> So, IMHO there's only one thing that needs to be examined; why are the >> lisp sources necessary to put into the jar? If they are not in the jar, abcl Right. Site.java uses boot.lisp; the ABCL bootup process does too (at least for the REPL, but maybe for all interpreter instances). I'd say the right strategy here is to keep removing .lisp files until the system won't start anymore. However, it would be a good bet to do a shortcut test which includes *only* boot.lisp and/or top-level.lisp (the real REPL processor). > Also, we need to verify that the build/installation works with java homes that > have spaces in the path, like "c:\program files\java\what ever". I received > a request that this needs to be fixed. The lisp build used to have problems > wrt that. You mean the submitted patch has this problem, or our current build files do? Bye, Erik. |
From: Mark E. <ev...@pa...> - 2008-09-29 12:11:42
|
Erik Huelsmann wrote: > On Sat, Sep 27, 2008 at 10:44 PM, Ville Voutilainen > <vil...@gm...> wrote: >>> So, IMHO there's only one thing that needs to be examined; why are the >>> lisp sources necessary to put into the jar? If they are not in the jar, abcl > > Right. Site.java uses boot.lisp; the ABCL bootup process does too (at > least for the REPL, but maybe for all interpreter instances). > > I'd say the right strategy here is to keep removing .lisp files until > the system won't start anymore. However, it would be a good bet to do > a shortcut test which includes *only* boot.lisp and/or top-level.lisp > (the real REPL processor). Ok, I'll look at this. >> Also, we need to verify that the build/installation works with java homes that >> have spaces in the path, like "c:\program files\java\what ever". I received >> a request that this needs to be fixed. The lisp build used to have problems >> wrt that. > > You mean the submitted patch has this problem, or our current build files do? The current build has the problem (Ville noted this is private email that didn't make it to the public list). I can duplicate the current install targets for 'abcl' and 'j' without too much additional work if that is requested (I am assumin it is unless someone explicitly states something different. And I can add targets to make distributions. Unfortunately, I am rather busy with work-related conferences this week, so the real problem is finding time in the next week to produce these changes. Please don't take a week's silence from me that I have given up on this, just that other priorities have intruded. Mark <ev...@pa...> -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now." |
From: Mark E. <ev...@pa...> - 2008-10-03 20:57:33
Attachments:
abcl@common-lisp.net.build.xml.diff
|
Mark Evenson wrote: > Erik Huelsmann wrote: >> On Sat, Sep 27, 2008 at 10:44 PM, Ville Voutilainen >> <vil...@gm...> wrote: >>>> So, IMHO there's only one thing that needs to be examined; why are the >>>> lisp sources necessary to put into the jar? If they are not in the jar, abcl >> Right. Site.java uses boot.lisp; the ABCL bootup process does too (at >> least for the REPL, but maybe for all interpreter instances). >> >> I'd say the right strategy here is to keep removing .lisp files until >> the system won't start anymore. However, it would be a good bet to do >> a shortcut test which includes *only* boot.lisp and/or top-level.lisp >> (the real REPL processor). Further work on this today shows that only including 'boot.lisp' and 'top-level.lisp' in 'abcl.jar' does not result in a viable runnable image, so the attached patch still includes all of the ABCL source lisp classes in the JAR. To facilitate debugging, a new target 'abcl.debug.jpda' has been introduced that builds a candidate 'abcl.jar', then spawns a separate JVM with only this in the classpath, and starts listening on port 6789 via the JPDA socket mechanism. To attach to this process with jdb, use: unix$ jdb -attach 6789 I found the command jdb$ trace methods THREAD-ID where THREAD-ID is the main thread to be useful to help debug the static initializers that blow up the stack. I am not quite finished debugging (I started to instrument the org.armedbead.lisp.Load.loadSystemClass code to help figure out what was going on), but I publish this Ant target in the hopes that it might be helpful. > >>> Also, we need to verify that the build/installation works with java homes that >>> have spaces in the path, like "c:\program files\java\what ever". I received >>> a request that this needs to be fixed. The lisp build used to have problems >>> wrt that. […] Not tested under win32 in the attached patch. > I can duplicate the current install targets for 'abcl' and 'j' without > too much additional work if that is requested (I am assumin it is unless > someone explicitly states something different. And I can add targets to > make distributions. This work has been started in this patch, but is not fully tested. Third patch on further work to [build.xml][1] attached as diff to common-lisp.net source tree. [1]: http://code.google.com/p/abcl-dynamic-install/source/diff?spec=svn141&r=141&format=side&path=/trunk/abcl/build.xml -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now." |
From: Ville V. <vil...@gm...> - 2008-09-29 05:37:24
|
>> Also, we need to verify that the build/installation works with java homes that >> have spaces in the path, like "c:\program files\java\what ever". I received > You mean the submitted patch has this problem, or our current build files do? Current ones. I haven't tested with the ant build, but in general ant is much better with paths includind spaces. |