John Fleck wrote:
I guess what Jody is suggesting is to install a .pc file that sets a number of variables. Something like this:On Sat, 2002-09-07 at 20:51, Jody Goldberg wrote:On Thu, Sep 05, 2002 at 08:25:36PM -0600, John Fleck wrote:I'd like to restart the discussion about how to deal with this so that we can come up with an answer and take care of the problem in the GNOME 2.2 time frame. I don't have the auto* expertise to suggest the specific syntax needed in our build files. I can only assume the suggested fixed offered by James and Tommi on the bug report are correct. I do see more dragons ahead down the path we're on if we keep trying to fix this one xmldocs.make file at a time. Suggestions?My first thought was to have something akin to intltool. However, I suspect that a low tech approach may be simpler. Have a module that contains - a copy of the xmldocs.make file - pkgconfig info with a pointer to the installed copy of xmldocs.make Then application can cut-n-paste some pkgconfig magic to find and include the common copy of the xmldocs.make file. It avoids making major changes to the current infrastructure, and does not suffer from the problems associated with the dreaded 'macros' dir approach.This sounds like the simplest approach, but y'all need to explain stuff better for me. How does "pkgconfig" work?
Name: Gnome Doc Utils Version: XXX doctoolsdir=/some/dirThis value could then be retrieved with the command "pkg-config --variable=doctoolsdir gnome-doc-tools". It would also be possible to do version checks for the doctools.
This kind of set up would require a some non-trivial stuff in the autogen script, so it might not have any real benefits over a "gnome-doc-toolise" script.
This can be solved in either case by maintaining multiple versions of the various files. For instance, a gnome-doc-toolize script could take a "--require-version=X" argument or something, where X is a version of the doc build files. It simply installs the version requested.Where would the installed copy of xmldocs.make (and omf.make) go? gnome-common? Or do we still need to create our own module to handle this? And will this approach still be subject to the backwards compatibility problem Malcolm alluded to earlier?
Both the makefile rules and the rule file copying infrastructure could do with a review. It would be good to work out what features are required, and what we are trying to build.The other issue we need to address is finding a hacker to implement whatever we come up with. I'll work closely with whoever, but I'm not comfortable/competent doing this kind of stuff myself.
It would also be good to make sure the build rules work with automake-1.6. This includes being able to build the docs in a srcdir!=builddir build with a read-only source dir. It would be good to completely switch GNOME away from automake-1.4, so it is desirable for the doc build tools to work with both automakes.
James. -- Email: james daa com au | Linux.conf.au http://linux.conf.au/WWW: http://www.daa.com.au/~james/ | Jan 22-25 Perth, Western Australia.