advance warning of Cabal-1.6.0.2 and package breakages

[Patrick Perry]

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.  
"dgemm").

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  
the following:

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

For reference, here is the autoconf macro I am using:

http://github.com/patperry/blas/blob/master/m4/ax_blas.m4


Patrick

On Feb 18, 2009, at 5:23 AM, Duncan Coutts wrote:

> On Tue, 2009-02-17 at 00:24 +0000, Duncan Coutts wrote:
>> All,
>>
>> I'll be releasing Cabal-1.6.0.2 soon. I've been testing with  
>> packages on
>> hackage for regressions. However even with the regressions fixed  
>> there
>> 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  
>> this
>> was previously hidden.
>
> I should like to point out that the fact that Cabal now does the  
> checks
> 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  
> more
> 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:
>
> jack-0.5:
>        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  
> libs.
>
> While we're on the topic of good practise in configure scripts. Try to
> avoid if possible grabbing random environment variables and putting  
> them
> 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  
> about
> 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  
> the
> base package, but it's not the majority.
>
> Duncan
>