From: Jens P. <je...@ju...> - 2004-08-19 09:14:43
|
Hi, I just committed changes required to build the documentation with haddock. gendoc/ and doc/ have been removed. The documentation is built with the "html" target if haddock is installed and there is also a "install-html" target. Quite a bit more work that I originally thought but at least it works for me. :-) I came up with a few minor questions/issues while doing this: 1) I couldn't really make up my mind if the Hierarchy module should be included in the Gtk documentation or not since it mostly just documents the internals? 2) It occurred to me it would be really cool if we could get the documentation to work in devhelp, where all the gtk/gnome documentation is more available locally - it is pretty "neat". 3) I improved (I hope) the way gconf, glade and sourceview are built so that ../gtk/general etc are only searched by c2hs and Hierarchy.o etc are not used when compiling them. Comments welcome - I'm sure improvements can still be made. Enjoy, Jens |
From: Duncan C. <dun...@wo...> - 2004-08-19 14:59:27
|
In message <412...@ju...> Jens Petersen <je...@ju...> writes: > I just committed changes required to build the documentation > with haddock. gendoc/ and doc/ have been removed. > The documentation is built with the "html" target if haddock > is installed and there is also a "install-html" target. > Quite a bit more work that I originally thought but at least > it works for me. :-) I'll try it out in October. :-) > I came up with a few minor questions/issues while doing this: > > 1) I couldn't really make up my mind if the Hierarchy module should > be included in the Gtk documentation or not since it mostly just > documents the internals? When I first started building hadock docs I experimented both ways. I think it should be excluded. However this is not wholly possible. Obviously haddock needs to read the Hierarchy.hs module or it'll never see the definitions. We can mark the module as hidden to hadock and it will expand any definitions in the module into which they are imported and references to the data type will go to the local definition. However cross module references will not be done like this, they will still point to the Hierarchy module html documentation. It's not clear if haddock could be improved to do anything about this since which module should it point to? We know there is some mapping between the types defined in the Hierarchy module and the other modules but I don't think you could work it out automatically very easily. I suppose you could say: data type Foo comes from a hiden module, look for a module in which it's documentation is expanded (re-exported), if there is only one such module link to that, otherwise pick one randomly and emit a warning. Axel sugested we link not to the data/class type but to the name of the module in which it lives. ie we should say "Button" rather than 'Button'. I've sort of half done this for some of the modules I documented recently, but I'm not sure if it is the ideal solution. We could always put the definition of the classes in each module using Template Haskell! :-) This is not a serious suggestion, we would almost certianly end up with circular module imports. > 2) It occurred to me it would be really cool if we could get > the documentation to work in devhelp, where all the gtk/gnome > documentation is more available locally - it is pretty "neat". I'd never seen devhelp before. It does look good. I'll probably start using it when I get back to binding more stuff rather than using the web site. > 3) I improved (I hope) the way gconf, glade and sourceview are > built so that ../gtk/general etc are only searched by c2hs > and Hierarchy.o etc are not used when compiling them. That looks better. Cheers. Duncan |
From: Axel S. <A....@ke...> - 2004-08-20 09:54:45
|
On Fri, Aug 20, 2004 at 12:03:32AM +0900, Jens Petersen wrote: > > openBinaryFile: does not exist (No such file or directory) > > > > There is in fact no directory doc in share. Removing the -i switches, I > get a > > result but lots of warnings (cannot resolve "IO" and the like). Is there > any > > way around this? > > You're right, the requirement for base.haddock should be optional. > Basically this is what --with-ghc-docdir is for, but I suppose it should > default to off if the option is not passed to configure... > > Any better now? Yes, it does compile now. > >>I came up with a few minor questions/issues while doing this: > >> > >>1) I couldn't really make up my mind if the Hierarchy module should > >>be included in the Gtk documentation or not since it mostly just > >>documents the internals? > > > > > >Ideally not. The type of each widget belongs to the widget. They are just > >in Hierarchy.chs because that files is automatically generated. > > Ok, then I've added it to the excluded list. In contrast to before, all gtk2hs type are now not recognized (and linked) at all. I guess we have to live with that for now. > >>2) It occurred to me it would be really cool if we could get > >>the documentation to work in devhelp, where all the gtk/gnome > >>documentation is more available locally - it is pretty "neat". > > > > > >Is that html? > > Yep, but it requires some xml in a .devhelp file to describe the contents. > gtk-doc generates this automatically for the C libs I believe. > Well this is probably a longer term thing for us I guess if at all > feasible... > If there were links from the gtk2hs documentation to the gtk2 documentation > this would be really nice. > > >It looks nice! I guess moving to hierarchical namespaces is next :-) > :) > > Jens > > ps Btw are you planning to announce 0.9.6? :) I guess I should. After updating the tar package. Axel. |
From: <msj...@gm...> - 2004-09-01 13:58:53
|
On Fri, 20 Aug 2004 10:53:37 +0100, Axel Simon <a....@ke...> wrote: > > ps Btw are you planning to announce 0.9.6? :) > I guess I should. After updating the tar package. Any progress on this? ;) I'd like to upload gtk2hs to Debian soon, but I'd prefer to wait until I know which the final 0.9.6 tarball is... /Martin |
From: Axel S. <A....@ke...> - 2004-09-01 14:30:39
|
On Wed, Sep 01, 2004 at 03:58:49PM +0200, Martin Sjgren wrote: > On Fri, 20 Aug 2004 10:53:37 +0100, Axel Simon <a....@ke...> wrote: > > > ps Btw are you planning to announce 0.9.6? :) > > I guess I should. After updating the tar package. > > Any progress on this? ;) I'd like to upload gtk2hs to Debian soon, but > I'd prefer to wait until I know which the final 0.9.6 tarball is... Ok, I uploaded the current HEAD with the same version number. If you sent me the .deb package, I'll upload that, too. Thanks, Axel. |
From: <msj...@gm...> - 2004-09-04 08:44:04
|
On Wed, 1 Sep 2004 15:29:15 +0100, Axel Simon <a....@ke...> wrote: > On Wed, Sep 01, 2004 at 03:58:49PM +0200, Martin Sjgren wrote: > > On Fri, 20 Aug 2004 10:53:37 +0100, Axel Simon <a....@ke...> wrote: > > > > ps Btw are you planning to announce 0.9.6? :) > > > I guess I should. After updating the tar package. > > > > Any progress on this? ;) I'd like to upload gtk2hs to Debian soon, but > > I'd prefer to wait until I know which the final 0.9.6 tarball is... > > Ok, I uploaded the current HEAD with the same version number. If you sent > me the .deb package, I'll upload that, too. Um. demo/filechooser is still not present in the tarball and there are cvs conflict markers in the ChangeLog file. BTW, is there a way to NOT build the demo programs, other than hacking the makefiles? It makes little sense to build the demo programs when I compile the Debian packages. /Martin |
From: Axel S. <A....@ke...> - 2004-09-04 09:09:44
|
On Sat, Sep 04, 2004 at 10:44:00AM +0200, Martin Sjgren wrote: > Um. demo/filechooser is still not present in the tarball and there are > cvs conflict markers in the ChangeLog file. Changed the ChangeLog, my bad. I think for the filechooser demo we have to wait till October until Duncan is back. > BTW, is there a way to NOT build the demo programs, other than hacking > the makefiles? It makes little sense to build the demo programs when I > compile the Debian packages. I changed the toplevel Makefile and mk/recurse.mk so that demos are built when you say make all but not when you say make inplace. You can say make install after make inplace. I commented out the filechoose demo program for now. It forgot about that since I'm building against 2.2 that doesn't have the filechooser widget. Does it work now? Thanks for trying, Axel. |
From: Duncan C. <dun...@wo...> - 2004-09-04 23:21:04
|
In message <200...@my...> Axel Simon <A....@ke...> writes: > On Sat, Sep 04, 2004 at 10:44:00AM +0200, Martin Sjgren wrote: > > Um. demo/filechooser is still not present in the tarball and there are > > cvs conflict markers in the ChangeLog file. > > Changed the ChangeLog, my bad. I think for the filechooser demo we have to > wait till October until Duncan is back. Did I forget to add files to cvs, or just to change the Makefile to add stuff into the tarball? If the former, you will have to wait 'til October (Duncan is now in the deepest north midwest of the USA). Otherwsie it should just be a matter of fiddling with the gtk/Makefile or gtk/demo/filechooser/Makefile to add that demo into the tarball. > > BTW, is there a way to NOT build the demo programs, other than hacking > > the makefiles? It makes little sense to build the demo programs when I > > compile the Debian packages. On the other hand, building the demos (but not installing them) serves as a useful primitive test-suite. I catch all my linker errors when building the demos. > I changed the toplevel Makefile and mk/recurse.mk so that demos are built > when you say make all but not when you say make inplace. You can say make > install after make inplace. I commented out the filechoose demo program > for now. It forgot about that since I'm building against 2.2 that doesn't > have the filechooser widget. Keep a list of stuff I need to do for when I get back! :-) Duncan |
From: Axel S. <A....@ke...> - 2004-09-05 08:52:58
|
On Sun, Sep 05, 2004 at 12:20:48AM +0100, Duncan Coutts wrote: > In message <200...@my...> Axel Simon <A....@ke...> writes: > > On Sat, Sep 04, 2004 at 10:44:00AM +0200, Martin Sjgren wrote: > > > Um. demo/filechooser is still not present in the tarball and there are > > > cvs conflict markers in the ChangeLog file. > > > > Changed the ChangeLog, my bad. I think for the filechooser demo we have to > > wait till October until Duncan is back. > > Did I forget to add files to cvs, or just to change the Makefile to add stuff into the tarball? If the former, you will have to wait 'til October (Duncan is now in the deepest north midwest of the USA). Otherwsie it should just be a matter of fiddling with the gtk/Makefile or gtk/demo/filechooser/Makefile to add that demo into the tarball. I'm afraid they are not in CVS. I uncommented the line that adds the demo in the Makefile. > > > BTW, is there a way to NOT build the demo programs, other than hacking > > > the makefiles? It makes little sense to build the demo programs when I > > > compile the Debian packages. > > On the other hand, building the demos (but not installing them) serves as a useful primitive test-suite. I catch all my linker errors when building the demos. > > I changed the toplevel Makefile and mk/recurse.mk so that demos are built > > when you say make all but not when you say make inplace. You can say make > > install after make inplace. I commented out the filechoose demo program > > for now. It forgot about that since I'm building against 2.2 that doesn't > > have the filechooser widget. > > Keep a list of stuff I need to do for when I get back! :-) - rework my Makefiles so I understand them... Have a nice trip, Axel. |
From: <msj...@gm...> - 2004-09-05 10:44:25
Attachments:
clean.diff
|
On Sat, 4 Sep 2004 10:09:19 +0100, Axel Simon <a....@ke...> wrote: > On Sat, Sep 04, 2004 at 10:44:00AM +0200, Martin Sjgren wrote: > > Um. demo/filechooser is still not present in the tarball and there are > > cvs conflict markers in the ChangeLog file. > > Changed the ChangeLog, my bad. I think for the filechooser demo we have to > wait till October until Duncan is back. Well, the filechooser files are in cvs, it's just that they're not present in the tarball. > > BTW, is there a way to NOT build the demo programs, other than hacking > > the makefiles? It makes little sense to build the demo programs when I > > compile the Debian packages. > > I changed the toplevel Makefile and mk/recurse.mk so that demos are built > when you say make all but not when you say make inplace. You can say make > install after make inplace. I commented out the filechoose demo program > for now. It forgot about that since I'm building against 2.2 that doesn't > have the filechooser widget. That won't help, will it? 'make inplace' only works for libraries, not for the tools, so the whole build goes kaboom. I *suppose* I could run $(MAKE) -C tools $(MAKE) inplace or something like that, but it's a bit messy. For now, I hacked recurse.mk to ignore $(MAKE_APPS) completely. "messy" is a word that describes the whole mk directory pretty well, actually. ;) Btw, I'm also attaching a patch for common.mk and library.mk that removes doc dirs on clean. I think the clean target needs a huge overhaul, it feels like if I abort a build, depending on exactly when I hit ctrl-c, make clean does different things. I guess I don't have to tell you what a mess that makes of the generation of the Debian .diff.gz file... :( |
From: Axel S. <A....@ke...> - 2004-09-06 07:48:50
|
On Sun, Sep 05, 2004 at 12:44:23PM +0200, Martin Sjgren wrote: > > Changed the ChangeLog, my bad. I think for the filechooser demo we have to > > wait till October until Duncan is back. > > Well, the filechooser files are in cvs, it's just that they're not > present in the tarball. Oh, sorry, I didn't get that. > That won't help, will it? 'make inplace' only works for libraries, not > for the tools, so the whole build goes kaboom. I *suppose* I could run > $(MAKE) -C tools > $(MAKE) inplace > or something like that, but it's a bit messy. For now, I hacked > recurse.mk to ignore $(MAKE_APPS) completely. > > "messy" is a word that describes the whole mk directory pretty well, > actually. ;) Yes and here's the next flaw: The reason why filechooser demo is not included in the tarball is that my configuration builds without filechooser, hence without demo, hence when I build a dist, I don't include it. That is a mess. Quickfix: Do an anonymous CVS checkout and make dist. Sorry about that. > > Btw, I'm also attaching a patch for common.mk and library.mk that > removes doc dirs on clean. Applied, thanks. > I think the clean target needs a huge overhaul, it feels like if I > abort a build, depending on exactly when I hit ctrl-c, make clean does > different things. I guess I don't have to tell you what a mess that > makes of the generation of the Debian .diff.gz file... :( I'd like to have a single top-level makefile that builds all necessary stuff depending on a few variables. automake is unfortunately not a solution since it dosn't cope at all with c2hs and ghc --make which both turn several sourcefiles into one target. automake cannot be extended easily which is why I don't think that automake is a viable route. Sorry about this, Axel. |
From: Duncan C. <dun...@wo...> - 2004-09-09 00:02:03
|
In message <200...@my...> Axel Simon <A....@ke...> writes: > I'd like to have a single top-level makefile that builds all necessary > stuff depending on a few variables. automake is unfortunately not a > solution since it dosn't cope at all with c2hs and ghc --make which both > turn several sourcefiles into one target. automake cannot be extended > easily which is why I don't think that automake is a viable route. I'm not sure that we shouldn't change to a single input, single output style for both ghc and c2hs anyway (even if it wern't for automake). ghc itself builds using makefiles and not 'ghc --make'. It could even be quicker on rebuilds since ghc --make will always chase source files and relink which can take some time for some of our tools & modules. I'd quite like to have a go at making c2hs cache intermediate files better so a single invocation scheme would be quick enough. I'd make the cacheing explicit and makefile-friendly rather than hiding the cache files away. Just musing, no short term suggestion, sorry. Duncan (who is now in Seattle) |
From: <msj...@gm...> - 2004-09-09 07:25:28
|
On Thu, 9 Sep 2004 01:01:55 +0100 (BST), Duncan Coutts <dun...@wo...> wrote: > In message <200...@my...> Axel Simon <A....@ke...> writes: > > I'd like to have a single top-level makefile that builds all necessary > > stuff depending on a few variables. automake is unfortunately not a > > solution since it dosn't cope at all with c2hs and ghc --make which both > > turn several sourcefiles into one target. automake cannot be extended > > easily which is why I don't think that automake is a viable route. > > I'm not sure that we shouldn't change to a single input, single output style for both ghc and c2hs anyway (even if it wern't for automake). > > ghc itself builds using makefiles and not 'ghc --make'. It could even be quicker on rebuilds since ghc --make will always chase source files and relink which can take some time for some of our tools & modules. I agree, ghc --make is nice for small projects, but in my opinion it's not good enough for large projects. In Debian, our source packages have separate targets for build and install, and as it is now, the install target takes way long to run because ghc --make has to go through a huge round of "Skipping Foo, Skipping Bar, ..." Heck, we can even use ghc to generate the dependencies with ghc -M and still get the advantage of ghc's dependency chasing, without having to worry about rebuilding. /Martin |
From: Axel S. <A....@ke...> - 2004-09-09 08:19:00
|
On Thu, Sep 09, 2004 at 09:25:25AM +0200, Martin Sjgren wrote: > On Thu, 9 Sep 2004 01:01:55 +0100 (BST), Duncan Coutts > <dun...@wo...> wrote: > > In message <200...@my...> Axel Simon <A....@ke...> writes: > > > I'd like to have a single top-level makefile that builds all necessary > > > stuff depending on a few variables. automake is unfortunately not a > > > solution since it dosn't cope at all with c2hs and ghc --make which both > > > turn several sourcefiles into one target. automake cannot be extended > > > easily which is why I don't think that automake is a viable route. > > > > I'm not sure that we shouldn't change to a single input, single output style for both ghc and c2hs anyway (even if it wern't for automake). > > > > ghc itself builds using makefiles and not 'ghc --make'. It could even be quicker on rebuilds since ghc --make will always chase source files and relink which can take some time for some of our tools & modules. > > I agree, ghc --make is nice for small projects, but in my opinion it's > not good enough for large projects. In Debian, our source packages > have separate targets for build and install, and as it is now, the > install target takes way long to run because ghc --make has to go > through a huge round of "Skipping Foo, Skipping Bar, ..." But this shouldn't happen. That is a bug in the makefiles (I need a bigger todo list). > Heck, we can even use ghc to generate the dependencies with ghc -M and > still get the advantage of ghc's dependency chasing, without having to > worry about rebuilding. Ok, I am about to be convinces. If we can't prevent ghc from running if you say make install, then we definitely go for the single invocation, ok? I'm just scared of the long compilation times with gtk+hs back then. Axel. |