cabal uses haddock from hard-coded location

[Frederik]

I don't know if this is a feature or a bug. It seems that cabal doesn't search for the haddock executable in $PATH but uses a hard-coded location. Is this the best behaviour? It seems confusing to me. It makes it difficult to upgrade different pieces of the system separately.

[duncan]

Will need more details, symptoms, build logs or whatever. What is this hard coded location? As far as I know and from looking at the code, it uses the path to find haddock, just like it does for almost every other program.

Also, it'd be helpful to know if you're talking about haddock-0.x or 2.x as they get treated somewhat differently.

[Frederik]

I see now that Cabal is storing the executable location in "dist/setup-config" during the configure step. Still seems somewhat strange, do other build systems do that? I think of PATH as part of my configuration already, it's not like I would have PATH set up correctly when configuring a package, and then incorrectly when building the same package. On the other hand, maybe there's a good reason I am not aware of for doing it this way.

[duncan]

If someone specifies a non-standard location using --happy-prog= then we have to remember that in the configuration somewhere. Even if the program is on the path we have to check that it does indeed exist, so that involves finding it and often running it to check its version. Then the choice is between remembering the unqualified or fully qualified path. There does not seem to be much to choose between the two, we somewhat arbitrarily pick the qualified path.

I think other systems do this too, eg you'll see many build systems running /usr/bin/gcc even though they were only looking for gcc on the path at configure time. For example autoconf saves the path info in the Makefile, generated by ./configure.

[Frederik]

OK, that makes sense. Sorry for the bogus bug.