[Opencxx-users] Re: [opencxx] Let's break OpenC++ up

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

On Thu, 13 Mar 2003, Michael Hohmuth wrote:

> Grzegorz Jakacki <ja...@he...> writes:
>
> > Conceptually OpenC++ consists of three sybsystems:
> >
> >     Frontend --- reads preprocessed sources, makes parse tree
> >         out of them; possibly OpenC++ static analyzer also belongs
> >         in this subsystem
> >
> >     Translator --- traverses syntax tree and transforms it
> >         according to rules described by metaclasses
> >
> >     Driver --- runs preprocessor, Frontend, Translator,
> >         native compiler and linker.
> >
> > As I understand Michael and Stefan work with Frontend and are not interested
> > in the rest of the system. I believe, that this is the most frequently
> > reused part of OpenC++ and I know of at least three more projects that
> > reuse just this part.
>
> (Just as an aside: Would you mind posting a list of the projects you
> know that use OpenC++ to this list or the project's homepage?  I would
> like to have a look at them, and I really learned a lot from looking
> at the Synopsis source code, for example.)

* Introspector
* Synopsis
* the commercial project I used to work on (non-open)
* I was told that 'Sds' projects also uses OpenC++, but I never contacted
  them
* Juan Carlos Arevalo-Baeza (should be on this list) once used
  OpenC++ in his project
* Walter Cazzola (should be on this list) once used
  OpenC++ in his project

> > Thus I suggest that we take it out and make it a separate library.
>
> There is a fourth part that lives somewhere in the middle between
> Frontend and Translator (maybe that's what you mean by ``static
> analyzer''): OpenC++'s symbol-table implementation, encapsulated in
> classes Environment, Encoding and friends.  We had trouble
> understanding and reusing particularly this part, and in the end
> decided not to use it, so it should be separable as well.

Right.

> > Otherwise I can see serious problems with testing.
> [...]
> > With separate Frontend library, we can test the library on its own, and
> > this is what we need at the moment, because we somehow have to add tests
> > for the new features implemented by patches from Fiasco project.
>
> I think what you are proposing can be achieved by some
> build-infrastructure (and maybe some terminology and documentation)
> changes, plus very little.  You actually do not need complete
> separation of the four parts comprising OpenC++ in order to facilitate
> testing -- separation would just be convenient for reuse.
>
> In my opinion, what's needed is just:
>
> 1. An abstract base class for Walker, which just provides the
>    interface for visiting a Ptree hierarchy and is completely
>    independent from the Translator and symbol-table parts.  (As an
>    added bonus, its visit functions should support return types other
>    than Ptree*, so it probably should be a template.)

But perhaps not called 'Walker', unfortunately, due to code base.

> 2. A simple unit-testing framework, to which tests for new
>    functionality (on a per-module level) can be added easily
>
> For our VFiasco project <http://www.vfiasco.org>, we use a wrapper
> around Walker which provides (1), and (2) consists of a set of
> unit-test programs that output test data and a simple Makefile (for
> GNU Make) that tests for regressions.

Could you part of your infrastructure to OpenC++? If so, can you put it
somewhere on the web so that we can review it and see what can OpenC++ get
from you?

> All in all, I think that the changes I proposed should be gradually
> added to the source base, but nothing more.  Frequent changes to the
> build system and library interface actually make reuse harder, not
> easier, and besides the points I mentioned, there isn't really that
> much of an itch to scratch.

I think that separation of Parser as a module should be done sooner or
later. In many applications you do not need the rest, why should it be
bundled? Moreover, I do not think that this separation *requires* much
of interface change (BTW: OpenC++ interface is a subjest for another
story).

> > BTW: Over a year ago there was a resolution on this forum to factor out the
> > Driver subsystem and make it a shell script (for easier maintenance
> > and to make underlying compiler/preproc/linker settable with Autoconf).
>
> I don't really care about the driver, but I don't understand how
> completely replacing a perfectly-well-working part makes anything more
> maintainable.

It is not working perfectly, see e.g. my problems with running regression
on gcc-3.2, originating from the fact that underlying compiler is
hardcoded and selected with system-specific defines. We hit this problem
a year ago, when Pavel Krusina was working on Irix port.

Another issue are shared libraries, which are currently not trurly
supported. libtool has all we need to make shared or dlopenable library,
while at the same time driver.cc/driver2.cc duplicates this functionality,
and is far less perfect than libtool (the fact is it was created much
earlier than libtool).

> It certainly is no problem to make the underlying tools
> configurable for the existing C++ driver, is it?

It is possible, but it is more work than it is worth (especially for
shared libs).

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