Browse thread
findlib help: how to specify dependencies against non-findlib packages ?
-
Guillaume Rousse
-
Gerd Stolpmann
-
Guillaume Rousse
-
Gerd Stolpmann
- Guillaume Rousse
-
Gerd Stolpmann
-
Guillaume Rousse
-
Gerd Stolpmann
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| From: | Guillaume Rousse <Guillaume.Rousse@i...> |
| Subject: | Re: [Caml-list] findlib help: how to specify dependencies against non-findlib packages ? |
Gerd Stolpmann wrote: > Am Montag, den 02.10.2006, 15:30 +0200 schrieb Guillaume Rousse: >> Gerd Stolpmann wrote: >>> Am Montag, den 02.10.2006, 11:24 +0200 schrieb Guillaume Rousse: >>>> I'm trying to add findlibsupport for camlimages. >>>> >>>> It has a dependency on graphics, which is easily handled by adding a >>>> require variable in META file, as graphics provides findlib support. >>>> >>>> However, camlimages can also get compiled with either lablgtk or >>>> lablgtk2 support (not both of them, as they have conflicting symbols), >>>> but none of those packages have findlib support. It means I can't >>>> ressort to smart dependency computation. I may eventually use the >>>> linkopts variable to add explicit linking flags (such as -I >>>> place/to/lablgtk2 lablgtk.cma), but this seem to be only possible for >>>> linking, not for compiling, whereas I also need to pass -I >>>> place/to/lablgtk2 option during compilation. >>>> >>>> So, is this just not possible at all ? >>> Of course, it is possible: ... > >> I'm speaking of incoming camlimages 3.0.0 release, not of camlimages >> packages in some distribution. I can't interfere with already existing >> lablgtk/lablgtk2 installation, unless there is a way to do it privately >> to camlimages itself. > > Sorry, I misunderstood you. > > In general, findlib assumes that prerequisite packages already have > findlib support. There is no clean built-in way to cope with the > situation, simply because if several packages depended on lablgtk and > fixed the missing META file in their own way it would not be possible to > resolve dependencies cleanly anymore. > > What you can still do is to define a subpackage > camlimages.lablgtk_substitute (syntax see below) and to depend on this > subpackage if you see that lablgtk is installed without META file > (otherwise just depend on lablgtk). This subpackage contains the > substitute for the missing META file. However, as said this is no really > clean solution but probably the best you can do. The cleaner solution would be to push META support to lablgtk maintainer directly. Does anyone already tried ? > You can define subpackages in META files with this syntax: > > <this is the META file for camlimages> > package "lablgtk_substitute" ( > <META directives> > ) > > The subpackage can then be referred to as camlimages.lablgtk_substitute. > For a complete example see the camlp4 META file coming with findlib. > > As lablgtk is usually installed below the standard library directory, > you can refer to this directory using > > directory = "+lablgtk" > > Hope this helps. That was exactly what I needed, thanks. I just have to handle the conditional META support in lablgtk now. > You might also be interested in how GODI generates a > META file for the current version of camlimages (it assumes, however, > that lablgtk is installed _with_ META file): > > https://gps.dynxs.de/svn/godi-build/trunk/godi/godi-camlimages/create-META Well, I hope this won't be necessary anymore with next release, if I understood correctly how to generate it myself. You're welcome to checkout current CVS version of camlimages to check. -- Guillaume Rousse Projet Estime, INRIA Domaine de Voluceau Rocquencourt - B.P. 105 78153 Le Chesnay Cedex - France