[isabelle-dev] Future and maintainance of ~isabelle/contrib_devel at TUM NFS
makarius at sketis.net
Mon Jun 25 14:10:00 CEST 2012
On Sat, 16 Jun 2012, Alexander Krauss wrote:
> On 06/16/2012 02:11 PM, Jasmin Christian Blanchette wrote:
>>>> a) Subdirectories for each platform
>>>> Then, the universal component packages must be copied, symlinked or
>>>> b) Different packages for different platforms, roughly as it is now...
>>>> 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).
More information about the isabelle-dev