Re: [Opencxx-users] Makefile.am fixes

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

On Tue, 9 Sep 2003, Yann Dirson wrote:

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

Thanks.

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

I don't get it. How would this work?

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

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.

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

  * Derive (or delegate to) existing walker
  * Provide a factory that returns your walker (factories are currently
    being implemented by Vladimir)

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

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.

> > PS: Haven't we met at BLUG meeting?
>
> No, I was not there :)

Sorry, that was some other Yann.

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