Thanks Alan,
I think I'll stay as close to the rubygen approach as I can.
-Ted
Alan Conway wrote:
Ted Ross wrote:
Alan,
In order to maintain the qpid broker management schema, we've
established a couple of XML document formats that formally define the
schema (object types, methods/arguments, events, etc.). Note that
these documents are disjoint from, and unrelated to the AMQP
specification document.
All of the broker classes (C++ only for now) that implement the
management schema are generated by a code generation tool. I would
like to begin integrating the management code generation into the C++
broker build and am looking for advice as to how to do it properly.
Here are some points/questions:
1. The schema spec will be changing on a regular basis during
development. This means that the generator must be run at build
time when the xml documents have changed. The generator writes
the output files only if they don't exist or their contents have
changed. This prevents unnecessarily long make runs caused by
"touching" files that aren't changed. The easiest strategy would
be to always run the generator at the beginning of each build (the
generation process takes 21 milliseconds on my ThinkPad).
That sounds good. Rubygen relies on Make to figure this out and isn't
so smart about not updating unchanged files. It probably should be
since presently touching any rubygen template causes a massive recompile.
2. The generator writes both .h and .cpp files. The .h files need to
be available for inclusion from normal broker source files (i.e.
must be in some include path).
3. Where should the generated files be deposited? I assume
cpp/src/gen/qpid/management is the right place.
Yup, there are already -Igen directives in the makefiles so they'll
get picked up. I can't think of any problem sharing gen/ with rubygen,
if there is one we should fix it rather than proliferate directories.
4. Where should the generator go? Should it be considered a peer of
rubygen and placed in cpp/managementgen?
Yup, either that or rename cpp/rubygen as cpp/gen/ruby and add
cpp/gen/management. I don't much care either way.
5. Where are the generator files and templates listed such that they
are properly included in a source distribution?
Currently rubygen is not distributed, instead the files it generates
are, so we don't have a build dependency on ruby. They get distributed
because they are included in the various foo_SOURCES lists in
Makefile.am.
This is somewhat historical - we previously had a Java generator and
Java was a serious problem as a build dependency. ruby probably would
not be such a problem but since we were already set up that way...
If your generator's dependencies are all in RHEL/Fedora and Nuno's
happy with them then you can go either route - distribute generated
source like rubygen, or add your generator to EXTRA_DIST in
cpp/Makefile.am.
With the latter you probably will need to do some different automake
stuff with the generated sources in src/Makefile.am - you'll have to
check that out for yourself. I hate automake and all its autofriends.
6. How is the make file updated to include all of the generated
source code? Should the generator create a makefile fragment to
be included? I can emulate the rubygen example but it's not
obvious to me how it works or which files are truly "source" and
which are generated along the way.
Hah! Took me a long time to get generated makefile fragments working
properly, so copy it exactly or you're on your own ;) All the files
listed are generated from an SVN perspective, but they are source from
the distribution perspective since we dont distribute the generator.
So the approach you take depends on whether or not you decide to
distribute your generator. Probably distributing the generator would
wind up simpler, but it may involve reading the automake info pages
since I haven't done it before.
Cheers,
Alan.
You can either create a regular makefile fragment in SVN and update by
hand or generate one - depends on how easy it is to manually sync.
