On Tue, 2008-06-17 at 11:50 +0100, Alistair Bayley wrote:

I've pushed the current Setup and .cabal to our repo. You can say: darcs get http://darcs.haskell.org/takusen

Then do this: ghc --make Setup setup configure -fodbc -fsqlite -fpostgres (note that you need to have these backends on your path; perhaps just -fodbc -fsqlite for you?) setup register --gen-pkg-config

I've just done this. Takusen.buildinfo contains:

extra-libraries: odbc32 pq sqlite3 extra-lib-dirs: "C:\\Program Files\\sqlite3\\" C:/PROGRA~1/POSTGR~1/8.1/lib includes: install-includes: include-dirs: "C:\\Program Files\\sqlite3\\" C:/PROGRA~1/POSTGR~1/8.1/include C:/PROGRA~1/POSTGR~1/8.1/include/server

Ok, so the issue is that only the autoconfUserHooks looks for .buildinfo files. The assumption was that configure scripts would want to write a .buildinfo file while Setup.hs scripts can do it directly without needing to go via any file. However the UserHooks api doesn't make it all that convenient to return an adjusted BuildInfo record. There is: preConf :: Args -> ConfigFlags -> IO HookedBuildInfo, which looks like what you want, but because it runs before configure it doesn't give you access to all the stuff that the configure step does (all the stuff in LocalBuildInfo). So probably the easiest thing to do is to use the autoconfUserHooks anyway and make sure you override postConf otherwise it'll try to find a ./configure script to run. The reason I couldn't reproduce it before of course is that I was making assumptions about what you were doing and using autoconfUserHooks :-) Duncan

On Fri, 2008-06-20 at 10:19 +0100, Alistair Bayley wrote:

2008/6/19 Duncan Coutts :

...

Ok, so the issue is that only the autoconfUserHooks looks for .buildinfo files. The assumption was that configure scripts would want to write a .buildinfo file while Setup.hs scripts can do it directly without needing to go via any file.

So probably the easiest thing to do is to use the autoconfUserHooks anyway and make sure you override postConf otherwise it'll try to find a ./configure script to run.

The reason I couldn't reproduce it before of course is that I was making assumptions about what you were doing and using autoconfUserHooks :-)

Well, partly my fault. I was using defaultUserHooks, but this is now marked as deprecated, so I changed it to simpleUserHooks. Make a change, something breaks, is there a connection? :-)

Yep. defaultUserHooks was completely misleading as it was not the default. (!!?!) Yes, you might reasonably have expected that defaultMain = defaultMainWithHooks defaultUserHooks but no. defaultUserHooks was actually really autoconfUserHooks except that if a ./configure script was not found it did not complain. This caused confusion all round (especially for packages that really did need a ./configure but where ./configure was not executable eg because it was from a darcs repo or because it had to be generated with autoconf).

We were always overriding the postConf hook, so using autoconfUserHooks as a defaultUserHooks replacement seems to work.

Ok. Duncan