[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [certi-dev] IEEE1516 includes
From: |
Eric Noulard |
Subject: |
Re: [certi-dev] IEEE1516 includes |
Date: |
Wed, 8 Oct 2008 10:54:32 +0200 |
2008/10/8 Gotthard, Petr <address@hidden>:
>> 2008/9/30 Eric Noulard <address@hidden>:
>>
>> I've just commited the update.
>> Beside that, in the current CVS there is only "headers" and
>> not code implementing it, now we have a target for the "librti1516"
>>
>
> Eric,
> did we discuss guidelines for the "dual" CERTI operation? (I remember
> some discission, but cannot find the results.)
Not finished yuo are right, let's continue :=)
> There are functions that
> (a) have the same behaviour in 1.3 and 1516,
> (b) have the same name, but different arguments and/or behaviour (e.g.
> the attribute handling)
> (c) are completely different (e.g. regions, ticks)
>
> What do you think is the best solution to support both? A preprocessor
> option (e.g. BUILD_HLA1516, BUILD_HLA13)? Separate source code? A
> runtime configuration option?
I think that since RTI library do have separate names
libRTI for 1.3
librti1516 for 1516
We should be able to build both libraries with appropriate behavior
for each one.
Concerning the source code layout I think we should
1) try to keep the same source files with added
#ifdef HLA1516
#endif
or
#ifdef HLA1_3
#endif
if it leads to bloated #if code then put specific code
in specific [separated] source files.
2) In the CMakeLists.txt we should be able to build the differents libs
with different FLAGS using possibly _the same files_
ADD_LIBRARY(RTI RTIambassador.c rti13_specific.c)
SET_TARGET_PROPERTIES(RTI PROPERTIES COMPILE_FLAGS -DHLA1_3)
ADD_LIBRARY(rti1516 RTIambassador.c rti1516_specific.c)
SET_TARGET_PROPERTIES(RTI PROPERTIES COMPILE_FLAGS -DHLA1516
Thus with this scheme (to be tested) we should be able to build both
HLA1.3 and IEEE-1516 libs.
3) The user (the one who write Federate)
must not be forced to use -DHLA1516 or -DHLA1_3.
He will select its binding using the appropriate headers and lib name
which are _separate_
This means that we must not put ANY #ifdef HLAxx inside public header
but only in certi internal headers or source files.
Does this scheme seems reasonable for you?
--
Erk