Thread: [ccmtools-devel] Re: owudb example and cpp

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Word. This is a confix/ccmtools issue so I'm posting to both development
lists.

A brief foreword is that we're moving the CCM Tools to use CPP (the C
PreProcessor) to handle things like include files (a nassssty problem,
indeed). So the theory is that you'd run something like

  ccmtools-generate <language> -I. -Iinclude_dir -I/usr/local/include_dir my_file.idl

to generate components from all the IDL declarations in my_file.idl *and
all included files*.

This seems to be the only clean way to handle includes. It also has the
benefits of (a) being able to use all the functionality of CPP (e.g. ifdef
and define and such in source IDL files), and (b) cleaning up the CCM Tools
code by delegating preprocessing to another, more stable, tool.

But on with the problems ...

On Mon, 28 Apr 2003, Egon Teiniker wrote:

> Hey Leif!
> 
> I tryed to run the owudb example
> owudb/
>  dbsql/
>  |-- login_dbsql.idl
>  |-- user_dbsql.idl
>  ifaces/
>  |-- auth.idl
>  |-- exc.idl
>  |-- ldbbrowser.idl
>  |-- logindata.idl
>  |-- logindatalist.idl
>  |-- loginmgr.idl
>  |-- persdata.idl
>  |-- udbbrowser.idl
> using the cpp tool in different ways:
> 
> a) cpp creates one IDL file per component and each component is build in a
> separate package:
>   > cpp -P -I /home/eteinik/src/ccmtools/owudb/cpp dbsql/user_dbsql.idl userdb.idl
>   > cpp -P -I /home/eteinik/src/ccmtools/owudb/cpp dbsql/login_dbsql.idl login.idl
>   > ccmtools-c++-generate -p userdb userdb.idl
>   > ccmtools-c++-generate -p login login.idl
>   > ccmtools-c++-make -p userdb
>   > ccmtools-c++-make -p login
>   > ccmtools-c++-install -p userdb
>   > ccmtools-c++-install -p login
>   This is working until I tryed to compile a test client. Confix stopped with:
>     Both module login.CCM_Local (prio 0) and module userdb.CCM_Local (prio 0)
>      resolve #include<CCM_Local/UserPassAuthentication.h>
>      (from [['UserDB_DBSQL_gen.h']])

Right. From my point of view, this is a Confix issue : Confix complains
here because there are two different modules (login and user) that provide
the UserPassAuthentication (UPA) interface.

On the CCM Tools side, both modules provide this header file because both
of the source IDL files contain components that use the UPA interface. Thus
the header file for the UPA interface is generated, compiled, and installed
with each component (otherwise standalone components could not be installed
at all). The CCM Tools have no way of knowing which interfaces are already
installed on a system : that's Confix's responsibility.

I think Confix should be changed to just go ahead and pick one of the two
libraries here. (But maybe only if the --advanced option is specified ?)

My reasoning : If the includes are named the same thing, it seems like a
programmer error if they actually refer to separate implementations. The
interface definitions should be put in separate namespaces if there are two
different interfaces with the same name (having same-name anythings is just
a bad idea anyway ; I think formal namespaces were invented by lazy
programmers).

I just thought of an alternative. If there was a way in Confix to give
installed modules higher priority than local modules for a particular
source directory or package, we could say that installed interfaces should
be included preferentially over locally generated interfaces. So an
installed component that provided the UPA interface header, for example,
would be used to compile a new component that needed that interface, even
if the same interface header was in the generated source package. Hope that
makes sense.

Now that I think of it, did you try the generation process below ? Maybe
fully installing a component will allow the second component to use the
first one's library / headers ? Confix --bootstrap is called as a part of
the -generate script, so dependencies are resolved before the -make script
is called. Maybe that's a bad idea ...

  ccmtools-c++-generate -p userdb userdb.idl
  ccmtools-c++-make -p userdb
  ccmtools-c++-install -p userdb
  ccmtools-c++-generate -p login login.idl
  ccmtools-c++-make -p login
  ccmtools-c++-install -p login

> b) cpp creates one IDL file per component and the components are build in
>    the same package:
>   > cpp -P -I /home/eteinik/src/ccmtools/owudb/cpp dbsql/user_dbsql.idl userdb.idl
>   > cpp -P -I /home/eteinik/src/ccmtools/owudb/cpp dbsql/login_dbsql.idl login.idl
>   > ccmtools-c++-generate -p xxx *.idl
>   > ccmtools-c++-make -p xxx
>   This does not work:
>   =>./CCM_Local/include/CCM_Local/userdb_user_types.h:23:
>        redefinition of `struct CCM_Local::PersData'
>     ../CCM_Local/include/CCM_Local/login_user_types.h:39:
>        previous definition here
>     ../CCM_Local/include/CCM_Local/userdb_user_types.h:40:
>        redefinition of `class CCM_Local::NoSuchUser'
>     ../CCM_Local/include/CCM_Local/login_user_types.h:60:
>        previous definition here
>     ../CCM_Local/include/CCM_Local/userdb_user_types.h:40:
>        confused by earlier errors, bailing out
>    The problem is that the types are generated for every components.

Hmm. Not sure what to do about this. We might just want to say that this
development method is discouraged. :-/

> c) I created one IDL file that includes all components used in an assembly:
>   /***
>    * owudb.idl
>    */
>   #include "dbsql/login_dbsql.idl"
>   #include "dbsql/user_dbsql.idl"
>   Now, I build the owudb.idl file ...
>   > cpp -P -I /home/eteinik/src/ccmtools/owudb/cpp owudb.idl test.idl
>   > ccmtools-c++-generate -p test test.idl
>   > ccmtools-c++-make -p test
>   > ccmtools-c++-install -p test
>   This solution also works with the test client.

That's excellent. This might be a good "best practice" development
methodology, but we'll still eventually need to support deployment of
individual components.

> Summary: I think, we can live with (c) for the pilot project. For the
> long term, I have to make (a) work because of the flexibility of
> distributed component development.

I definitely agree. Again, I think this is a Confix-solvable problem (just
need to put a bit more voodoo in Confix).

leif

--
Leif Morgan Johnson . http://ambient.2y.net/leif/
IAESTE trainee      . http://www.iaeste.org/
Salomon Automation  . http://www.salomon.at/