Wed 26 Nov 2008 08:24:58 AM UTC, comment #13:
Hi Petr,
Never mind.
I didn't remember if we already discussed
our bug processing way so I take the message
as an occasion.
Sorry about that if you already know :=)
|
Wed 26 Nov 2008 08:20:01 AM UTC, comment #12:
Well, you should "keep bug open" read as "keep bug in progress". I didn't mean to literally "close" the bug. I just wrote it in that way.
|
Tue 25 Nov 2008 06:11:51 PM UTC, comment #11:
Ok fine.
However concerning,
> I'll keep this bug open until I verify the CERTI build under Windows ...
Just a reminder:
A bug should remain Open until it
has been included in a CERTI Release.
However it should go from Status::In Progress to
Status::Fixed or Status::Ready For Test as soon
as you think it is in CVS and precisely "Ready For Test".
When I release CERTI I do check all
Open & Fixed or Open & Ready For Test bugs and close
them if I'm confident they are included in the release
at the same time I set the "Fixed Release" to the appropriate
value.
The whole process is loosely described here:
http://cvs.savannah.gnu.org/viewvc/certi/ReleaseProcess.txt?root=certi&view=markup
|
Tue 25 Nov 2008 05:06:44 PM UTC, comment #10:
Patch applied, however I'll keep this bug open until I verify the CERTI build under Windows and try dynamic-link compatibility with MAK RTI.
|
Mon 24 Nov 2008 11:53:21 AM UTC, comment #9:
Ok with your patch.
Ga ahead apply it.
|
Sat 22 Nov 2008 03:47:30 PM UTC, comment #8:
Attached a patch and a new libRTI file that
- change the libRTI to libRTI-NG
- create libFedTime
- move RTI symbols to libRTI
I prefer to not create any backward-compatibility libraries because it may cause unnecessary troubles when linking wrong libraries together.
(file #16898, file #16899)
|
Sat 15 Nov 2008 05:35:16 PM UTC, comment #7:
The HLA 1.3 DLC uses librti13 and libfedtime13. In a first step I propose to modify the libRTI(-NG?) and create a libFedTime.
(1)
I checked the libCERTI and only the following files need to be modified:
- The RTI::xxx functions in libCERTI/GAV_aux.cc should be moved to a libRTI/RTItypes.cc
- The RTI::xxx definitions in libCERTI/Exception.cc should be moved to libRTI/RTItypes.cc (yes, the same)
By doing this, all certi:: excepptions defined in libCERTI/Exception.hh will be implemented in libCERTI/Exception.cc and all RTI:: types defined in include/RTItypes.hh will be implemented in libRTI/RTItypes.cc. (I considered making libRTI/Exceptions.cc, but this seems to me more consistent.)
(2)
Then I propose to modify libCERTI/CMakeLists.txt, create there the libFedTime target a link there everything in FedTime.cc. The FedTime.cc may stay in libCERTI. (Or should it be moved to libRTI? Or to libFedTime? I think that moving it to libFedTime is not necessary.)
This should solve this bug report. As a next step, full DLC compliancy may be introduced, but this will require additional changes.
|
Sat 15 Nov 2008 12:07:24 PM UTC, comment #6:
We should add libFedTime
in order to be HLA 1.3 DLC compliant.
It would "only" break CERTI-specific federate
which should not be an issue, but it worth a poll on
certi-devel.
What would you propose?
(I won't be much responsive this Week-End,
next week will be better)
|
Sat 15 Nov 2008 10:14:11 AM UTC, comment #5:
Update:
Works well under Linux: Only libRTI needs to be linked (libFedTime is missing, but FindRTI handles that).
Under (my installation of) Windows both libRTI and libCERTI need to be included. The FindRTI therefore doesn't properly work with CERTI under Windows (the DLC compliancy is broken).
My Visual Studio says that the following should be moved to libRTI
- RTI::Exception and its children
- RTI::xxxxSetFactory::create()
- RTIfedTime
Well, preferrably the RTIfedTime() should go to libFedTime, but this would break build of all existing CERTI federates.
|
Thu 10 Apr 2008 09:07:10 AM UTC, comment #4:
Thank you.
Just for the record: The problem reported in this report is valid also for the cmake, but I'm unnable to create the patch (yet).
The X11 related problem is reported as bug #22890.
Enjoy your holidays.
|
Wed 09 Apr 2008 06:22:01 PM UTC, comment #3:
OK I see,
It should work,
However, most of our machine do have X :-(
Could you open a specific bug for this
telling us more about the configuration
(Linux flavor, SOlaris etc...)
I will fix this.
In the meantime you may set
FORCE_NO_X11 using either
cmake -DFORCE_NO_X11=ON
or
using ccmake.
|
Wed 09 Apr 2008 04:33:23 PM UTC, comment #2:
Regarding cmake:
Seems that cmake does not set X_DISPLAY_MISSING. I have troubles building the examples when using cmake.
|
Wed 09 Apr 2008 04:00:34 PM UTC, comment #1:
Hi Petr,
Thank you for another patch.
I'll give it a look in a week or two since holidays
are coming for me.
From your patch I see you may be using autotools
to build CERTI.
We try to switch to CMake as build system
since we want CERTI to compile easily on Windows
and autotools are just painful beside cygwin.
There is a note on CERTI on Windows build with CMake:
http://download.savannah.gnu.org/releases/certi/documentation/CERTI%20eng%20doc2.0.pdf
The CMake-based certi build system is currently operational
on Linux/Solaris/Windows so
that I would advise you to give it a try since we may
drop autotools usage sooner or later.
|
Wed 09 Apr 2008 03:38:13 PM UTC, original submission:
An application must be linked with CERTI using
-lRTI -lCERTI -lxml
However, it should be independent on used RTI, so "-lCERTI" should not be used if no CERTI extensions are used.
For example, the MAK RTI can be linked using
-lRTI-NG -lFedTime
I suggest to create standalone libRTI, so -lCERTI and -lxml is not needed (when not using CERTI extensions). This is a "safe", backwards compatible change.
Additionaly, the -lFedTime library can be created, however this change might require changes to all simulations using CERTI.
See the attached patch.
|