The tool in this directory are to semi-automatically generate binding modules complete with haddock format documentation for all gtk modules. With a little modification it should work for any other GObject-based api. It works by extracting an api description from the C source files and extracting documentation from the docbook documentation produced by gtk-doc. It is semi-automatic in the sense that the resulting binding module will need some hand tweaking and it is not intended that this tool be used automatically as part of the build process. It is mainly a time saving tool to relieve much manual work involved in writing binding modules. Some things that may need to be edited by hand: * Add your name at the top for new modules! * Some type signatures and marshaling code eg for possibly NULL Strings you would want to change to use Maybe String also it is not possible to automatically determine the element type of GLists so this will have to be determined manually. * Documentation. This is converted directly from the C documentation so there are usually things that you would want to change to make things make sense in Haskell. Code samples should be converted for example. == For users: == There is a Makefile to automate much of the process. Type just "make" to get a list of make targets and a brief description. There are a few stages that the Makefile helps to automate: * downloading and unpacking the source code for the right versions of packages * configuring and building each package and their DocBook documentation * running the tools that scan the various files and generate .chs modules You will libxslt installed (since that provides the program "xsltproc") == For hackers: == There are a few components to the system: There are a few perl scripts written by the mono/gtk-sharp authors. These extract information from GObject-based .h & .c files and generate xml descriptions. The xml files assume an object oreinted target language (C#) but it does preserve all the information ok. These scripts are GPL so should probably not be distributed in tarballs, just left in cvs. Besides they're just gtk2hs hacker tools. There is an XSLT program to extract per function documentation from docbook xml files into a more convenient format. It is pretty specific to the format of docbook document generated by gtk-doc (version 1.2). No doubt it will require changes if gtk-doc changes. The major component to the system is a Haskell program ApiGen.hs that reads in the api xml file and the documentation xml file and spits out .chs binding file(s) using the Template.chs file. The files are named the same as the object they bind. Some improvements that would be good: * Complete marshaling code for more types