Re: [Opencxx-users] Makefile.am fixes

[Grzegorz J. <ja...@he...>]

On Wed, 10 Sep 2003, Yann Dirson wrote:

> 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 see. Go ahead and implement it if you think it is important, but to be
honest I don't think it is a cruicial feature. Implementing it involves
some maintenance burden (now anybody writting '$libdir' in docs should add
a link to directories.html to be consistient; and most likely that person
will not do it, because there is no mechanism or process that would
require him/her to do so), but we don't change docs often, so I don't see
a problem. I would encourage you to rather invest your time in
implementing your ideas about walkers, but if you think 'directories.html'
is a good thing, go ahead. Provided you get down to walkers afterwards :-)

> > 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 don't know about Synopsis, but in Doxygen you can also provide input in
free-form text, so you can combine code annotations with epic docs.

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

Yes, you can do this.

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

I think I did not understand what you mean by "adding hooks". Could you
elaborate on this?

> 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),

Sure.

> or to call the current one and manipulate the result Ptree
> again (useless copy of (part of) the Ptree).

What if you provide your own walker, which derives or delegates to the
existing walker? In your implementation of
'YourWalker::TranslateFunctionImplementation()' you could either call the
original walker (and possibly postprocess the result) or not call it and
do all processing by yourself. Is this what you are looking for?

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

I am not sure: are you talking about accessing the code from user-defined
metaclass methods or about writting your own derivative of Walker?

Best regards
Grzegorz


##################################################################
# Grzegorz Jakacki                       Huada Electronic Design #
# Senior Engineer, CAD Dept.              1 Gaojiayuan, Chaoyang #
# tel. +86-10-64365577 x2074               Beijing 100015, China #
# Copyright (C) 2002 Grzegorz Jakacki, HED. All Rights Reserved. #
##################################################################