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

[Joerg F. <jf...@ao...>]

>>>>> "Leif" == Leif Johnson <le...@am...> writes:

Leif> But on with the problems ...

Leif> 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']])

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

Rightfully (of course :-). At the time Confix barfs about a duplicate
provide the unwanted has already happened: one package has overwritten
another's include file. Whether the involved include files are
identical (because generated) or not is not in the scope of Confix.

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

It is as you say: both components *use* the UPA interfaces, in that
they *include* the interface's IDL. I don't see why this should make
them *define* (generate) that interface.

What we need is a way to resolve IDL dependencies just as we resolve
C/C++ dependencies. At least, when the IDL compiler runs, we need to
pass it the include path to the installed IDL file that is being
*used*.

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

Yeah, randomly, no doubt.

Leif> My reasoning : If the includes are named the same thing, it seems like a
Leif> programmer error if they actually refer to separate implementations.

That's what I say.

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

Sure this is possible. Still, I think we should solve the root of the
problem rather than tackle its symptoms. The UPA interface is defined
at some place, without knowledge of it being implemented by a
component. It could just as well be implemented by a traditional CORBA
server (a facet is a plain CORBA 2 interface, after all), and the
person who defines that interface just doesn't care about how many
times it is implemented.

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

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

Me too, except for what I said above. (There's already quite a bit of
voodoo in Confix that makes me search for pragmatic solutions.)

Joerg