|
From: Joerg F. <jf...@ao...> - 2003-04-29 07:31:31
|
>>>>> "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 |