Date: Tue, 20 Feb 2001 11:53:18 +0100
To: Patrick M Doane <patrick at watson.org>
Cc: Jacques Garrigue <garrigue at kurims.kyoto-u.ac.jp>, lablgtk at kaba.or.jp
Subject: Re: Improving lablgtk installation
Message-ID: <20010220115318.A32461 at lambda.u-strasbg.fr>
References: <20010220103752P.garrigue at kurims.kyoto-u.ac.jp> <Pine.BSF.3.96.1010219222705.4882A-100000 at fledge.watson.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.BSF.3.96.1010219222705.4882A-100000 at fledge.watson.org>; from patrick at watson.org on Mon, Feb 19, 2001 at 10:43:58PM -0500
From: Sven LUTHER <luther at dpt-info.u-strasbg.fr>
Sender: Sven LUTHER <luther at lambda.u-strasbg.fr>

On Mon, Feb 19, 2001 at 10:43:58PM -0500, Patrick M Doane wrote:
> Hi Jacques,
> 
> Thanks for your comments. Here are some additional ideas related to the
> topic.
> 
> On Tue, 20 Feb 2001, Jacques Garrigue wrote:
> 
> > > I think that making some minor modifications to the lablgtk installation
> > > could make the package more usable.
> > 
> > My impression is that the problem is not cause by lablgtk:
> > 
> > >   1) Install the .cmx files.  For users of 'ocamldep', the .cmx files
> > >      are generated as dependencies. I would also imagine this opens
> > >      up opportunities for inlining.
> > 
> > All the cmx are in lablgtk.cmxa, which should be all you need.
> 
> The interpretation here is largely dependent on your later point regarding
> library dependencies, so I'll comment there directly. 
> 
> > 
> > >   2) Build a native-code version of gtkThInit.ml
> > 
> > I'll think about this, but this file contains really a single line:
> >      let thread = GtkThread.start ()
> > It is only intended for toplevels.
> 
> I would like to create a native-code executable using threads and lablgtk. 
> It was my impression that using the GtkThread module was the right
> approach. I found that not using it created very poor thread performance
> but I could have been using the system incorrectly.  I could work from?
> 
> > >   3) Use 'cp -p' instead of regular 'cp' to preserve timestamps.
> > >      I usually have to 'touch' all the .cm[iox] files after
> > >      installation so that 'make' doesn't get confused.
> > >
> > >   4) Better support with OcamlMakefile. It's currently difficult to
> > >      use these init objects properly. They should be placed before all 
> > >      other .cmo files for order dependence reasons,
> > >      but it seems that only source files can show up in that location.
> > 
> > I think there is some confusion here: you should not have dependencies
> > on a library directory. If you want to add some, why not directly use
> > the source directory, which will have the expected behaviour.
> 
> I agree with your point about library dependencies, but can also
> understand the viewpoint that library dependencies should be expressed in
> a Makefile. If I upgrade to a new version of lablgtk, it would be nice for
> the make system to compile only the necessary files. If such a dependency
> is expressed, then the .cmx files from point #1 are useful to install. 
> 
> Note that I probably would not have given this much thought if the
> OcamlMakefile by Markus Mottl did not automatically include these
> dependencies.
> 
> > >   5) Optional installation using 'findlib'.
> > 
> > Good suggestion. But I'll first have to learn how to use findlib,
> > which I only installed once.
> 
> It's very straight-forward to use, I could send an example Makefile to the
> list if that would be useful. As a side note for Ocaml, it would really be
> great to see better package management integrated with Ocaml. At least the
> latest versions of the compiler support the '-where' option. 

Erm, ...

yes, but please don't forget to keep a standard install target as well for
people not usinf findlib at all.

(am having conversation with Gerd on debian-ocaml-maint list about this and
integration of findlib in debian packages of ocaml stuff right now ...)