[Caml-list] GODI available for download

[Caml-list] GODI available for download

[Gerd Stolpmann]

Hi list,

In the past days I have worked on GODI, an experimental source-based
O'Caml distribution, and I think it is now worth a try.

You can get the current bootstrap tarball here:

http://www.ocaml-programming.de/packages/godi-bootstrap-20030730.tar.gz

Currently, GODI is based on 3.06, but I will switch to 3.07beta the next
days (and drop a message, if so).

It has been tested on Linux and Solaris.

Read the README file, it contains further instructions (and is currently
the only source of documentation).

Gerd

------------------------------------------------------------
README
------------------------------------------------------------

GODI is an experimental distribution of the Objective Caml language
as packages that can be automatically built from their sources. GODI
does not include pre-compiled binaries, but it is possible to create
them, even in packaged form.

GODI is derived from the NetBSD pkgsrc system (which is derived from
the FreeBSD port system), and has a similar way of dealing with
sources, although not everything is identical.

Basically, GODI is a framework to download, compile, install, and
package O'Caml software. This software is not included in GODI, but
GODI knows from which Internet sites it can be downloaded. To do so,
GODI provides small archives with build instructions, the build.tgz
archives. These instructions (basically Makefiles) are dynamically
added to the GODI framework, and extend it with the information needed
to deal with a certain piece of software.

After the software has been installed, it is always archived as
so-called binary packages. The binary packages can be easily
transferred to other computers with the same operating system, where
they can be added to the local GODI installations without having to
rebuild them again.

GODI knows about software dependencies, and automatically builds
prerequisites first. Furthermore, GODI can upgrade hierarchies of
dependent libraries by rebuilding the libraries in the right order.

...

-- 
------------------------------------------------------------
Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany 
gerd@gerd-stolpmann.de          http://www.gerd-stolpmann.de
------------------------------------------------------------

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] GODI available for download

[Fred Yankowski]

On Wed, Jul 30, 2003 at 11:41:27PM +0200, Gerd Stolpmann wrote:
> In the past days I have worked on GODI, an experimental source-based
> O'Caml distribution, and I think it is now worth a try.
> 
> You can get the current bootstrap tarball here:
> 
> http://www.ocaml-programming.de/packages/godi-bootstrap-20030730.tar.gz

I gave it a try on a Linux 2.4.20 / Debian 3.0 machine, where (as far
as I can recall) I have never installed ocaml.  Although I have lots
of experience with Debian package management, I've never BSD-style
package management tooks before.  So here's what ensued:

The godi-ocaml package built and installed easily.

To build godi-ocaml-graphics I had to first install the Debian
xdev-libs package to get the needed Xlib.h and Xutil.h files.  No big
deal.

Building godi-ocaml-labltk was a minor pain.  I had to install the
Debian tcl8.3-dev and tk8.3-dev packages to get the tcl.h and tk.h
files.  But building godi-ocaml-labtl would still fail to find those
headers.  I saw the note in the main README about "So if your tcl/tk
libraries are not found, you have to fix the problem in
godi-ocaml-src" and I eventually saw the note in the DESCR file for
godi-ocaml-src saying that tcl/tk should be installed first.

So then it was a bit of a mystery, how to rebuild godi-ocaml-src and
whatever depends on it.  Nothing much happened when I ran 'godi_build
godi-ocaml-src' again, so I ran 'godi_delete godi-ocaml-src' and tried
again, whereupon it rebuilt from source and finished OK.

Now, presumably, godi-caml and godi-caml-graphics need to be rebuilt
as well.  Doing "godi_build godi-ocaml" reports that the package is
already up-to-date.  Doing "godi_delete godi-ocaml" fails because the
godi-ocaml-graphics package depends on it, so I did "godi_delete -f
godi-ocaml" to force the delete.  That worked, mostly, but gave some
warnings about directories that could not be removed because they aren't
empty, because of files still there for godi-ocaml-graphics.  (OK,
that wasn't my brightest move, but I thought using -f would
recursively remove any packages that depend on godi-ocaml -- and that
did not happen).  Run "godi_delete godi-ocaml-graphics".  Now doing
"godi_build godi-ocaml" rebuilds from source ... but it fails near the
end because a lib/ocaml/std-lib/ directory already exists.  Remove
that and try again; now the build finishes OK.

Build godi-ocaml-graphics again; OK.  And now building
godi-ocaml-labltk works just fine.  Minimal testing suggests that the
executables are working well.  ocamlbrowser runs OK.

So, that's how it went for someone who knows Linux system admin well,
but has no experience with BSD packaging tools and almost no
experience with ocaml distribution/packaging.  The "GODI" tools work
well, but I need a bit more information about their theory of
operation to understand how to recover when things go wrong.  I'd also
like to understand the role of the godi-ocaml-src package better, and
what sort of implicit dependencies other GODI ocaml packages have on
it.

Overall, it's an impressive first cut at an easy to use package
management system for Ocaml.

-- 
Fred Yankowski      fred@ontosys.com           tel: +1.630.879.1312
OntoSys, Inc	    PGP keyID: 7B449345        fax: +1.630.879.1370
www.ontosys.com     38W242 Deerpath Rd, Batavia, IL 60510-9461, USA

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] GODI available for download

[Gerd Stolpmann]

Am Don, 2003-07-31 um 18.51 schrieb Fred Yankowski:
> On Wed, Jul 30, 2003 at 11:41:27PM +0200, Gerd Stolpmann wrote:
> > In the past days I have worked on GODI, an experimental source-based
> > O'Caml distribution, and I think it is now worth a try.
> > 
> > You can get the current bootstrap tarball here:
> > 
> > http://www.ocaml-programming.de/packages/godi-bootstrap-20030730.tar.gz
> 
> I gave it a try on a Linux 2.4.20 / Debian 3.0 machine, where (as far
> as I can recall) I have never installed ocaml.  Although I have lots
> of experience with Debian package management, I've never BSD-style
> package management tooks before.  So here's what ensued:

Thank you very much. I need more such user reports to make GODI as easy
and as reliable as possible.

> The godi-ocaml package built and installed easily.
> 
> To build godi-ocaml-graphics I had to first install the Debian
> xdev-libs package to get the needed Xlib.h and Xutil.h files.  No big
> deal.

Ok, I will add a hint to the README.

> Building godi-ocaml-labltk was a minor pain.  I had to install the
> Debian tcl8.3-dev and tk8.3-dev packages to get the tcl.h and tk.h
> files.  But building godi-ocaml-labtl would still fail to find those
> headers.  I saw the note in the main README about "So if your tcl/tk
> libraries are not found, you have to fix the problem in
> godi-ocaml-src" and I eventually saw the note in the DESCR file for
> godi-ocaml-src saying that tcl/tk should be installed first.

The reason for this strange dependency is that the O'Caml sources
contain both the base system and the labltk code, but that I wanted to
split it up for GODI. Not for everybody labltk is important, so it
should be possible to install only the base system without labltk.
However, because the base system and labltk are configured by the same
script, the question arose where to put this common configuration step.
This is the idea of godi-ocaml-src, it configures all of the O'Caml
system and saves the configuration such that the other packages
(godi-ocaml, godi-ocaml-graphics, and godi-ocaml-labltk) can find it and
use it.

Maybe I should rename it to godi-ocaml-config to make this role clearer.

> So then it was a bit of a mystery, how to rebuild godi-ocaml-src and
> whatever depends on it.  Nothing much happened when I ran 'godi_build
> godi-ocaml-src' again, 

Because it thinks it is up to date. godi_build -force godi-ocaml-src
would do it.

Again a useful addition to the README file.

> so I ran 'godi_delete godi-ocaml-src' and tried
> again, whereupon it rebuilt from source and finished OK.

So you were able to help yourself.

> Now, presumably, godi-caml and godi-caml-graphics need to be rebuilt
> as well.  Doing "godi_build godi-ocaml" reports that the package is
> already up-to-date.  Doing "godi_delete godi-ocaml" fails because the
> godi-ocaml-graphics package depends on it, so I did "godi_delete -f
> godi-ocaml" to force the delete.  

The -f option allows you to break the system, and it is normally not a
good idea. The -r option would have been right, because it deletes the
dependent packages, too.

> That worked, mostly, but gave some
> warnings about directories that could not be removed because they aren't
> empty, because of files still there for godi-ocaml-graphics.  (OK,
> that wasn't my brightest move, but I thought using -f would
> recursively remove any packages that depend on godi-ocaml -- and that
> did not happen).  

Yes, -r would do that.

> Run "godi_delete godi-ocaml-graphics".  Now doing
> "godi_build godi-ocaml" rebuilds from source ... but it fails near the
> end because a lib/ocaml/std-lib/ directory already exists.  Remove
> that and try again; now the build finishes OK.

This is one of the problems with GODI: you normally cannot install over
old files, because the installation routines are not intelligent enough.

> Build godi-ocaml-graphics again; OK.  And now building
> godi-ocaml-labltk works just fine.  Minimal testing suggests that the
> executables are working well.  ocamlbrowser runs OK.
> 
> So, that's how it went for someone who knows Linux system admin well,
> but has no experience with BSD packaging tools and almost no
> experience with ocaml distribution/packaging.  The "GODI" tools work
> well, but I need a bit more information about their theory of
> operation to understand how to recover when things go wrong.

Well, the documentation is not complete enough. In principle, it works
the same way as the NetBSD tools; maybe I should add an example how to
do the installation steps manually, and add a pointer to the NetBSD
docs.

>  I'd also
> like to understand the role of the godi-ocaml-src package better, and
> what sort of implicit dependencies other GODI ocaml packages have on
> it.

godi-ocaml-src unpacks the O'Caml sources, configures them, and creates
a tar.gz archive of them, so other packages can extract the already
configured source tree from it.

> Overall, it's an impressive first cut at an easy to use package
> management system for Ocaml.

I hope the remaining difficulties can be resolved, so it would be easy
for everybody.

Gerd
-- 
------------------------------------------------------------
Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany 
gerd@gerd-stolpmann.de          http://www.gerd-stolpmann.de
------------------------------------------------------------

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] GODI available for download

[Jacques Garrigue]

Hi Gerd,

I attempted to install godi on FreeBSD 5.1, but my first attempt
lamentably failed.
The error I got was
===> Creating sample godi.conf
===> Installing BSD compatible install script
===> Installing bmake
mkdir: /usr/opt/godi/man/man1: File exists
Failure!
This seems to come from a missing -p argument to mkdir in bootstrap.
I join a patch.

The fix was easy, but getting it to work difficult, as you have to
erase the godi directory, and use the cleanup script in the
distribution before recompiling everything (strange for such a small
detail).
Also, godi_build and godi_info were not installed, and I had to
install them by hand.
Next, building godi-ocaml and godi-ocaml-labltk. godi-ocaml went fine,
but godi-ocaml-labltk failed, because it needs some configuration
options (I see no way to pass them). Since I'm used to BSD packages, I
go to the godi-ocaml-labltk/work directory, and reconfigure by hand.
Build goes fine, but it uses ocamlopt rather than the faster
ocamlopt.opt.

I was also a bit wondering why it installs so many utilities, as they
are all there already on FreeBSD :-) But compatibility can be a pain.

I have two questions concerning godi itself:
 - is it a good idea to use a small tgz by package?
   we might en up with lots of them!
   personnally I would rather go for updating directly from a CVS
   repository, and eventually distribute a big tgz containing all
   instruction corresponding to a specific version of ocaml.
   but you may have your reasons.
 - what about windows? Do you think it is reasonnable to have a binary
   distribution of godi with all the necessary commands (not depending
   on cygwin)? Or a distribution on top of cygwin.
   Not depending on cygwin would be a big plus for occasional users.

Regards,

        Jacques Garrigue

--- bootstrap.orig	Thu Jul 31 23:34:07 2003
+++ bootstrap	Sat Aug  2 11:37:10 2003
@@ -339,7 +339,7 @@
 (cd bmake; $shprog ./configure --prefix=$prefix --with-default-sys-path=$prefix/share/mk $configargs && make -f makefile.boot bootstrap && env BINDIR=$prefix/bin $BSTRAP_ENV ./bmake -f Makefile install) 2>&1
 ln -s bmake $prefix/bin/godi_make
 # The manpage is not installed. Why?
-mkdir $prefix/man/man1
+$mkdirprog -p $prefix/man/man1
 cp bmake/make.1 $prefix/man/man1/godi_bmake.1
 
 # bootstrap lukemftp
@@ -415,7 +415,7 @@
 
 # Move pkgsrc in place
 pkgsrcdir=$prefix/build
-mkdir $pkgsrcdir
+$mkdirprog -p $pkgsrcdir
 cpio=$prefix/bin/godi_cpio
 
 (   cd pkgsrc

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] GODI available for download

[Alexander V. Voinov]

Hi Jacques et al.

Jacques Garrigue wrote:

> I have two questions concerning godi itself:
>  - is it a good idea to use a small tgz by package?
>    we might en up with lots of them!
>    personnally I would rather go for updating directly from a CVS
>    repository, and eventually distribute a big tgz containing all
>    instruction corresponding to a specific version of ocaml.
>    but you may have your reasons.

If there is a way to [interactively] select components to install, with all 
dependences transitively added, a one big package may be better. (bandwidths are 
wide and our disks get larger, nowadays...)

>  - what about windows? Do you think it is reasonnable to have a binary
>    distribution of godi with all the necessary commands (not depending
>    on cygwin)? Or a distribution on top of cygwin.
>    Not depending on cygwin would be a big plus for occasional users.

It would be a big plus to have a binary installation, not depending on cygwin. 
Though my main development platform is u*x, I found that it is quite easy and 
straighforward to develop apps with MSVC and OCaml. (that is the chance that you 
deadly need cygwin to port your app to win32 is less than one would expect.)

Alexander



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] GODI available for download

[Jacques Garrigue]

Some more considerations on my experience.

> Next, building godi-ocaml and godi-ocaml-labltk. godi-ocaml went fine,
> but godi-ocaml-labltk failed, because it needs some configuration
> options (I see no way to pass them). Since I'm used to BSD packages, I
> go to the godi-ocaml-labltk/work directory, and reconfigure by hand.

I realize now that this configuration problem is going to be very
complicated. BSD packages are OS-oriented: they assume a closed world,
where everything is controlled by the packaging system. So you don't
need to tell them where something is on the system, they already know
it.

With godi, the situation is different. For instance, tcl/tk headers
may be in many places, maybe even several versions of them, and the
user should be able to indicate where to find them. Same thing for
camlimages, lablgl, lablgtk, etc...
My feeling is that there has to be a way to give this information
by hand the first time you install a package, and these parameters
would be reused in following installations. When the package is
installed as a dependency, this may require some interaction from the
user.
Also, the possibility of finishing the work by hand must be left,
otherwise recovering from simple configurations bugs can become
unwieldly.

I'm afraid this is just one example of mismatch between an
OS-oriented packager and a language-oriented multi-platform packager.

Another one is the use of makefiles internally and in packages. While
makefiles are not intrinsically bad, they have one big default: they
depend heavily on the behaviour of external commands on the system. If
you have only platform this is not a problem: you just have to check
once that this works, but if you must handle multiple platforms, it is
very hard to be sure that the Makefile is portable.
I don't know how CPAN handles that, but this is going to be painful.
Using an ocaml only tool like ocamake may be an interesting option, at
least for simple packages.

Just some thoughts.
I certainly believe that godi is a big step in the right direction.

Jacques Garrigue

P.S. A small detail, but would it be hard to replace godi_ftp by
fetch? On my system godi_ftp is 351K whereas fetch is only 18K. I
suppose this is also reflected by the size of the sources.
I wonder also if there is a packaging system based on gmake rather
than bmake. It feels a bit strange to install bmake only for internal
purposes.

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

[Caml-list] Re: GODI available for download

[Alain]

Hi,

Have a try on MacOS X, quickly interrupted because the native
filesystem (HFS+) is not "a case-sensitive filesystem".

I will retry soon with on a computer with an UFS partition.
But this is annoying, most Darwin's users use HFS+.

regards,
Alain.

--
quote godi output:

===> Testing file system case sensitivity
"/Users/alain/Sources/godi" needs to be on a case-sensitive filesystem 
(see README.Darwin)
Failure!


-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Re: GODI available for download

[David Brown]

On Sat, Aug 02, 2003 at 01:54:34PM +0200, Alain wrote:

> Have a try on MacOS X, quickly interrupted because the native
> filesystem (HFS+) is not "a case-sensitive filesystem".
> 
> I will retry soon with on a computer with an UFS partition.
> But this is annoying, most Darwin's users use HFS+.

I agree with this.  Requiring a case-sensitive filesystem will be a show
stopper for an increasing number of systems.

One question is, does GODI really require that?  HFS preserves the case
of filenames, and usually you can't tell it is case insensitive.  Only
if you try to create two filenames that differ only in case do you
notice the problem.

Dave

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] GODI available for download

[Sven Luther]

On Thu, Jul 31, 2003 at 11:51:06AM -0500, Fred Yankowski wrote:
> On Wed, Jul 30, 2003 at 11:41:27PM +0200, Gerd Stolpmann wrote:
> > In the past days I have worked on GODI, an experimental source-based
> > O'Caml distribution, and I think it is now worth a try.
> > 
> > You can get the current bootstrap tarball here:
> > 
> > http://www.ocaml-programming.de/packages/godi-bootstrap-20030730.tar.gz
> 
> I gave it a try on a Linux 2.4.20 / Debian 3.0 machine, where (as far
> as I can recall) I have never installed ocaml.  Although I have lots
> of experience with Debian package management, I've never BSD-style
> package management tooks before.  So here's what ensued:
> 
> The godi-ocaml package built and installed easily.
> 
> To build godi-ocaml-graphics I had to first install the Debian
> xdev-libs package to get the needed Xlib.h and Xutil.h files.  No big
> deal.
> 
> Building godi-ocaml-labltk was a minor pain.  I had to install the
> Debian tcl8.3-dev and tk8.3-dev packages to get the tcl.h and tk.h

Notice that i build the ocaml debian packages with :

                -tklibs "-L/usr/lib -ltk8.3 -ltcl8.3"

Friendly,

Sven Luther

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] GODI available for download

[Gerd Stolpmann]

Am Sam, 2003-08-02 um 05.28 schrieb Jacques Garrigue:
> Hi Gerd,
> 
> I attempted to install godi on FreeBSD 5.1, but my first attempt
> lamentably failed.
> The error I got was
> [...]
> I join a patch.

Thank you.

> The fix was easy, but getting it to work difficult, as you have to
> erase the godi directory, and use the cleanup script in the
> distribution before recompiling everything (strange for such a small
> detail).

The bootstrap script uses the binaries it creates; installations and
compilations are not separated, so you cannot restart at the failed
step. I am not really happy about that, but I hope that fixes will no
longer be necessary when the bootstrap process stabilizes.

> Also, godi_build and godi_info were not installed, and I had to
> install them by hand.

I guess because the script did run until its end (it is a "set -e"
script, so it stops after the first error).

> Next, building godi-ocaml and godi-ocaml-labltk. godi-ocaml went fine,
> but godi-ocaml-labltk failed, because it needs some configuration
> options (I see no way to pass them). 

The idea is to put all configuration options into godi.conf, and that
every driver Makefile pulls the options it needs from this file.

> Since I'm used to BSD packages, I
> go to the godi-ocaml-labltk/work directory, and reconfigure by hand.
> Build goes fine, but it uses ocamlopt rather than the faster
> ocamlopt.opt.
> 
> I was also a bit wondering why it installs so many utilities, as they
> are all there already on FreeBSD :-) But compatibility can be a pain.

I have simply copied them from the NetBSD bootstrap script. I do not
know whether we need all them (for the uninformed reader, we are talking
about BSD make, lukemftp, pax, digest, mtree, and the tools for the
binary packages). I guess mtree is not used at all because it requires
root privileges, so it should be possible to omit it. Regarding bmake, I
do not know how identical the NetBSD and FreeBSD versions are; it looks
like that they have been independently developed after the fork (the
FreeBSD man page lists fewer syntax elements than the NetBSD version).
You can try to make the godi_make symlink pointing to the FreeBSD
version. pax (which is a tool implementing the tar and cpio commands) is
standardized, but the danger is too big that non-POSIX versions like
GNU-tar are unintentionally used. The differences are small, but I do
not want to get bug reports because of deviating tar formats.

Regarding ftp we can try to let the script find out the native version
and use it.

> I have two questions concerning godi itself:
>  - is it a good idea to use a small tgz by package?
>    we might en up with lots of them!
>    personnally I would rather go for updating directly from a CVS
>    repository, and eventually distribute a big tgz containing all
>    instruction corresponding to a specific version of ocaml.
>    but you may have your reasons.

CVS is a good tool to get the current development version, i.e. for the
unstable branch (when it exists). For the casual user, it is too random
which version is the current one. There are further disadvantages, e.g.
you cannot use CVS behind firewalls (at least like firewalls that are
typically used in company LANs).

On the other hand, a big tgz has the disadvantage that you cannot "pin"
certain versions of libraries, so that they are excluded from updates.

The current solution wants to be a compromise that works for everybody.
That the checks are so slow is caused by bmake calls that find out the
version on the disk; this can be improved, e.g. by comparing the $Id$
tags once they are in place.

By the way, I am not using CVS to manage the sources but subversion.
There are several reasons: (1) I want to check it out, (2) it has
features that can be very helpful to track foreign sources, and (3) it
works even over HTTP.

>  - what about windows? Do you think it is reasonnable to have a binary
>    distribution of godi with all the necessary commands (not depending
>    on cygwin)? Or a distribution on top of cygwin.
>    Not depending on cygwin would be a big plus for occasional users.

For a binary distribution we basically need the package tools, and some
scripts around them. I do not know whether there are Windows ports. Of
course, these tools are typical Unix programs, i.e. lots of pipes,
forks, etc., so that a MinGW port would be some work (but certainly
doable).

The scripts around these tools could be written in O'Caml itself, as we
do not have the bootstrap problem for a binary distribution. (As a last
resort, we could also rewrite the package tools in O'Caml, which is not
too hard.)

Am Sam, 2003-08-02 um 11.52 schrieb Jacques Garrigue: 
> Some more considerations on my experience.
> 
> > Next, building godi-ocaml and godi-ocaml-labltk. godi-ocaml went fine,
> > but godi-ocaml-labltk failed, because it needs some configuration
> > options (I see no way to pass them). Since I'm used to BSD packages, I
> > go to the godi-ocaml-labltk/work directory, and reconfigure by hand.
> 
> I realize now that this configuration problem is going to be very
> complicated. BSD packages are OS-oriented: they assume a closed world,
> where everything is controlled by the packaging system. So you don't
> need to tell them where something is on the system, they already know
> it.
> 
> With godi, the situation is different. For instance, tcl/tk headers
> may be in many places, maybe even several versions of them, and the
> user should be able to indicate where to find them. Same thing for
> camlimages, lablgl, lablgtk, etc...
> My feeling is that there has to be a way to give this information
> by hand the first time you install a package, and these parameters
> would be reused in following installations. When the package is
> installed as a dependency, this may require some interaction from the
> user.

In the current version of GODI, the godi.conf file contains these
configuration options. Of course, this is a non-interactive solution,
but I have added now hints that are printed on the screen just before
the build starts (and the user must confirm). So the user is now
reminded that there are such options, and where they can be found.

In the future, I can imagine that we have a labltk program that assists
the user in configuring the system. This GUI would be the better
solution for "camlimages, lablgl, lablgtk, etc...", but of course not
for labltk itself.

I see only one way for labltk: implanting more knowledge about the
various operating systems, and more intelligence to find even unusual
locations for tcl/tk.

There is not only the question of configuration options to find external
installations, but also the question which libraries one should better
include in GODI. Currently, I have only included GDBM (because an ndbm
implementation is necessary for a full O'Caml installation, and I wanted
to have something predictable), and PCRE (because PCRE4 is not yet
widely available, but the O'Caml bindings require it). Of course, the
question is where to draw the line. If we had a GUI for GODI, it could
even be justified to include tcl/tk if the user wishes so.

> Also, the possibility of finishing the work by hand must be left,
> otherwise recovering from simple configurations bugs can become
> unwieldly.

This is also necessary for the developers. Currently, the whole make
infrastructure works like NetBSD's, and I am not going to change this.

> I'm afraid this is just one example of mismatch between an
> OS-oriented packager and a language-oriented multi-platform packager.

I hope there will not be more. I have already resolved several other
mismatches: 

- The original scripts require root privileges for installation. Of course,
  we do not want that.

- The original package tools store the version conditions like
  "libraryXY>=3.5" in the binary packages. I have changed that to
  "libraryXY=3.5" because of OCaml's strict interface checksums.

- Some of the PLIST issues are resolved. There is a special
  PLIST.godi format that recognizes additional directives, so you
  can package whole directories, with filename globbing, and under
  a number of O'Caml-specific conditions.

- There can be several GODI installations on the same system (no
  conflict because there is only one /etc/mk.conf as in NetBSD)

Up to now, it was quite easy to change the build and packaging scripts
as needed (I guess there would be more trouble if I had used a closed
system like rpm).

> Another one is the use of makefiles internally and in packages. While
> makefiles are not intrinsically bad, they have one big default: they
> depend heavily on the behaviour of external commands on the system. If
> you have only platform this is not a problem: you just have to check
> once that this works, but if you must handle multiple platforms, it is
> very hard to be sure that the Makefile is portable.
> I don't know how CPAN handles that, but this is going to be painful.
> Using an ocaml only tool like ocamake may be an interesting option, at
> least for simple packages.

It is painful. I have already run into problems, e.g. /bin/sh on Solaris
is not even POSIX-compliant, and it starts subshells under much more
conditions than a standard shell. Fortunately, most of the tools are not
that problematic; an mkdir is an mkdir. And most of the O'Caml sources
come with Makefiles that have the same portability problems; in the long
run, I guess most of the bugs will occur in the upstream Makefiles.

(There is already such a problem in godi-wlex. The "patch" utility of
Solaris does not grok the wlex patch.)

In my opinion, the portability problem can only be _finally_ solved if
the upstream Makefiles are replaced by something better. Perl has its
Makefile.PL, which is a Perl script that writes the system-dependent
Makefile. However, Perl is not compiled, and the possible cases are
simpler to manage.

> Just some thoughts.
> I certainly believe that godi is a big step in the right direction.
> 
> Jacques Garrigue
> 
> P.S. A small detail, but would it be hard to replace godi_ftp by
> fetch? On my system godi_ftp is 351K whereas fetch is only 18K. I
> suppose this is also reflected by the size of the sources.

You can set FETCH_CMD in godi.conf; I don't know if the options are
compatible enough.

> I wonder also if there is a packaging system based on gmake rather
> than bmake. It feels a bit strange to install bmake only for internal
> purposes.

I consider bmake as just another scripting language. Of course, we could
port the whole bsd.pkg.mk to gmake, but does this make sense? It has
more than 4600 lines, and it makes heavy use of the BSD extensions.

If we are going to switch to another tool, it will be more attractive to
write a small make utility in O'Caml that can be scripted in O'Caml.
There is very ugly code in bsd.pkg.mk that would have a trivial and
elegant expression in O'Caml.

Gerd
-- 
------------------------------------------------------------
Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany 
gerd@gerd-stolpmann.de          http://www.gerd-stolpmann.de
------------------------------------------------------------

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Re: GODI available for download

[Gerd Stolpmann]

Am Son, 2003-08-03 um 17.26 schrieb David Brown:
> On Sat, Aug 02, 2003 at 01:54:34PM +0200, Alain wrote:
> 
> > Have a try on MacOS X, quickly interrupted because the native
> > filesystem (HFS+) is not "a case-sensitive filesystem".
> > 
> > I will retry soon with on a computer with an UFS partition.
> > But this is annoying, most Darwin's users use HFS+.
> 
> I agree with this.  Requiring a case-sensitive filesystem will be a show
> stopper for an increasing number of systems.

I don't know whether this number increases or decreases, I have just
copied this check from the original NetBSD script. I also do not know
whether a case-sensitive filesystem is strictly required, and in which
problem you will run with other systems. You can try it by passing the
option --ignore-case-check to the bootstrap script, this turns the check
off.

> One question is, does GODI really require that?  HFS preserves the case
> of filenames, and usually you can't tell it is case insensitive.  Only
> if you try to create two filenames that differ only in case do you
> notice the problem.

I can imagine that certain checks do not work properly, so maybe one or
the other error condition is not detected, or maybe filename
manipulations do not work always.

Gerd
-- 
------------------------------------------------------------
Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany 
gerd@gerd-stolpmann.de          http://www.gerd-stolpmann.de
------------------------------------------------------------

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Re: GODI available for download

[David Brown]

On Mon, Aug 04, 2003 at 02:49:32AM +0200, Gerd Stolpmann wrote:

> > One question is, does GODI really require that?  HFS preserves the case
> > of filenames, and usually you can't tell it is case insensitive.  Only
> > if you try to create two filenames that differ only in case do you
> > notice the problem.
> 
> I can imagine that certain checks do not work properly, so maybe one or
> the other error condition is not detected, or maybe filename
> manipulations do not work always.

In all of the programs I have worked with on case-preserving
case-insensitive, only a few have ever failed.

  - Old versions of perl generated both a 'makefile' and a 'Makefile'.
    This has long been corrected.
  - OpenCM creates directories 'A', and 'a'.  It actually works, since
    the filenames probably won't collide, but the resultant tree can't
    be moved to a case-sensitive filesystem.

I have heard of one other, and it was fairly trivial to fix.

I'm guessing that there is nothing in GODI that cares.

Dave

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] GODI available for download

[Fred Yankowski]

On Sun, Aug 03, 2003 at 07:11:12PM +0200, Sven Luther wrote:
> Notice that i build the ocaml debian packages with :
> 
>                 -tklibs "-L/usr/lib -ltk8.3 -ltcl8.3"

OK, but what's your point?  I'm guessing that the above options mean
that the ocaml exectables built in your debian packages are linked
with the tcl and tk libraries.  Does that have any bearing on my
experiment with Gerd's proposed distribution tools?

Perhaps you're informing me that ocaml with tkinter is already
available in your Debian packages.  If so -- so noted.  I do prefer to
use Debian packages when they have what I need.  One trouble is that I
tend to be a late-adopter of new Debian releases, and Debian releases
are notoriously slow to pick up current upstream package versions as
it is; so I have to build more from source distributions than I would
like.  I wish it were easier to install the latest Debian packages in
older releases (a problem not particular to Ocaml).

-- 
Fred Yankowski      fred@ontosys.com           tel: +1.630.879.1312
OntoSys, Inc	    PGP keyID: 7B449345        fax: +1.630.879.1370
www.ontosys.com     38W242 Deerpath Rd, Batavia, IL 60510-9461, USA

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] GODI available for download

[Sven Luther]

On Mon, Aug 04, 2003 at 04:36:55PM -0500, Fred Yankowski wrote:
> On Sun, Aug 03, 2003 at 07:11:12PM +0200, Sven Luther wrote:
> > Notice that i build the ocaml debian packages with :
> > 
> >                 -tklibs "-L/usr/lib -ltk8.3 -ltcl8.3"
> 
> OK, but what's your point?  I'm guessing that the above options mean
> that the ocaml exectables built in your debian packages are linked
> with the tcl and tk libraries.  Does that have any bearing on my
> experiment with Gerd's proposed distribution tools?

Just to say that in debian, the tcl/tk library are accessed not with
plain -ltk -ltcl, but that they have the version appended in order to
have multiple versions of tcl/tk. So maybe your troubles building Gerd's
stuff may be related to that, but then maybe not.

> Perhaps you're informing me that ocaml with tkinter is already

Err, i don't know about tkinter. the debian packages are mostly plain
upstream sources, with some collection of added fixes, mostly taken out
of CVS.

> available in your Debian packages.  If so -- so noted.  I do prefer to
> use Debian packages when they have what I need.  One trouble is that I
> tend to be a late-adopter of new Debian releases, and Debian releases
> are notoriously slow to pick up current upstream package versions as
> it is; so I have to build more from source distributions than I would
> like.  I wish it were easier to install the latest Debian packages in
> older releases (a problem not particular to Ocaml).

You are aware of Stefano's backport repository, which was reptedly
announced here, are you not ?

Friendly,

Sven Luther

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] GODI available for download

[prashanth]

On Sat, Aug 02, 2003 at 06:52:29PM +0900, Jacques Garrigue wrote:

> I wonder also if there is a packaging system based on gmake rather
> than bmake. It feels a bit strange to install bmake only for internal
> purposes.

There is GAR:

http://lnx-bbc.org/garchitecture.html

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners