[isabelle-dev] Future and maintainance of ~isabelle/contrib_devel at TUM NFS

[Makarius]

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