Re: debian packaging of findlib
On Tue, 20 Feb 2001, Sven LUTHER wrote:
>On Mon, Feb 19, 2001 at 08:21:58PM +0100, Gerd Stolpmann wrote:
>> "ocamlfind install" is also to ensure that layout; actually it is only a cp
>> into the right directory, not more.
>
>you don't even check that the META file is there, or copy it to the right dir
>?
No, I don't check it. (I think it's a bug not to do so.)
>BTW, i have seen that in the packages you do :
>
>$(OCAMLFIND) install stuff ...
>
>what would have been nice, is that ocamlfind would have been compatible with
>install at command line level, this way, you just set the OCAMLFIND variable
>to empty, and install is used, ... mmm, not possible, you don't have a target
>directory, isn't it ?
The target directory is implicit.
>then what about :
>
>$(OCAMLFIND) install stuff to install ... $(DESTDIR)
>
>and putting DESTDIR to empty in the findlib install, and to the installdir in
>the non-findlib install ?
I can write a shell script "ocamlfind-fake" that emulates ocamlfind, and you can
set OCAMLFIND=ocamlfind-fake, and installation works without ocamlfind. That's
very easy and avoids any command-line magic.
>> Maybe there are some heuristics to generate it. For example, you can look if
>> there is only one .cma/.cmxa archive, and put its name into the archive line.
>> For more than one archive it becomes difficult; maybe you can use them only
>> alternatively, or in certain combinations. There is no generic way to obtain or
>> even to guess that. - Perhaps you can extract the prerequisites from the debian
>
>No generic way to obtain it ? do you mean just listing all included .cma and
>.cmxa is not enough ?
>
>> package infos. However, debian packages (as far as I understand) only include
>> build-time and not developer-usage-time dependencies. This can make a
>
>no, the debian packages include build-dependencies, for building the package,
>but this is something new.
>
>The classic dependencies, are useage time one (a package that is not useable
>when all dependencies are met is broken).
>
>example is :
>
>libgtk1.2-dev depends on : libgtk1.2, libglib1.2, libglib1.2-dev.
>
>there is also other more advanced kind of stuff, like suggests, provide and
>conflicts.
>
>The first onelist a list of packages that are not absolutely needed, but would
>be nice to have (like the doc packages). provide is when a package provides
>the functionality of some other package or a virtual package. conflicts is
>when you have cannot install this package together with some other.
>
>> difference, because it is possible that a package A needs another package B at
>> build-time only to extract the necessary modules and to put them into its own
>
>Yes, this is build-dependencies, but then it is not nice stuff, since then you
>end having the same thing installed 2 times, if you have both A dn B installed
>at the same time. But then, i guess until ocaml supports dynamic links, it
>will not be possible to do it differently.
>
>> archive. When the package is used to build some software C it is sufficient to
>> link with the library found in A (even worse, trying to link with B would cause
>> link conflicts).
>
>Yes, because you are including the same module 2 time, i undertsand that. This
>would not be needed if you had dynamic links, and/or are able to add the
>library name to the path of the modules.
>
>> I do not really know if a heuristics is possible that has some success. Perhaps
>> it is simpler to have a quick look at the sources and manually write these five
>> lines.
>
>I see, mmm, are there lot of packages which do this kind of dirty trick ?
I had a look at several (non-INRIA) ocaml libraries. Most of them don't do such
tricks, but:
- Some don't have even Makefiles (mostly one-module libraries)
- Some don't archive the object files
- Some packages put the resulting archive into the topmost build dir, some
into a subdirectory
- Some tarballs consist of several libraries that should be separated
(e.g. efuns)
- Some libraries add the (ocaml 3.00-style) linking options to the resulting
archive, some not
- Some applications can also be packaged as libraries, but the Makefile only
generates an executable
So there is always some work with the last step of building packages (making
the result more uniform). The specifications contained in META describe the
result of the last step: the name of the archive, whether linking options are
needed etc. So I would consider the necessary cleanup of the last step and
writing the five lines META as one task.
>> I have quite good experience with installing META in the same directory as the
>> other files. First, it is clear that the META file found in some directory
>> describes the findlib package in the same directory. Second, the META file is
>> used as a tag that makes the directory a package directory (useful when
>> searching for package directories).
>
>Ok, i see, but in the long term aim of all packages supporting findlib, and
>that all packages register themself to findlib during installation, this is
>not needed.
>
>> directory. It is even possible to have both approaches at the same time. If you
>> really want it, I can implement it; this would make only a few lines of code.
>
>nice would be to have the centralized approach for the official debian
>packages, and the META in directory approach in the user added modules in
>/usr/local or $HOME.
>
>But that said, i am only stating what would be very nice to have in a almost
>perfect debian installation of findlib. i don't want you to devote time to it
>if you don't feel like it, or something such, please don't take it bad ...
I think if there is a good argument, I should do it. And I think that there is
at least one good argument: I do not want to prescribe users how to install the
libraries in detail. If some have other ideas than I, I should allow that these
other ideas are optionally enabled.
>> Of course, there are some more INRIA packages not yet handled; but this is
>> simply because I did not use them until now.
>
>Do you think that eventually every package would be handled by findlib ?
I think so.
>> instructions into an algorithm. But there is no _generic_ solution for
>> arbitrary packages because I would need some intelligent algorithm
>> understanding the English text.
>
>I see ...
>
>So you don't generate them with ocamlfind ?
ocamlfind only installs already existing files. META files must either have
been written by hand, or be generated by a specific algorithm working exactly
for the package
>> >> - the installation method needs a way to specify an alternate target directory
>> >
>> >Yes, and ideally, a conventional install target, is it possible to
>> >'pre-process' the ocamlfind stuff, in a way similar to how the
>> >autmoake/autoconf stuff work ?
>> >
>> >You use it for out_of_cvs versions, but not in released packages.
>>
>> I can add such conventional install targets when I update the packages from
>> time to time.
>>
>> Preprocessor: You mean a mechanism that writes a Makefile maybe by using a tool
>> like findlib, and in the resulting Makefile there is no more findlib call?
>> I hoped to get around that... Maybe it's nice for you, but it destroys the
>> abstractions introduced by findlib.
>
>Err, when you use automake/autoconfig (i guess you are familiar with it) you
>have a Makefile.in or somethign such, which get's pre-prossesed to something
>that don't need these tools, the same goes with configure.in.
>
>I think in our case, this would be more difficult to handle, but that was my
>idea. You still keep the ocamlfind one around, or even you just reuse the same
>Makefile, just expanding (in a second target) he findlib specific stuff.
>
>Don't know if it is the best solution though.
The idea needs some more studies before I can say whether it would work or not,
and what are the advantages/disadvantages.
>> For some INRIA packages (camltk, labltk, camlp4) the generator exists:
>> findlib's configure script. I would recommend to simply run it, and to look at
>> the result, and to change manually the things that went wrong (e.g. wrong path).
>
>It is in the findlib package ?
Yes.
>> >I guess that if the whole debina-ocaml stuff supported findlib directly, maybe
>> >it would gain widder acceptance, which would be good ofr you.
>>
>> That would be fine.
>
>:)))
>
>Again, i hope you don't take all my 'exigences' badly, nor for more than what
>they are, ...
:)))
Gerd
--
----------------------------------------------------------------------------
Gerd Stolpmann Telefon: +49 6151 997705 (privat)
Viktoriastr. 100
64293 Darmstadt EMail: gerd@gerd-stolpmann.de
Germany
----------------------------------------------------------------------------
Reply to: