Re: config.h namespace clashes
John Meacham wrote: [...] also, it would be good if config.h could be renamed to something like ghc-config.h, because otherwise the conflict between the names can hide bugs where you get the incorrect config.h or make it tricky to get at the GHC one if it is actually the one you want. That's definitely on the fptools-ToDo-List: Every package/project should have its own configuration shell script, configuration header used only for build time and configuration header included in pre-built distributions. It's just a matter of splitting of configure.ac and pushing the relevant parts down the fptools hierarchy. Any volunteers? I'll do it when I've got some time left and no one else has done it by then, but this will definitely not be in the near future... Cheers, S. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
config.h namespace clashes
The inclusion of the GHC made config.h in HsFFI.h makes it extremely difficult to use autoconf with ones own projects without dealing with horrible name clashes everywhere. Is there some way this can be fixed? perhaps pre-generating the HsFFI.h. although I don't think it is stated explicitly by the FFI report, I would assume that HsFFI.h should not clash with anything that doesn't start with Hs, hs_ or HS_. also, it would be good if config.h could be renamed to something like ghc-config.h, because otherwise the conflict between the names can hide bugs where you get the incorrect config.h or make it tricky to get at the GHC one if it is actually the one you want. John -- --- John Meacham - California Institute of Technology, Alum. - [EMAIL PROTECTED] --- ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: config.h namespace clashes
The inclusion of the GHC made config.h in HsFFI.h makes it extremely difficult to use autoconf with ones own projects without dealing with horrible name clashes everywhere. Is there some way this can be fixed? perhaps pre-generating the HsFFI.h. although I don't think it is stated explicitly by the FFI report, I would assume that HsFFI.h should not clash with anything that doesn't start with Hs, hs_ or HS_. also, it would be good if config.h could be renamed to something like ghc-config.h, because otherwise the conflict between the names can hide bugs where you get the incorrect config.h or make it tricky to get at the GHC one if it is actually the one you want. Yes, we should definitely do that. I'm surprised this hasn't caused problems before (or maybe it has?). Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: config.h namespace clashes
On Mon, Mar 01, 2004 at 11:55:05AM -, Simon Marlow wrote: Yes, we should definitely do that. I'm surprised this hasn't caused problems before (or maybe it has?). The reasons it has not been as much of an issue before are twofold as far as I can tell, 1. cpp only complains if you #define something to a different value than it was previously defined. chances are any autoconf tests will succeed similarly during the building of ghc and later. 2. autoconf only recently started #defining PACKAGE, VERSION, BUGREPORT and friends, which will almost definatly be different. so, they probably were conflicting a lot before, but the symtoms were hidden. At least that was what I determined from my post-mortem when figuring out why the compiler started horking on -Werrors with ghc 6.2. John -- --- John Meacham - California Institute of Technology, Alum. - [EMAIL PROTECTED] --- ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
