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

[Michael H. <ho...@sa...>]

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

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

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

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.

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.

> 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 certainly is no problem to make the underlying tools
configurable for the existing C++ driver, is it?

Kind regards,
Michael
-- 
ho...@sa..., ho...@in...
http://home.pages.de/~hohmuth/