On Sat, 16 Jun 2012, Alexander Krauss wrote:
On 06/16/2012 02:11 PM, Jasmin Christian Blanchette wrote:
a) Subdirectories for each platform
/home/isabelle/contrib/
x86-linux/
x86_64-linux/
x86-cygwin/
...
Then, the universal component packages must be copied, symlinked or
hardlinked.
b) Different packages for different platforms, roughly as it is now...
/home/isabelle/contrib/
jdk-6u31_x86_64-linux/
jdk-6u31_x86-linux/
Then we need a /Admin/contributed_components file for each
platform, which lists the components relevant for that platform.
I would prefer both indeed:
a) architecture-sensitive organisation, but with universal components
directly under contrib (as is the case now)
b) separate component files for different platforms
I'm a bit puzzled here. What does "preferring both" means exactly?
And why does point (a) talk about universal components, when you
wrote that the time of platform-universal components is gone? What
are the precise implications for the (universal) components I'm
packaging (Kodkodi, CVC3, E, SPASS, Z3)?
"the time is gone" just means that we can no longer assume that every
component is platform-universal. You can continue building universal
components, and I would say this is still the preferred way wherever it can
be done with reasonable effort.
My impression from this entangled mail thread is that it is worth making
an extra effort to revive the original "universal component" idea.
De-facto http://isabelle.in.tum.de/website-Isabelle2012/dist has platform
diversity for the following special cases:
* Heap files: When IsaMakefiles and "isabelle make" are overcome at
last, we can let users build platform-specific heap files on the spot.
This will also save some download time (already 150 MB for HOL).
Heaps are not components, though.
* JDK: a bit of a mess due to unclear situation of Java 1.6 on Mac OS X
I hope to be able to make a unified Java 1.7 for all 3 platform
families before the next release. It will require some
de-Mac-ification of the official jEdit codebase, though.
* Special add-on components to make Windows/Cygwin work smoothly. For
now we can ignore this as genuine "add-ons", but in the longer run one
needs to include Windows into the testing infrastructure more
seriously, and people actually need to test it first-hand as well.
Having fully universal components has the main disadvantage of extra disk
space usage. For Isabelle2012 I have started already some adhoc purging
of unused platform directories just for the Windows bundle. We could
cultivate this idea, and make the platform-specific bundles exclude other
platforms, and maybe provide a universal bundle as well (or an easy way to
assemble one on the spot).
Makarius
_______________________________________________
isabelle-dev mailing list
[email protected]
https://mailmanbroy.informatik.tu-muenchen.de/mailman/listinfo/isabelle-dev
