Re: [Opencxx-users] Makefile.am fixes

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

On Mon, Sep 08, 2003 at 09:54:29AM +0800, Grzegorz Jakacki wrote:
> Great. You have been added to the project.

Cool, thanks.  Committed.

Additionally, I've added the opencxx and tools modules to CVSROOT/modules,
for "cvs co -c" to be useful.


> I am afraid this may cause confusion to the users, because some of them
> reading the (installed version of) documentation may not notice, that the
> library path can vary. My personal opinion is that it is much safer to
> just say '$libdir/libocc.a' in docs, as it clearly indicates that the path
> may vary, also giving a hint on what the path depends (the name "libdir"
> occures verbatim in './configure --help').

Well, $libdir is clearly better than the current situation :)

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

> However, if you have some time to
> donate to documentation cleanup, then there is a long outstanding project
> of integrating documentation with code, so that it can be generated with
> Doxygen and/or Synopsis (which I hope would contribute to better
> maintenance of documentation).

I'll wait till I know the tool better before doing big doc things :)

Anyway I'd have to look at how Doxygen and Synopsis can help with user
documentation - I thought they were only useful for internals.

> Also there are coding tasks (both in core
> and infrastructure) if you would like to get involved.

There is one thing I'd like to do, but this needs to be discussed first to
find a way to integrate that in the occ design.  Here are 3 tasks which are
not currently possibly with stock occ - maybe with Vladimir's patch however:

- I currently had to find a way to spot all casts to a
pointer-to-class-instance in a large project.  I did that by patching the
Walker::TranslateCast method to simply add some code there.

- TAU is a profiling toolkit, which currently depends on PDT for automatic
code instrumentation, the latter depending on a parser based on a
proprietary compiler for the extraction of program information (location of
definitions, statements, etc).  I'd like to make a completely free parser
instead, but currently it does not seem possible to bind actions to the
translation of a global function definition, or of a statement.

- Use occ to produce a tagging facility (think etags), but based on real
code parsing instead of ad-hoc regexps applied to unpreprocessed code

All of this seems to be easily achieved if we can add hooks to the
translation of arbitrary language constructs (casts, statements...)

> PS: Haven't we met at BLUG meeting?

No, I was not there :)

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