advance warning of Cabal-126.96.36.199 and package breakages
patperry at stanford.edu
Wed Feb 18 11:54:13 EST 2009
Thanks for the heads-up, Duncan. For the BLAS package, the situation
is slightly complicated, and I will still be sticking with autoconf
for now. The reasons are twofold:
1. The functions I am binding to are written in Fortran, and have
different calling conventions on different architectures. On some
architectures, the equivalent C function names have a trailing
underscore (e.g. "dgemm_"), and on some architectures they don't (e.g.
2. There is no standard name for a BLAS shared library. The autoconf
macro I use checks in libraries named atlas, blas, mkl, cxml, dxml,
sunperf, essl, and a few others.
For me to switch to git rid of autoconf, I would need Cabal to provide
1. A way to find out the C calling convention for Fortran functions.
2. A way to check if a specific function exists in a library.
3. An option to try a different library name if a check for a library
For reference, here is the autoconf macro I am using:
On Feb 18, 2009, at 5:23 AM, Duncan Coutts wrote:
> On Tue, 2009-02-17 at 00:24 +0000, Duncan Coutts wrote:
>> I'll be releasing Cabal-188.8.131.52 soon. I've been testing with
>> packages on
>> hackage for regressions. However even with the regressions fixed
>> will be a small handful of packages that will break with the new
>> release. This is because they are already incorrect it's just that
>> was previously hidden.
> I should like to point out that the fact that Cabal now does the
> for C header files and libs means we can generally do a better job now
> if the packages themselves do not try to do anything clever. We get
> consistent error messages but we also take into account extra flags
> passed in by the user which a custom check may omit (which means the
> user may not be able to install at all if they have the C libs in a
> non-standard location).
> For example:
> Searching for jack/jack.h...setup: user error (ERROR:
> jack/jack.h not found)
> And it ignores the --extra-include-dirs flag.
> If you maintain a FFI binding package, take a look to see if it has
> redundant checks in the ./configure or Setup.hs for C headers and
> While we're on the topic of good practise in configure scripts. Try to
> avoid if possible grabbing random environment variables and putting
> into a .buildinfo file. For example $CPPFLAGS or $LDFLAGS. The current
> way for users to specify non-standard install locations for C libs is
> via --extra-include-dirs and --extra-lib-dirs.
> If you want to argue that env vars are the better user interface then
> make the case and we people agree then we can do it in Cabal itself.
> Having it different in each package just confuses users.
> The other problem with putting the env vars into .buildinfo files is
> that the cc-options, ld-options don't just get used to build your
> package but they get put into the package registration info and used
> when building every dependent package.
> More advice:
> * Don't make configure set buildable: False. Just fail.
> * Do declare the key header files your package needs in
> the .cabal
> file rather than just in .hs or .hsc files. That way Cabal can
> check for them and tools that convert to native distro packages
> will notice the dependencies on foreign packages.
> Looking at the failing packages on hackage at the moment we've got
> 100 failing at build time and about 50 failing at configure time. A
> bunch more fail because they depend on other things that failed. The
> biggest cause for build failure seems to be incorrectly specified
> dependencies. That is they probably worked against one version and now
> fail to compile against some different version. Quite often that is
> base package, but it's not the majority.
More information about the Libraries