On Sunday 16 September 2007 04:42, Ian Lynagh wrote: > At the interface to the outside world (i.e. the configure flags) they > have the normal semantics. We then append "/ghc-$(ProjectVersion)" to > the internal build system variables. This seems reasonable to me - I > don't think it would be better to put the "/ghc-$(ProjectVersion)" in > manually everywhere we use it, if that's what you're suggesting?
Alas, we do not have the usual interface to the outside world, because the Makefile variables have a different meaning, e.g. "make libdir=/foo" means something different in our project than in the rest of the GNU world. What makes this situation even worse is that other tools we use (like Cabal) expect the GNU meaning, so we have to convert back and forth, with no good reason for this complexity. Of course I don't want to mention the package suffix all over the place, we'll use Makefile variables including this suffix already, but we *do not* call them "libdir", "libexedir" etc. Probably this is a single variable "topdir", anyway, because GHC is restricted that way. > > I think I'll go for b) if nobody yells. > > I can't think about your proposals properly right now, but I do have a > patch that will hopefully finally get bindists working correctly on both > Windows and Linux, that I suspect would conflict with anything in this > area. I expect to push on Sunday or Monday, so if you could hold off a > couple of days then that would make my life easier. I don't want to make such changes before 6.8.1 is out, anyway. Let's get this release out of the door with all necessary hacks, and let's clean up the mess afterwards. Cheers, S. P.S. to any Cabal Gods out there: It would be nice if Cabal could handle "exec_prefix", "datarootdir" etc. with the defaults described in the GNU standards. No need to be creative here or only offer a subset... ;-) _______________________________________________ Cvs-ghc mailing list [email protected] http://www.haskell.org/mailman/listinfo/cvs-ghc
