Re: debian packaging of findlib
On Wed, Feb 21, 2001 at 10:07:25PM +0100, Gerd Stolpmann wrote:
> 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.
thought so, ...
> >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.
Yes, that would be very nice, ...
> >> 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
Yes, this is not clear what is the best way of doing this.
I guess the addition of +package-name would be a big help for people putting
their stuff in separate subdirs.
> - 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
Is this not automatic ?
> - 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.
Ok, ...
> >> 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.
And then findlib will some day be an official part of the upstream ocaml
packages :)))
> >> 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
Ok, ...
so we just write the META file per package, and use the ocamlfind-fake file to
install.
Err, ...
how will we specify the installdir in the ocamlfind-fake script ?
maybe we shall use :
ocamlfind-fake $(DESTDIR) ...
or something such ...
and thus we would set $(OCAMLFIND) to ocamlfind-fake $(DESTDIR).
> >> >> - 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.
It was just a tought anyway, ... the ocamlfind-fake thingy would be easier to
do i guess and would do the job we need.
Friendly,
Sven Luther
Reply to: