new target ./setup plain_source?
Hi. What about adding another target ./setup plain_source which should preprocess everything (including cpp) and output the files to an extra directory? Why? This could be used for haddock documentation generation (Not sure how this is done) and perhaps to be read by future IDE's to provide compiler independent completion etc? eg ./setup haddock on haddock sources itself fails on line #if defined(mingw32_HOST_OS) ... What do you think? Marc Weber
On Sat, Jul 21, 2007 at 02:26:47AM +0200, Marc Weber wrote:
Hi.
What about adding another target ./setup plain_source which should preprocess everything (including cpp) and output the files to an extra directory? Why? This could be used for haddock documentation generation (Not sure how this is done) and perhaps to be read by future IDE's to provide compiler independent completion etc?
eg ./setup haddock on haddock sources itself fails on line
#if defined(mingw32_HOST_OS) ...
What do you think?
Sounds very cool. *However* the output will not be portable, since the FFI preprocessors work by inlining constants. It also sounds pretty easy. Look at the API docs (Distribution.* in your nearest GHC documentation bundle), see if it can be done in a stand-alone tool, if not by all means submit a ticket. Stefan
Sounds very cool. *However* the output will not be portable, It dasen't have to be portable. That's why you have your source distribution.tar.gz or darcs repa..
I just want a bunch of files which I can feed intto haddock or any other developement tool (tag generation etc).. If you need to refactor things using tools you could use this as starting point as well ( or do those existing refactorers read #defines as well? ) It's just an idea I had more than once durirng the last year. M.
Hi Marc, On Sat, Jul 21, 2007 at 02:26:47AM +0200, Marc Weber wrote:
What about adding another target ./setup plain_source which should preprocess everything (including cpp) and output the files to an extra directory? Why? This could be used for haddock documentation generation (Not sure how this is done)
"Setup haddock" preprocesses the files itself if necessary.
and perhaps to be read by future IDE's to provide compiler independent completion etc?
eg ./setup haddock on haddock sources itself fails on line
#if defined(mingw32_HOST_OS) ...
I suspect that haddock wasn't designed to be haddocked, as it's not a library. If you put a "extensions: CPP" line in the top section of the Cabal file then you get a bit further, to a parse error in src/BlockTable.hs; I'm not sure what the problem is there, but it's certainly not pre-processor related. I'm also not sure why Cabal is is running haddock on modules that are only used in an executable, or if it's meant to do that then why it isn't taking into account the CPP extension of the executable. Thanks Ian
Ian Lynagh wrote:
Hi Marc,
On Sat, Jul 21, 2007 at 02:26:47AM +0200, Marc Weber wrote:
What about adding another target ./setup plain_source which should preprocess everything (including cpp) and output the files to an extra directory? Why? This could be used for haddock documentation generation (Not sure how this is done)
"Setup haddock" preprocesses the files itself if necessary.
and perhaps to be read by future IDE's to provide compiler independent completion etc?
eg ./setup haddock on haddock sources itself fails on line
#if defined(mingw32_HOST_OS) ...
I suspect that haddock wasn't designed to be haddocked, as it's not a library. If you put a "extensions: CPP" line in the top section of the Cabal file then you get a bit further, to a parse error in src/BlockTable.hs; I'm not sure what the problem is there, but it's certainly not pre-processor related.
I'm also not sure why Cabal is is running haddock on modules that are only used in an executable, or if it's meant to do that then why it isn't taking into account the CPP extension of the executable.
I ran into this recently while making 'setup haddock' work on XMonad for Simon PJ. The 'extensions: CPP' needs to be put in the library part of the .cabal file, in addition to the executable part. And then Cabal runs Haddock twice: once for the (non-existent) library, and once for the executable. Probably something needs to be fixed here; I guess not many people use 'setup haddock' on executables. Cheers, Simon
On Tue, 2007-07-24 at 09:06 +0100, Simon Marlow wrote:
I'm also not sure why Cabal is is running haddock on modules that are only used in an executable, or if it's meant to do that then why it isn't taking into account the CPP extension of the executable.
I ran into this recently while making 'setup haddock' work on XMonad for Simon PJ. The 'extensions: CPP' needs to be put in the library part of the .cabal file, in addition to the executable part. And then Cabal runs Haddock twice: once for the (non-existent) library, and once for the executable. Probably something needs to be fixed here; I guess not many people use 'setup haddock' on executables.
In the dev version of Cabal we have a flag: setup haddock --executables so in theory just "setup haddock" should not generate docs for executables and with that flag it should. From a quick test on hscolour that does indeed appear to work as expected. Duncan
On Tue, Jul 24, 2007 at 12:21:37PM +0100, Duncan Coutts wrote:
In the dev version of Cabal we have a flag:
setup haddock --executables
so in theory just "setup haddock" should not generate docs for executables and with that flag it should. From a quick test on hscolour that does indeed appear to work as expected.
I couldn't find that in the dev version of the User's Guide.
On Tue, Jul 24, 2007 at 12:36:53PM +0100, Ross Paterson wrote:
On Tue, Jul 24, 2007 at 12:21:37PM +0100, Duncan Coutts wrote:
In the dev version of Cabal we have a flag:
setup haddock --executables
I couldn't find that in the dev version of the User's Guide.
Sorry, I missed it.
On Tue, 2007-07-24 at 12:36 +0100, Ross Paterson wrote:
On Tue, Jul 24, 2007 at 12:21:37PM +0100, Duncan Coutts wrote:
In the dev version of Cabal we have a flag:
setup haddock --executables
so in theory just "setup haddock" should not generate docs for executables and with that flag it should. From a quick test on hscolour that does indeed appear to work as expected.
I couldn't find that in the dev version of the User's Guide.
It got added in a very recent patch:
Wed May 30 20:47:47 BST 2007 Roberto Zunino
participants (6)
-
Duncan Coutts -
Ian Lynagh -
Marc Weber -
Ross Paterson -
Simon Marlow -
Stefan O'Rear