advance warning of Cabal-1.6.0.2 and package breakages

[Duncan Coutts]

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