Ticket #216 (reopened enhancement)

Opened 10 months ago

Last modified 4 months ago

need a way to specify the foreign libraries a package depends on

Reported by: ross@soi.city.ac.uk Assigned to:
Priority: normal Milestone: _|_
Component: Cabal library Version: 1.2.3.0
Severity: major Keywords:
Cc: dons@galois.com Difficulty: normal
GHC Version: 6.8.2 Platform: Linux

Description

Package descriptions allow one to specify which Haskell libraries a package depends on, but foreign ones. Designing something that can be used with native package managers is complicated because many of them alter the upstream library names in unpredictable ways.

Change History

01/26/08 07:01:01 changed by duncan

Note that we already have some partial information, like extra-libraries:, includes:, pkgconfig-depends: and frameworks:.

02/11/08 16:48:57 changed by dons

  • cc set to dons@galois.com.

In addition, we can see the lack of checking for the existence of C libs breaking test builds on hackage, and breaking cabal-install downloads.

pcre-light is a good example: no way to test pcre.h is available, without resorting to autoconf.

One solution here might be to reuse/duplicate autoconf functionality to check if extra-libraries are available?

02/12/08 01:31:35 changed by duncan

See also #177, suggestion that we can at least check at configure time if all required C libs and header files can be found. Of course that does not relate them back to what packages those C libs belong to, but it'd give better error messages.

03/25/08 05:05:55 changed by guest

#177 is actually about checking for directories.

See also:

  • #15 and #159 - implement dependency analysis
  • #262 - check for required foreign libraries

03/25/08 10:55:34 changed by duncan

Module/file dependency analysis is not relevant (#15 and #159). That's a different kind of dependency.

#177 and #262 are closely related though.

04/24/08 03:24:47 changed by duncan

  • milestone set to Cabal-1.6.

(follow-up: ↓ 8 ) 06/19/08 06:35:21 changed by duncan

Do we really need this? I'm not sure we do.

We can already specify that we need C libs and headers (and frameworks and pkg-config packages). Do we also need to be able to specify the native packages that provide those C libs and headers?

When we make native packages from cabal packages we can derive which other native packages provide the C libs and headers. For example if we have extra-libraries: z then the cabal->native tool just asks the package manager which package provides the file /usr/lib/libz.so. Obviously this is system-specific.

(in reply to: ↑ 7 ) 06/19/08 09:04:09 changed by ross@soi.city.ac.uk

  • status changed from new to closed.
  • resolution set to invalid.

Replying to duncan:

Do we really need this? I'm not sure we do. We can already specify that we need C libs and headers (and frameworks and pkg-config packages). Do we also need to be able to specify the native packages that provide those C libs and headers?

OK, I'll buy that.

07/08/08 11:46:31 changed by lemming

  • status changed from closed to reopened.
  • resolution deleted.

We have support for different compilers, why not also having support for different package systems? We could either sort the dependencies with respect to distributions: 

Debian-Depends: zlib-devel, alsa-devel
Fedore-Depends: zlib-devel, alsa-devel

or with respect to needed files: 

File-Depends: zlib.h - zlib-devel.rpm >= 0.4, zlib-devel.deb >= 0.4
File-Depends: asound.h - alsa-devel.rpm >= 2.0, alsa-devel.deb >= 2.0

08/15/08 07:16:20 changed by duncan

  • milestone changed from Cabal-1.6 to _|_.

I think the native package conversion tools should be doing this reverse dependency lookup, matching headers, C libs or build tools that packages need to native packages. It does not scale to ask package authors to know what native package name and version is needed on each different system (in particular they would have no way to test it).