Hi Dan, On May 7, 2007, at 2:43 AM, Daniel Macks wrote:
> On Sun, May 06, 2007 at 08:39:53PM -0700, David R. Morrison wrote: >> On May 6, 2007, at 9:09 AM, Remi Mommsen wrote: >>> >>> I have a package (root5) which builds many shlibs and has different >>> variants. Depending on the variant, some shlibs are built or not > [...] >>> How do I handle this situation? >> >> 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? > > A further question is whether the dylib that are exist in all are > *the same* in all. AFAIK, the dylib are the same. However, there are configuration files mapping the dependencies btw libraries for the run-time C++ interpreter. These files only contain the libraries which are actually built. Thus, one would need to hack these configuration files depending on the add-on packages. > That's important for drm's Idea #2: > >> 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. > > If a dylib file that exists in multiple variants is not the same in > all of them, then a core package plus varianted add-ons won't > work. OTOH, if the core dylib are identical in all variants, then one > probably could hack the build to avoid building those core again in > the variant add-on packages. Quick example would be the python > bindings for gnome-menus: the shared libraries and python bindings are > all part of the same source tarball and is designed so a single > "./configure && make" builds it all, so we first build the libs with > python disabled, and then, in a separate package, build *just* the > python bindings for a given python variant by hacking to point to the > installed lib instead of the one in the build dir. I guess this would be possible with a lot of hacking and testing (possibly repeating each time when a new version is released). In addition, I would need to maintain 8 different info files instead of one. I hope we can find a better solution as this solution is (too) time consuming IMHO. Remi -- Computers are like air-conditioners, they stop working properly when you open Windows. (Anonymous) ********************************************************************* 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
