RE: [certi-dev] IEEE1516 includes

[Gotthard, Petr]

I completely share your opinion.

And how about RTIA/RTIG? The MAK RTI has a separate RTIexec and
RTIexec1516, but I think we might get some benefit if we keep a single
(universal) RTIA and RTIG. (If possible, of course.)

Petr

-----Original Message-----
From: address@hidden
[mailto:address@hidden On
Behalf Of Eric Noulard
Sent: Wednesday, October 08, 2008 10:55 AM
To: CERTI development discussions
Subject: Re: [certi-dev] IEEE1516 includes

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


-- 
CERTI-Devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/certi-devel