Hi David,
On May 6, 2007, at 10:39 PM, David R. Morrison wrote:
>
> On May 6, 2007, at 9:09 AM, Remi Mommsen wrote:
>
>> Hi,
>>
>> I have a package (root5) which builds many shlibs and has different
>> variants. Depending on the variant, some shlibs are built or not. So
>> far, I just listed all possibly built libraries in the Shlibs field.
>> The latest (cvs head) version of fink complains now about the missing
>> libraries listed in the shlibs field:
>> Error: Shlibs field specifies /sw/lib/root/libEGPythia6.5.dylib, but
>> it does not exist!
>> Error: Shlibs field specifies /sw/lib/root/libG4root.5.dylib, but it
>> does not exist!
>> Error: Shlibs field specifies /sw/lib/root/libHbook.5.dylib, but it
>> does not exist!
>>
>> How do I handle this situation?
>>
>> TIA,
>> Remi
>
> Hi Remi.
>
> The basic problem here is that we want a reliable mapping between
> "install-name and compatibility version of a dynamic library" and
> "what fink package installs it".
>
> I haven't looked at the package to see what your variant structure
> is, but presumably there is some core collection of dylib files
> which are built for all variants, and then some extra ones which
> only occur in some variants?
Correct.
> I see two possible strategies for handling this, but I'm willing to
> be convinced that there are others I haven't thought of.
>
> 1) The contents of your Shlibs field has to depend on the variant.
> This is unpleasant, because we hadn't anticipated it and fink's
> variant code can't handle this smoothly. It would require
> separate .info files for the various variants. (It also has the
> unfortunate property that there are several different packages
> which could be used to provide a given dylib, so these should all
> conflict/replace each other, which gets messy where shared library
> packages are involved.)
>
> 2) A basic package would provide the dylibs that are in common for
> all variants, and then the variant packages would build other
> splitoffs with other dylibs in them (as needed). The disadvantage
> of this is that people may have to compile things twice. You would
> probably also need separate .info files.
Having separate info files would be quite messy. Currently, there are
8 combinations built from one info file. I don't want to build all
extensions by default (and split them into split-offs) as these
extensions pull in other huge packages which only a few people
actually need.
> Can anybody think of another strategy?
Would it be possible to extend the variant syntax to allow it also in
the shlibs field, i.e. one could put something like
Shlibs: <<
%p/lib/root/libRooFit.5.dylib 5.0.0 %n
(>=5.02.00-1)
(%type_pkg[-qt]) %p/lib/root/libQtRoot.5.dylib 5.0.0 %n
(>=5.15.04-2)
<<
where the first library is available in all variants, and the second
only in the '-qt' variants?
Remi
--
… there are known knowns; there are things we know we know. We also
know there are known unknowns; that is to say we know there are some
things we do not know. But there are also unknown unknowns — the ones
we don’t know we don’t know.
Donald Rumsfeld
*********************************************************************
Remigius K. Mommsen e-mail: [EMAIL PROTECTED]
University of Manchester URL: http://cern.ch/mommsen
Fermilab, MS 357 voice: ++1 (630) 840-8321
P.O. Box 500 fax: ++1 (630) 840-2649
Batavia, Il 60510, US home: ++1 (630) 236-0932
*********************************************************************
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel
