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?

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.

Can anybody think of another strategy?

   -- Dave



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

Reply via email to