On Jan 4, 2008, at 9:39 AM, Ted Kosan wrote: > Robert, > > Do you think it is okay to manually edit the various build scripts to > make them build as desired and then just record what was edited in the > SPKG.txt file?
The route we have traditionally gone down is to place patch files in a "patches" directory and then apply them at compile time to whatever needs to be changed. > Also, how much software can we require the user have pre-installed on > their system before building jmol-src.spkg? At this point we require > they have a Sun JDK and ant installed. How many of the following > packages can we also require they have pre-installed (if any)? Due to the circular nature of building ant, let us assume as a first task that users have a (recent) JDK + ant. Hopefully some of the dependancies can be mitigated if we avoid supporting really old version of java. >> #ant-contrib. >> #apache commons-logging. >> #apache commons-lang. >> #bcmail -Bouncy Castle Crypto. >> #bcprov -Bouncy Castle Crypto > > The reason I am asking is that jmol will probably not be the only > Java-based package to be added to Sage and, if dependencies like this > are offloaded to the user's environment, they can be used by all > Java-based Sage packages that need them. > > You had also mentioned adding an Ant spkg to Sage earlier. This is an > interesting approach for dependency management, but if this route is > taken there will need to be quite a few Java-based spkg packages > created. > > Are we sure we want to bring Java-based packages into Sage in a big > way? I know that Gentoo found it extremely challenging to get > Java-based packages to work correctly with Gentoo. Here is an excerpt > form a Gentoo Java manual: If it looks like there are going to be several java-based spkg's in Sage, then I'd suggest making a java-deps package with the "common" ones, completely self-contained and build-able from source with the above. The jars would be placed in $SAGE_ROOT/local/java, and used/ copied from there to the appropriate places by the jmol (and other spkg) build scripts. > ---- > "Bundled Dependencies > > One of the features of Java has always been "compile once, run > everywhere." A consequence of this is that Java developers > traditionally bundle all library dependencies with their project's > distribution. While this might be convenient for the end-user, it > rapidly becomes problematic from a packager's point of view. > > For example, project A depends on C, and project B depends on C, and > you have project A and B installed, then you'd have two copies of C > installed to support it. And if there's new release of C with a bug or > security fix , you would want both A and B to take advantage of it. " > ---- > > Perhaps a better way to solve the jmol-src problem is to tell the > builder to build the following jars on their own and then place them > into the jmol jars directory before building jmon-src?: > > Acme.jar gnujaxp-onlysax.jar junit.jar > vecmath1.2-1.14.jar > ant-contrib.jar gnujaxp.jar netscape.jar > commons-cli-1.0.jar itext-1.4.5.jar saxon.jar This places the headache of building these jars from us to every user, and makes installing the spkg not "just work," so I would like to avoid that if possible. - Robert --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~----------~----~----~----~------~----~------~--~---
