Ptolemy build problems
Currently kepler uses 'ant ptolemy' to compile PtolemyII source code. Some
source code is just ignored (skipped) if it doesn't compile and isn't directly
used by Kepler. Often this problem is handled in PT by config/make dynamic
configuration of files.
We should make the ant ptolemy build 'smarter' to handle some of the dynamic
build problems (e.g Java 3D samples).
#1 Updated by Christopher Brooks almost 17 years ago
- I updated build-ptolemy.jar so that we now don't include things of little
use to Kepler. Basically, I looked at ptolemy/adm/gen-5.2/src.ex and the
makefile in the same directory and added a number of excludes to
build-ptolemy.jar. This reduces the size from 16.8Mb to 12.3Mb and
decreases the build time. Further reductions are possible.
One possibly minor issue is that I had to add the excludes in two places.
I don't know enough about ant to know if there is a workaround.
- I looked in to the problem I was having with the ptolemy/configs/ptiny/intro.htm
Part of the problem was the demosPtiny.htm file was not being created properly,
which I fixed. That file is checked in to CVS, so there is no need for ant to
try to build it. I fixed a few other missing file problems.
- It turns out that there is a problem with relative URLS and how ant builds
files. For example, ptolemy/configs/ptiny/intro.htm includes a URL
../../../doc/mainVergilPtiny.htm. The problem is that if we
$PTII/build/classes in the the classpath, then ptolemy/configs/ptiny/intro.htm
is found in $PTII/build/classes. However, ant puts the docs in
$PTII/build/doc, so the file we are looking for appears in
$PTII/build/doc/doc/mainVergilPtiny.htm and is not found relative to intro.htm.
Fortunately, if we stick with using ptolemy.jar and ptolemy-doc.jar, everything
works out because the HTML code in Ptolemy is jar URL aware.
If we could modify the ant configuration so that the doc directory was inside
classes, then this problem would go away for users that are not using
ptolemy.jar and ptolemy-doc.jar. However, this would mean modifying how
ant jars things up, I'm not sure if this is possible.
Anyway, short answer: use the jar files, the links will work out.
I added a comment to build.xml, but did not modify its functionality.
Before shipping alpha8, we should use ptolemy.jar, not build/classes
so that the URLs in intro.htm work
- At this point, the following links are bad in the configuration.
- The local pdfs are missing. This can be ignored, but when the installer
is shipped, they should probably be included.
- "Java Class Documentation" is broken.
Ptolemy expects to find the javadocs in doc/codeDoc.jar
build-ptolemy.xml has a jdoc rule that build the Ptolemy javadocs
and places them in build/docs/codeDoc. This can't be renamed to
build/doc/codeDoc because there is already a target there. Perhaps
it could be renamed to build/jdoc/doc/codeDoc and then a jar file
could be created of build/jdoc so that the javadocs would work out?
Maybe this is moot with the Kepler doc system, so it is not that important.
- The colt demo does not work because lib/ptcolt.jar is not included.
Colt is this pretty nifty random number toolkit, see
I think it probably has real value for Kepler.
If you want me to include it, I can update the configuration accordingly.
- The Matlab demo does not work because Matlab is not include.
Matlab is very useful, but the UI has a C component so it uses JNI so
it is not very portable. I'm not sure if it is worth Kepler's time
to include Matlab.
- None of the GR demos work because ptolemy/domains/gr is excluded.
GR uses Java3D, and while it is very slick, I think excluding it
from Kepler is reasonable
So, I think the right solution is for me to create an even smaller configuration
than ptiny that has just the domains and demos that Kepler needs. We
could use the dsp configuration here. I'll think this over.
Anyway, the upshot is that we are in much better shape for alpha8,
especially if we use ptolemy.jar.
#3 Updated by Matt Jones almost 17 years ago
The current Kepler installers don't use ptolemy.jar. Instead, the build process
under the "run" target builds a "kepler.jar" that contains all of the classes
from ptolemy and the classes from Kepler. We do this specifically so that we
can control the placement of the "exp" files in the resulting jar file (as they
override corresponding classes in ptolemy.jar).
Our initial builds did in fact use ptolemy.jar, but we ran into consistency
problems on different platforms and JVMs when loading the exp classes. So we
switched to the approach of building a consolidated kepler.jar file. But this
file takes quite a while to build, so the "run-dev" target was also created to
run directly from build/classes in order to speed up the edit-compile-test
cycle. This "run-dev" target is only intended to be used by developers, and is
not ultimately how kepler is shipped. So your suggestion to use ptolemy.jar
will not work without some significant changes to our build process.
I would like to eliminate this distinction between the two targets (run and
run-dev). I would also like to go back to using ptolemy.jar. But that requires
resolving our issues with inconsistent classloading for the exp directory. One
approach would be to eliminate the exp directory alltogether, which would also
be good. However, we clearly need a place to experiment with changes to the
ptolemy tree before checking them into ptolemy. I'm not sure the ptolemy group
wants all of the changes that we have made in the exp tree. We should, however,
be better about merging our code in exp regularly into the ptolemy tree. I will
enter a separate bug for this task.