Re: Haskell-Cafe Digest, Vol 51, Issue 180
I'm trying to build diverse packages from Hackage with ghc 6.8.1, they usually fail to build because of missing language extensions.
Sometimes I am unable to determine the proper name of the extension missing in .cabal I tend to slap {- #OPTIONS -fglasgow-exts #-} at the top of the troublesome file. It works, but out of curiosity, what is the downside of such an approach ? (bigger executables ?)
Can you list which packages failed to build out of the box?
-- Don
Well I'd say none of the packages I've tried, build out of the box, that include : haskelldb haskelldb-hdbc haskelldb-hdbc-sqlite3 HDBC HDBC-sqlite3 Agreed some of these compile right after tweeking the build-depends: and extensions: lines in the .cabal file (apart from the pesky PatternSignatures which require a LANGUAGE pragma in the source file) haskelldb-hdbc-sqlite3 is the one that I couldn't get past... I didn't bother with hsql-mysql-1.7 since Duncan Coutts mentioned it required significant work (and I cannot do much) Manu
Well I'd say none of the packages I've tried, build out of the box...
I'm not a windows developer, but.... Is it actually reasonable to expect any cabal packages that depend on external c libraries and headers to build out of the box on windows? How can cabal find out where those files are, without requiring a config file to be edited? Tim
On 11/28/07, Tim Docker
Well I'd say none of the packages I've tried, build out of the box...
I'm not a windows developer, but....
Is it actually reasonable to expect any cabal packages that depend on external c libraries and headers to build out of the box on windows? How can cabal find out where those files are, without requiring a config file to be edited?
Tim
Tim, It is reasonable if you set the LIB and INCLUDE environment variables to point to the MSYS /usr/local/lib and /usr/local/include directories. Of course you'll have to build the c library from source in MSYS/MinGW for this to work. You'll also have to manually copy the dll files to a location in the PATH. set LIB=%LIB%;C:\MSYS\1.0\local\lib set INCLUDE=%INCLUDE%;C:\msys\1.0\local\include You can this as a one time change in the Systems control panel. If you install the C library from a binary distribution (usually installed in some arbitrary location on the pc) then the easiest way is to edit the cabal file. Cheers, Olivier.
On Thu, 2007-11-29 at 13:51 +1100, Tim Docker wrote:
Well I'd say none of the packages I've tried, build out of the box...
I'm not a windows developer, but....
Is it actually reasonable to expect any cabal packages that depend on external c libraries and headers to build out of the box on windows? How can cabal find out where those files are, without requiring a config file to be edited?
It's usually worse than that. The most likely situation is that the C library and header files are not even installed. This is a big problem for all packages that wrap C libs. Sometimes the C code is sufficiently simple that one can just bundle it. My zlib and bzlib packages on hackage do that and that's the only reason they work on Windows. This is not a realistic solution for most other binding packages. Duncan
From: haskell-cafe-bounces@haskell.org [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of Duncan Coutts On Thu, 2007-11-29 at 13:51 +1100, Tim Docker wrote:
Is it actually reasonable to expect any cabal packages that
depend on
external c libraries and headers to build out of the box on windows? How can cabal find out where those files are, without requiring a config file to be edited?
It's usually worse than that. The most likely situation is that the C library and header files are not even installed. This is a big problem for all packages that wrap C libs.
It can be done, with a bit of work, luck, and a brittle cabal Setup.hs :-) If you assume that the user has installed the 3rd party library correctly, and you know it's layout and an executable it uses (which is on the PATH), then you can do something like what HSQL does (and Takusen now, which copied HSQL's approach). That is, you ask for the location of the known executable in the PATH, and then build your header (include) and library paths relative to the location of the executable. That's what we've done in Takusen for the Oracle and Sqlite installations. For PostgreSQL there is a program you can run which will emit the installed locations of the include and library files, so that's slightly less brittle. Of course, if the particular libs are not on the PATH then this won't work :-( Alistair ***************************************************************** Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. *****************************************************************
Duncan Coutts wrote:
Tim Docker wrote:
Is it actually reasonable to expect any cabal packages that depend on external c libraries and headers to build out of the box on windows?
How can cabal find out where those files are, without requiring a config file to be edited?
It's usually worse than that. The most likely situation is that the C library and header files are not even installed. This is a big problem for all packages that wrap C libs.
I wonder if this could be addressed by discarding the desire to run magically "out of the box", but make the requirements clearer. Currently the choices seem to be: * Require the user to install these libs+headers "just right" (on the PATH or in certain MSYS directories) so that they are found. * Edit the cabal package file to point to the libs+headers Perhaps a worthwhile addition to cabal would be for it to be able to read a local config file, in which a user would specify where each package should get the necessary headers and libs? You'd manually create this file, maybe like: package: SDL include-dirs: c:\libs\SDL\include lib-dirs: c:\libs\SDL\lib package: curl include-dirs: c:\dev\mycurl\include lib-dirs: c:\dev\mycurl\lib When building a package X, cabal would consult this file to work out localised options for that package. Tim
emmanuel.delaborde:
I'm trying to build diverse packages from Hackage with ghc 6.8.1, they usually fail to build because of missing language extensions.
Sometimes I am unable to determine the proper name of the extension missing in .cabal I tend to slap {- #OPTIONS -fglasgow-exts #-} at the top of the troublesome file. It works, but out of curiosity, what is the downside of such an approach ? (bigger executables ?)
Can you list which packages failed to build out of the box?
-- Don
Well I'd say none of the packages I've tried, build out of the box, that include :
haskelldb haskelldb-hdbc haskelldb-hdbc-sqlite3 HDBC HDBC-sqlite3
Agreed some of these compile right after tweeking the build-depends: and extensions: lines in the .cabal file (apart from the pesky PatternSignatures which require a LANGUAGE pragma in the source file)
haskelldb-hdbc-sqlite3 is the one that I couldn't get past...
I didn't bother with hsql-mysql-1.7 since Duncan Coutts mentioned it required significant work (and I cannot do much)
Please contact the maintainers of these larger database bindings to get them updated for the new release. (Its possible the authors haven't yet attempted the update, that its hard, or they just forgot). -- Don
participants (6)
-
Bayley, Alistair -
Don Stewart -
Duncan Coutts -
manu -
Olivier Boudry -
Tim Docker