From: Jens Thiele <jens.thiele@intra2net.com>
Date: Mon, 18 Dec 2006 16:16:02 +0000 (+0000)
Subject: docu updates
X-Git-Tag: v0.2~21
X-Git-Url: http://developer.intra2net.com/git/?p=libt2n;a=commitdiff_plain;h=7781f1c4d69c5be72d5cc98bf34d0b5ccf1f372e;hp=b35406feb0d11c6022c58ae485e9864641b7ff9c

docu updates
---

diff --git a/codegen/README b/codegen/README
index 3156fca..5c05067 100644
--- a/codegen/README
+++ b/codegen/README
@@ -2,3 +2,16 @@ code generator using gccxml and libxml++
 
 for example usage take a look at the libt2n-example package
 
+design decisions:
+
+installation of codegen-stubhead.hxx:
+codegen-stubhead.hxx is installed because the generated includes depend on the libt2n headers anyway
+
+make file snippet moved into libt2n-example1 and must be copied manually:
+automake is run first (before configure) and needs the makefile snippet => no way to let configure
+find the makefile snippet
+
+examples in separate packages:
+- this was done to be able to test that installation and configure scripts work as intended
+- there are two examples because one is used to generate the usage example documentation using doxygen
+  and one is used for automatic testing
diff --git a/codegen/TODO b/codegen/TODO
index 601a5a0..d90cf65 100644
--- a/codegen/TODO
+++ b/codegen/TODO
@@ -1,30 +1,9 @@
 - remove support for LIBT2N_EXPORT_GROUP(group) (this will simplify the generator a lot)
 - add option similar to gccs -MD (at the moment it is a fixed set of files generated and
   they are handled in the makefile snippet [codegen.make])
-
-open questions:
-- should projects using the codegen depend on installed version of ... or ship their own version?
-- get rid of codegen-stubhead.hxx or include a "copy" in each project?
-  first we said yes but now i say no because the lib depends on the libt2n headers anyway
-- makefile snippet must work for builds outside of libt2n
-  => some variables must be set by configure
-  the variables which must be set:
-	LIBT2N_CODEGEN="\$(top_builddir)/codegen/libt2n-codegen"
-	LIBT2N_CLIENT_PCTEMPLATE="\$(top_srcdir)/codegen/clientlib.pc.in"
-  => we store the variables in the .pc file of libt2n
 - it would really be much nicer if the client lib includes would not depend upon boost serialization
   i thought a solution would be to provide this optionally by wrapping the corresponding includes in a #ifdef
   but this does not work since command.hxx is included which depends on boost serialization headers anyway
   => we do not provide this for now
 - naming scheme?!
   perhaps generated group class should not be prefixed by cmd_group_
-
-docu
-- for the docu we need a minimal example
-- for automatic testing we need a complex example
-
-the example should show:
-- how to mark procedures
-- how to write configure.ac and Makefile.am
-- that we create a library for the client
-- how to use that library
diff --git a/src/t2n_exception.hxx b/src/t2n_exception.hxx
index 4ce11aa..14243fc 100644
--- a/src/t2n_exception.hxx
+++ b/src/t2n_exception.hxx
@@ -231,6 +231,8 @@ class t2n_serialization_error : public t2n_exception
 
 /** @brief a runtime error within the remote function.
  derive your own custom exceptions from this one
+
+ @note you must override the virtual clone method if you do (used by \ref command_server::handle_packet)
 */
 class t2n_runtime_error : public t2n_exception
 {