Re: xmldocs.make and friends

[James Henstridge <james daa com au>]

John Fleck wrote:

> 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?
I guess what Jody is suggesting is to install a .pc file that sets a 
number of variables.  Something like this:

   Name: Gnome Doc Utils
   Version: XXX
   doctoolsdir=/some/dir

This 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.

> 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?
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.

> 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.
>  
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.

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.