[Caml-list] autocompile

[Caml-list] autocompile

[skaller]

I have this annoying problem sometimes:

The files /usr/local/lib/ocaml/pervasives.cmi
and /usr/local/lib/ocaml/lablgtk2/gdk.cmi make inconsistent assumptions
over interface Pervasives

Of course the problem is that I installed a new version
of Ocaml from a CVS build, but didn't rebuild lablgtk2.

Obviously, just saying 'reinstall lablgtk2' isn't
an answer: it's in the standard distribution location,
the installation process should handle that automatically.

I was thinking: why not build the dependencies
into the compiled files, so if a compiled file is
out of date it can be rebuilt automatically?
Perhaps a switch would enable the autorebuild:
I wouldn't suggest doing it by default.

One would need to put the files depended on,
including the path to the compiler, along with
timestamps, and also put the command line used
for the compilation (possibly with absolute pathnames
replacing the ones actually typed in).

Also, when installing Ocaml, it would be interesting
to have a make target that rebuild any installed libraries,
since a user recompilation of a system library would
fail due to lack of permissions.

Does findlib already do this kind of thing?

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
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] autocompile

[Xavier Leroy]

> I have this annoying problem sometimes:
> 
> The files /usr/local/lib/ocaml/pervasives.cmi
> and /usr/local/lib/ocaml/lablgtk2/gdk.cmi make inconsistent assumptions
> over interface Pervasives
>
> Of course the problem is that I installed a new version
> of Ocaml from a CVS build, but didn't rebuild lablgtk2.

Rejoice that this error is caught rather than crashing randomly
later (as can happen with library upgrades in C or C++).

> Obviously, just saying 'reinstall lablgtk2' isn't
> an answer: it's in the standard distribution location,
> the installation process should handle that automatically.

Sorry for nit-picking, but lablgtk2 is not part of the core OCaml
distribution, so there is no way installing the latter can
recompile the former.

But more generally you've just hit the reason why package management is
needed for OCaml.  Transitively rebuild and reinstall packages that
depend on an updated package is exactly the job of a package manager.

> I was thinking: why not build the dependencies
> into the compiled files, so if a compiled file is
> out of date it can be rebuilt automatically?

I don't think this is sufficient.  What if the corresponding source
file was erased after installation?  What if that source file is
generated?  You can need to download sources again, and do a full
rebuild of the package.  That's what a package manager can automate.

> Does findlib already do this kind of thing?

I doubt it.  This sounds more like the job of GODI (Gerd Stolpmann's
experimental package manager).

- 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

Re: [Caml-list] autocompile

[skaller]

On Tue, 2004-04-13 at 02:38, Xavier Leroy wrote:
> > I have this annoying problem sometimes:
> > 
> > The files /usr/local/lib/ocaml/pervasives.cmi
> > and /usr/local/lib/ocaml/lablgtk2/gdk.cmi make inconsistent assumptions
> > over interface Pervasives
> >
> > Of course the problem is that I installed a new version
> > of Ocaml from a CVS build, but didn't rebuild lablgtk2.
> 
> Rejoice that this error is caught rather than crashing randomly
> later (as can happen with library upgrades in C or C++).

I do: thanks!

> > Obviously, just saying 'reinstall lablgtk2' isn't
> > an answer: it's in the standard distribution location,
> > the installation process should handle that automatically.
> 
> Sorry for nit-picking, but lablgtk2 is not part of the core OCaml
> distribution, so there is no way installing the latter can
> recompile the former.

I know it isn't in the core, but it -- and many other packages --
do install themselves in the standard location.


> But more generally you've just hit the reason why package management is
> needed for OCaml.  Transitively rebuild and reinstall packages that
> depend on an updated package is exactly the job of a package manager.

I was hoping that there might be a sensible intermediate level of
support which worked 'automagically' for simple Ocaml-only 
algorithms and data structures libraries, which typically
don't require any special build procedures.

> > I was thinking: why not build the dependencies
> > into the compiled files, so if a compiled file is
> > out of date it can be rebuilt automatically?
> 
> I don't think this is sufficient.  

I agree, in general it isn't. 

However, consider turning this issue inside out.
What if you *specify* that it is sufficient?

For a wide class of libraries, it is enough.
So if the Ocaml standard library directory
is simply *deemed* to contain only such libraries,
the rebuilding can be automated.

This may mean, for example, that the rebuilding
would fail for some libraries, but the conclusion
should be that the library should not be put
in the standard location.

For example one may ask whether PCRE should go
in the standard location, since it may need to
be rebuilt if the underlying C libraries is rebuilt:
perhaps the build 'scans' the C headers looking
to see what flags are available and adds them
to the Ocaml source before compilation.

That kind of build process would not fit with the
simple autorebuild model .. so don't put PCRE in the
standard location.

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



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