Re: [Opencxx-users] Makefile.am fixes

[Yann D. <yd...@al...>]

On Wed, Sep 10, 2003 at 08:38:09AM +0800, Grzegorz Jakacki wrote:
> > > Thous I would discourage you
> > > from moving the docs to .in files etc.
> >
> > Some possibility would be to generate a directories.html from a .in and get
> > that linked from $libdir ?
> 
> I don't get it. How would this work?

Put a directories.html.in in CVS and shipped tarball, with something like
"on your system $libdir is @LIBDIR@" in it, and add this file to the list of
files to be generated by ./configure.  Then say <a
href="directories.html>$libdir</a> in man.html and possibly other places.


> I think they are just well-suited for APIs. In some packages APIs are
> internal, in OpenC++ much of its APIs goes to user's docs.

Sure.  But then only the part of the doc which is the API reference can be
generated that way.  Granted, it's surely already better than maintaining a
separate document.

I also wonder if it's easy to tell those tools to only generate a reference
for a given subset of the code - since we probably don't need to expose the
whole internals to users.


> > All of this seems to be easily achieved if we can add hooks to the
> > translation of arbitrary language constructs (casts, statements...)
> 
> Right. However after you expand the existing walker you need to have a way
> to coerce it back into the old functionality, so that the occ itself and
> legacy applications compile. However this seems doable.

Hm.  My idea was that without any hooks the behaviour would be the current
one.  But it's surely both more flexible and less intrusive to provide my
own walker in many cases.

However, say I want to instrument functions.  I'll have to provide a
replacement Walker::TranslateFunctionImplementation(), and it'd not be
comfortable to either override it with a copy-paste-modify version (code
maintainance), or to call the current one and manipulate the result Ptree
again (useless copy of (part of) the Ptree).

I'm under the impression that if we were given translator hooks within each
call to Translate(), with the default implementation just returning its
Ptree* argument, that would be sufficient.  I noticed a
TranslateFunctionBody(), but a quick code browsing does not make it obvious
to me that it's be taken into account here.  Clearly I'd need to experiment.

Regards,
-- 
Yann Dirson    <yd...@al...> |    Why make M$-Bill richer & richer ?
Debian-related: <di...@de...> |   Support Debian GNU/Linux:
Pro:    <yan...@fr...> |  Freedom, Power, Stability, Gratuity
     http://ydirson.free.fr/        | Check <http://www.debian.org/>