[Caml-list] The CDK looks marvelous... but...

[Caml-list] The CDK looks marvelous... but...

[Dave Mason]

Hi,

First off, the CDK is looking good.  There is a bunch of really cool
stuff happening there.  But it needs some cleanup (which I don't think
would be all that difficult to do, for someone familiar with it).

Let me give you the scenario of my last couple of hours.  (I may omit
some of the frustrations, but you'll get the sense of it.  If you get
bored, skip to after point 9.)

1) I want to use the stuff in cdk/network, so I check out that
   subdirectory.  I try a make.  It dies in an ugly way, indirectly
   saying that it needs the config directory.

2) I go up a level and say `cvs update -d config', then go there and
   run configure.  But it's trying to put something into camlimages,
   which doesn't exist, so it dies again.  I go get camlimages, and
   some other directory and eventually everything is cool, so I go
   back to network and try make again.  It wants cdk_config.  It's not
   in the config directory - too obvious.

3) I go and poke around in the browsable CVS tree.  I find it in
   tools.  So I go up a level again and say `cvs update -d tools',
   then go there and say make.  It wants OCAML_SRC/boot/ocamlyacc.
   But I don't have the ocaml source installed, I installed from the
   RPM.  I track down that it's in cdk/Makefile.generic in the
   dependency for TMPSOURCES, so I edit that line, and do a make in
   the tools directory.  Everything is cool again, except it tries to
   copy the cdk_config binary into cdk/bin, but I don't have that
   directory, so I mkdir it, and run make again.... it doesn't copy
   the file... and it wouldn't matter anyway because the cdk/bin
   directory isn't in my PATH.  So I fix it, go back to network and
   try again.  No-go - it wants unix2.. so I get it.

4) Make doesn't work in unix2...

5) Somewhere there were compiles that needed .cmi files, but there was
   no dependency in the Makefile, so I compiled them all by hand.
   (Unix2 is one of these).

6) The makefiles use features of tools that presumably exist in the
   CVS version of the compiler, but not in the current release version
   (like -subdir for ocamlc.opt and ocamldep).

7) Many of the directories in CDK don't even have README files to give
   a hint what they might be useful for.

8) I give up and download the whole cdk.  I go to the cdk directory
   and type make.  No go... tools wants to install ocaml from some tar
   file!  (I figure out that ``make .depend byte opt'' will do close
   to what I want, without that stage.)

9) All of this pain was on Linux, for heaven's sake!  God forbid I was
   trying it on Windows... (not that I'm a fan... but in this case
   being able to build on Windows was one of the reasons I was trying
   to use CDK in the first place)

Sigh.

There is *so* much potential here.... we're getting close to a
critical mass of code.  But I can't even *try* to use a particular
piece of the CDK.  It's NOT unreasonable for there to be some
dependencies between parts of the CDK, but it *is* unreasonable for me
to have to (a) (re-)install ocaml from the CVS version; (b) install
all of the CDK, or (c) have the build process die in ugly ways at
every turn if I try to do it incrementally.

I have some specific suggestions for whoever is overall responsible
for the CDK.

1) Let's assume gmake.  I assume it's available for Windows.

2) Have the config directory not try to modify files outside itself.
   Put cdk_config in the config directory.

3) At the beginning of every makefile put a line like:

       DEPENDS_ON=unit1 unit2 ...

   Follow this with an include of Makefile code that loops through
   DEPENDS_ON and checks for a file called ../unit1/.built,
   ../unit2/.built, etc. and gives a reasonable error for anything
   missing.  (It could even offer to load it if there is a ../CVS
   directory - it could `cd ..;cvs update -d unit1;cd unit1;make').

4) That makefile should have `all' depend on `.built', and the current
   dependencies for `all' should instead depend on .built, and the
   recipe for .built should touch the file.  (Or add a recipe for `all'
   that touches it, and use `all' instead of `.built' in suggestion 3.)

5) Make sure everything possible builds with the current ocaml.  There
   may be a few parts that don't but they better not be in many
   dependency trees.

6) Periodically, try removing all the cdk subdirectories except for
   config and the one under test and try a make.  Minimize the
   gratuitous dependencies.

If nobody else is responsible for this and/or willing to do it, I
wouldn't mind working on it.  This isn't quite the PTAN model of
down-loadable components, but it would be a step in that direction.

../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] The CDK looks marvelous... but...

[Dave Mason]

Oops, got the wrong acronym.  Should have been CPAN - the Perl
repository.

../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] The CDK looks marvelous... but...

[Alan Schmitt]

Hi,

When we started writing the cdk, our first goal was to provide a big
bunch of useful libraries and integrated makefiles, so that one could
get them all from one place, and compile them all with one 'make'.
Unfortunately, I'm afraid our approach does not work, for several
reasons. First of all, many of the libraries included are developed by
other persons, and we need to manually take their changes into the
libraries included, which is a pain. Another problem is the one you
describe: we provide a bundle that is not easy to cut in pieces.

So I really think the packaging issues should be tackled differently, in
a distributed way (it needs to be easy for developpers to integrate in
their project). Packaging should take care of a few things:
- make libraries easy to find
- make libraries easy to compile and use (well known library repository,
  detection of installed libraries)
- make recompiling easy (in my dream world, when I recompile ocaml, I'd
  like to be able to recompile all the libraries and apps that depend on
  it with one command).

Best,

Alan

-- 
The hacker: someone who figured things out and made something cool happen.
-------------------
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] The CDK looks marvelous... but...

[Alexander V. Voinov]

Hi Alan,

Alan Schmitt wrote:
> - make recompiling easy (in my dream world, when I recompile ocaml, I'd
>   like to be able to recompile all the libraries and apps that depend on
>   it with one command).

Again, _why_ do you want to recompile ocaml? Both me and Dave and Berke
emphasized that a key to the adoption of this intergrated kit is that it
compiles with the stock binary version of ocaml for the respective
platform. I can't understand the reason to have a special version of
ocaml for CDK.

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] The CDK looks marvelous... but...

[Alan Schmitt]

* Alexander V. Voinov (avv@quasar.ipa.nw.ru) wrote:
> Hi Alan,
> 
> Alan Schmitt wrote:
> > - make recompiling easy (in my dream world, when I recompile ocaml, I'd
> >   like to be able to recompile all the libraries and apps that depend on
> >   it with one command).
> 
> Again, _why_ do you want to recompile ocaml? Both me and Dave and Berke
> emphasized that a key to the adoption of this intergrated kit is that it
> compiles with the stock binary version of ocaml for the respective
> platform. I can't understand the reason to have a special version of
> ocaml for CDK.

What I meant was "when a new version of ocaml comes out, or when I want
to recompile ocaml from cvs, ...".

At the moment, each time I install a new version of ocaml, I need to
recompile all librairies that depend on the standard library if it has
changed a bit. Same thing if I get a new version of, say, lablgtk, with
all my gtk apps.

So I don't mean to have a special version of ocaml with any packaging
system, just to be able to handle dependencies among librairies.

Best,

Alan

-- 
The hacker: someone who figured things out and made something cool happen.
-------------------
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] The CDK looks marvelous... but...

[Markus Mottl]

On Fri, 05 Jul 2002, Alan Schmitt wrote:
> Unfortunately, I'm afraid our approach does not work, for several
> reasons. First of all, many of the libraries included are developed by
> other persons, and we need to manually take their changes into the
> libraries included, which is a pain. Another problem is the one you
> describe: we provide a bundle that is not easy to cut in pieces.

Which indicates again, how badly we need packaging standards for OCaml...

Regards,
Markus Mottl

-- 
Markus Mottl                                             markus@oefai.at
Austrian Research Institute
for Artificial Intelligence                  http://www.oefai.at/~markus
-------------------
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] The CDK looks marvelous... but...

[Xavier Leroy]

> Which indicates again, how badly we need packaging standards for OCaml...

I couldn't agree more.  But that's no small undertaking :-)

- Xavier Leroy
-------------------
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