certi-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [certi-dev] Shall CERTI use libRTI-NG and libFedTime?


From: Eric Noulard
Subject: Re: [certi-dev] Shall CERTI use libRTI-NG and libFedTime?
Date: Mon, 17 Nov 2008 15:27:35 +0100

2008/11/17 Pierre Siron <address@hidden>:
> Gotthard, Petr a écrit :
>> Dear CERTI friends,
>> I'd like to modify the CERTI libraries to be more "standard".
>> Unfortunatelly, this change may require you to slightly modify Makefiles
>> of your federates.
>>
>> The problem is that linking a federate with CERTI requires "-lRTI
>> -lCERTI", while other HLA RTI often use "-lRTI-NG -lFedTime".
>>
>> It's thus much harder to create a "universal" Makefile that easily links
>> a federate with CERTI or other HLA RTI. The biggest problem is that the
>> proprietary libCERTI contains symbols that should be in libRTI-NG
>> (RTI::xxxSetFactory, RTI::Exception) and symbols that should be in
>> libFedTime (FedTime).
>>
>> Therefore I propose to
>>  - move all RTI:: namespace symbols from libCERTI to libRTI
>>  - move FedTime from libCERTI to (newly created) libFedTime
>>  - rename libRTI to libRTI-NG
>>
>> When doing so
>>  - CERTI will become more compatible with other HLA RTI
>>  - you may need to replace "-lRTI -lCERTI" in your Makefiles by
>> "-lRTI-NG -lFedTime" (if you don't use FindCERTI)

In order to make the transition easier for user we can
maintain the current libCERTI ( for 1 up to 3 releases) and

- create a new libRTIG-NG with appropriate symbol in it
- create libFedTime
- create libCERTI-13 which is libCERTI without fedtime and RTI:: symbols
  (we will have libCERTI-1516 when the work will begin)
  libCERTI-13 and libCERTI-1516 may be the same lib or not depending
  on implementation issue.

- update FindRTI such that it would generate the proper
   -lRTI-NG -lFedTime for new CERTI release
  and keep it generate -lCERTI if older CERTI release is found
  may be with a "MESSAGE(STATUS" telling that the user should upgrade
  to an newer CERTI release.

an older federate may continue to link to libCERTI but should update to
the new names libRTI-NG libFedTime (or should use FindRTI).

>>
>> Would this change be very annoying for you?
>>
> Dear Petr,
> this change would not be very annoying,
> I am concerned by the perennity of the RTI-NG name
> which is a reference to the last RTI of the DMSO.

RTI-NG is the common used name precisely because of the DMSO
historical RTI.
see http://lists.nongnu.org/archive/html/certi-devel/2008-10/msg00001.html.
This is not the DLC HLA 1.3 name which is librti13, but there doesn't seem
to be much support for this name.

When evolving towards to IEEE-1516 support
we will create a 1516 SISO DLC conforming name

librti1516.so (unix)
librti1516.dll (windows)

which seems to be more widespread.

> Is is possible to have many synonyms ?

I don't think there is a portable way to have synonyms libraries
(symlink are not supported on Windows)
but I think we may (optionally) build the library twice, which would
be 2
add_library lines in the CMakeLists.txt
instead of one with some extra build time.

> The move of FedTime is justified, in particular if we consider
> that this library may be provided by the user ...

I agree with this.
We should create the libFedTime

> I am not sure that we are ready to accept that.

You mean we did never tried to use a user-defined libFedTime with CERTI,
so we don't know if ever it would work.

I think we may first create the libFedTime and then we will see if we
are facing bugs when using user-provided lib.


-- 
Erk




reply via email to

[Prev in Thread] Current Thread [Next in Thread]