Re: [CMake] Contribute two new find package implementation.
Hi,
On Monday 10 October 2011, Michael Hertling wrote:
> AFAICS from Mathias' FindRTI1516{,E}.cmake modules, the libraries have
> different names, but their respective header files are named the same:
>
> FIND_LIBRARY(RTI1516_LIBRARY NAMES rti1516 RTI1516 ...)
> FIND_LIBRARY(RTI1516E_LIBRARY NAMES rti1516e RTI1516E ...)
>
> FIND_PATH(RTI1516_INCLUDE_DIR NAMES RTI/RTI1516.h ...)
> FIND_PATH(RTI1516E_INCLUDE_DIR NAMES RTI/RTI1516.h ...)
Yes.
> Therefore, the usage of both libraries for the same binary should be
> quite possible as long as they don't violate the one-definition-rule,
> whereas the inclusion of both headers for the same compilation unit
> will require some trickery, e.g. an intermediate header containing
> configured #include directives with the other headers' full paths.
Yes.
Having different include paths for different object files would be sufficient
to include all in the same application.
Cmake can do this fine.
Greetings
Mathias
--
Dr. Mathias Fröhlich, science + computing ag, Software Solutions
Hagellocher Weg 71-75, D-72070 Tuebingen, Germany
Phone: +49 7071 9457-268, Fax: +49 7071 9457-511
--
Vorstand/Board of Management:
Dr. Bernd Finkbeiner, Dr. Roland Niemeier,
Dr. Arno Steitz, Dr. Ingrid Zech
Vorsitzender des Aufsichtsrats/
Chairman of the Supervisory Board:
Philippe Miltin
Sitz/Registered Office: Tuebingen
Registergericht/Registration Court: Stuttgart
Registernummer/Commercial Register No.: HRB 382196
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Contribute two new find package implementation.
Hi, On Friday 07 October 2011, Eric Noulard wrote: > Ok I understand. > I'll get in touch with Petr to see if he has time to update its > contribution if he has not I may offer to take over. Ok, So I am around and can respond to questions more or less timely but I am not monitoring the mailing list. > find_package(RTI) >would find all of them 1.3, 1516 and 1516e (which is 1516-2010 right?) >This would define > RTI13_FOUND if 1.3 compliant RTI is found > RTI1516_FOUND if 1516 compliant RTI is found > RTI1516e_FOUND ... > > find_package(RTI COMPONENT RTI1516) > > would only search for 1516. > > find_package(RTI COMPONENT RTI13 RTI1516) > > search for 1.3 and 1516 only etc... Ok, thats fine then. > Like I said I will contact Petr directly and ask him whether if he wants > to continue to maintain the CMake FindRTI.cmake, if not I'll take over > and import your work + the CERTI modification and propose a unified > version for CMake. So you are incorporating the contributed files into FindRTI then? Or do I need to take some actions? Greetings Mathias -- Dr. Mathias Fröhlich, science + computing ag, Software Solutions Hagellocher Weg 71-75, D-72070 Tuebingen, Germany Phone: +49 7071 9457-268, Fax: +49 7071 9457-511 -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Philippe Miltin Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Contribute two new find package implementation.
On 10/09/2011 06:54 PM, Eric Noulard wrote:
> Argh... forgot the list
>
>
> -- Forwarded message --
> From: Eric Noulard
> Date: 2011/10/9
> Subject: Re: [CMake] Contribute two new find package implementation.
> To: Michael Hertling
>
>
> 2011/10/9 Michael Hertling :
>> On 10/07/2011 07:06 PM, Eric Noulard wrote:
>>> 2011/10/7 Mathias Fröhlich :
>>>> On Friday 07 October 2011, Eric Noulard wrote:
>>
>>>>> Concerning 1516 and 1516e specific module may be it would be interesting
>>>>> to only have one module "FindRTI.cmake" .
>>>> Sure this is there and finds the rti13 libs.
>>>>
>>>>> I think we cannot really use the VERSION argument of find_package
>>>>> but may be
>>>>>
>>>>> find_package(RTI COMPONENTS HLA13 IEEE1516)
>>>>> would be nice?
>>>> Hmm, I have done seperate versions because I was willing to find all three
>>>> variants of rti libs. That means if all three are installed I would like to
>>>> find all of them and have them all available within the same applications
>>>> build system.
>>>
>>> Yes.
>>>
>>> find_package(RTI)
>>>would find all of them 1.3, 1516 and 1516e (which is 1516-2010 right?)
>>>This would define
>>> RTI13_FOUND if 1.3 compliant RTI is found
>>> RTI1516_FOUND if 1516 compliant RTI is found
>>> RTI1516e_FOUND ...
>>
>> Due to [1], the variables should ne named RTI_RTI{13,1516{,e}}_FOUND,
>> i.e. __FOUND. However, there might be a problem
>> with the RTI_FOUND variable regarding backwards compatibility: Since
>> FIND_PACKAGE(RTI) - without specification of any components - should
>> behave the same with the current single-component FindRTI.cmake as
>> well as with a future multi-component one, RTI_FOUND must be FALSE
>> even if a 1516 implementation is detected, i.e. RTI_FOUND does not
>> indicate an 1516 package's presence if FIND_PACKAGE(RTI) is invoked
>> without components. This might be surprising at first glance, but is
>> a particular problem when a single-component find module is advanced
>> towards multiple components. A possible conceptual solution could be:
>>
>> - FIND_PACKAGE(RTI ...) must never run into config mode so that the
>> FindRTI.cmake module retains control of the RTI_FOUND variable; a
>> config file would mean that RTI_FOUND is forcedly set to TRUE.
>> Since the diverse RTI packages stem from different projects,
>> this should be well feasible.
>> - Calling FIND_PACKAGE(RTI) without components mimics the current
>> behavior, i.e. only a 1.3 package is searched, the variables are
>> set up like the single-component FindRTI.cmake does it now, and
>> RTI_FOUND just indicates the presence of a 1.3 package even if
>> a 1516 package is available on the system.
>> - Calling FIND_PACKAGE(RTI COMPONENTS HLA13) basically does the same,
>> but behaves as expected for a component-aware find module, i.e. it
>> also looks for a 1.3 package only, but sets up the variables right
>> in a multi-component manner: RTI_HLA13_{FOUND,LIBRARY,INCLUDE_DIR}.
>> RTI_FOUND indicates whether anything about RTI has been detected;
>> actually, this merely means that the component-specific *_*_FOUND
>> variables have received defined values, possibly even limited to
>> the components explicitly requested via the FIND_PACKAGE() call.
>>
>> Anyway, a multi-component FindRTI.cmake is the way to go, IMO, and
>> should be strongly preferred to the addition of any further find
>> modules which are closely related and differ just slightly.an
>
> Hi Michael,
>
> Thank you for this thorough explanation as usual.
> I'll try to stick to the referenced Module coding guidelines you've just
> described.
>
>>>> Is this possible to implement this within a single find_package call?
>>>
>>> This is possible as long as the resulting variables are separate.
>>> (in our case there is some RTIxxx prefix)
>>
>> Note that there may be difficiulties w.r.t. possible prerequisites in
>> this way: The *_*_{LIBRARY,INCLUDE_DIR} variables contain information
>> about the related component only, i.e. without prerequisite libraries
>> and include directories. The full information is provided by the non-
>> cached component-unspecific *_{LIBRARIES,INCLUDE_DIRS} variables, i.e.
>>
>> FIND_PACKAGE(RTI COMPONENTS HLA13 RTI1516 RTI1516E)
>>
>> would return RTI_{LIBRARIES,INCLUDE_DIRS} suitab
[CMake] Contribute two new find package implementation.
Argh... forgot the list
-- Forwarded message --
From: Eric Noulard
Date: 2011/10/9
Subject: Re: [CMake] Contribute two new find package implementation.
To: Michael Hertling
2011/10/9 Michael Hertling :
> On 10/07/2011 07:06 PM, Eric Noulard wrote:
>> 2011/10/7 Mathias Fröhlich :
>>> On Friday 07 October 2011, Eric Noulard wrote:
>
>>>> Concerning 1516 and 1516e specific module may be it would be interesting
>>>> to only have one module "FindRTI.cmake" .
>>> Sure this is there and finds the rti13 libs.
>>>
>>>> I think we cannot really use the VERSION argument of find_package
>>>> but may be
>>>>
>>>> find_package(RTI COMPONENTS HLA13 IEEE1516)
>>>> would be nice?
>>> Hmm, I have done seperate versions because I was willing to find all three
>>> variants of rti libs. That means if all three are installed I would like to
>>> find all of them and have them all available within the same applications
>>> build system.
>>
>> Yes.
>>
>> find_package(RTI)
>> would find all of them 1.3, 1516 and 1516e (which is 1516-2010 right?)
>> This would define
>> RTI13_FOUND if 1.3 compliant RTI is found
>> RTI1516_FOUND if 1516 compliant RTI is found
>> RTI1516e_FOUND ...
>
> Due to [1], the variables should ne named RTI_RTI{13,1516{,e}}_FOUND,
> i.e. __FOUND. However, there might be a problem
> with the RTI_FOUND variable regarding backwards compatibility: Since
> FIND_PACKAGE(RTI) - without specification of any components - should
> behave the same with the current single-component FindRTI.cmake as
> well as with a future multi-component one, RTI_FOUND must be FALSE
> even if a 1516 implementation is detected, i.e. RTI_FOUND does not
> indicate an 1516 package's presence if FIND_PACKAGE(RTI) is invoked
> without components. This might be surprising at first glance, but is
> a particular problem when a single-component find module is advanced
> towards multiple components. A possible conceptual solution could be:
>
> - FIND_PACKAGE(RTI ...) must never run into config mode so that the
> FindRTI.cmake module retains control of the RTI_FOUND variable; a
> config file would mean that RTI_FOUND is forcedly set to TRUE.
> Since the diverse RTI packages stem from different projects,
> this should be well feasible.
> - Calling FIND_PACKAGE(RTI) without components mimics the current
> behavior, i.e. only a 1.3 package is searched, the variables are
> set up like the single-component FindRTI.cmake does it now, and
> RTI_FOUND just indicates the presence of a 1.3 package even if
> a 1516 package is available on the system.
> - Calling FIND_PACKAGE(RTI COMPONENTS HLA13) basically does the same,
> but behaves as expected for a component-aware find module, i.e. it
> also looks for a 1.3 package only, but sets up the variables right
> in a multi-component manner: RTI_HLA13_{FOUND,LIBRARY,INCLUDE_DIR}.
> RTI_FOUND indicates whether anything about RTI has been detected;
> actually, this merely means that the component-specific *_*_FOUND
> variables have received defined values, possibly even limited to
> the components explicitly requested via the FIND_PACKAGE() call.
>
> Anyway, a multi-component FindRTI.cmake is the way to go, IMO, and
> should be strongly preferred to the addition of any further find
> modules which are closely related and differ just slightly.an
Hi Michael,
Thank you for this thorough explanation as usual.
I'll try to stick to the referenced Module coding guidelines you've just
described.
>>> Is this possible to implement this within a single find_package call?
>>
>> This is possible as long as the resulting variables are separate.
>> (in our case there is some RTIxxx prefix)
>
> Note that there may be difficiulties w.r.t. possible prerequisites in
> this way: The *_*_{LIBRARY,INCLUDE_DIR} variables contain information
> about the related component only, i.e. without prerequisite libraries
> and include directories. The full information is provided by the non-
> cached component-unspecific *_{LIBRARIES,INCLUDE_DIRS} variables, i.e.
>
> FIND_PACKAGE(RTI COMPONENTS HLA13 RTI1516 RTI1516E)
>
> would return RTI_{LIBRARIES,INCLUDE_DIRS} suitable to use the HLA13
> and RTI1516 and RTI1516E components in the same target,
This requirement is problematic because RTI1516 and RTI1516E
do have the same library names (but not the same path of course).
> whereas the
> RTI_*_{LIBRARY,INCLUDE_DIR} variables don't comprise the respective
> component's possible prerequisites.
Why wouldn't they?
FIND_PACKAGE(RTI COMPONENTS HLA13 RTI151
Re: [CMake] Contribute two new find package implementation.
2011/10/9 Alexander Neundorf : > On Friday 07 October 2011, Mathias Fröhlich wrote: >> Hi, >> >> I have done and would like to contribute two new find package >> implementations. These are both IEEE standardized successors rti1516 and >> rti1516e of the RTI libraries where cmake already has the predecessor >> library find package implementation with FindRTI.cmake. >> >> Attached are the initial versions of FindRTI1516.cmake and >> FindRTI1516E.cmake. Is it possible to include these or improoved versions >> into the standard distribution? >> Please review and may be apply. > > Don't know much (i.e. only 2 minutes of googling) about RTI, and I didn't > really find a homepage. RTI = Run Time Infrastructure http://en.wikipedia.org/wiki/Run-Time_Infrastructure_%28simulation%29 > Are the RTI libs built themselves with cmake ? As you surely understood from the previous ref. RTI is a generic term like "CORBA" at least one RTI implementation is built with CMake CERTI: https://savannah.nongnu.org/projects/certi but for the commercial ones mainly Pitch and Mäk I don't know. > If so, maybe find-packages are not needed, but instead they should install > Config.cmake files ? Clearly on my TODO list for CERTI but this only solve a part of the problem because one should be able to built an RTI-based application which is "implementation agnostic". So better use something like FindRTI.cmake for building this kind of application (my opinion though). -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Contribute two new find package implementation.
On Friday 07 October 2011, Mathias Fröhlich wrote: > Hi, > > I have done and would like to contribute two new find package > implementations. These are both IEEE standardized successors rti1516 and > rti1516e of the RTI libraries where cmake already has the predecessor > library find package implementation with FindRTI.cmake. > > Attached are the initial versions of FindRTI1516.cmake and > FindRTI1516E.cmake. Is it possible to include these or improoved versions > into the standard distribution? > Please review and may be apply. Don't know much (i.e. only 2 minutes of googling) about RTI, and I didn't really find a homepage. Are the RTI libs built themselves with cmake ? If so, maybe find-packages are not needed, but instead they should install Config.cmake files ? Are you contributing to the libraries ? Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Contribute two new find package implementation.
On 10/07/2011 07:06 PM, Eric Noulard wrote:
> 2011/10/7 Mathias Fröhlich :
>> On Friday 07 October 2011, Eric Noulard wrote:
>>> Concerning 1516 and 1516e specific module may be it would be interesting
>>> to only have one module "FindRTI.cmake" .
>> Sure this is there and finds the rti13 libs.
>>
>>> I think we cannot really use the VERSION argument of find_package
>>> but may be
>>>
>>> find_package(RTI COMPONENTS HLA13 IEEE1516)
>>> would be nice?
>> Hmm, I have done seperate versions because I was willing to find all three
>> variants of rti libs. That means if all three are installed I would like to
>> find all of them and have them all available within the same applications
>> build system.
>
> Yes.
>
> find_package(RTI)
>would find all of them 1.3, 1516 and 1516e (which is 1516-2010 right?)
>This would define
> RTI13_FOUND if 1.3 compliant RTI is found
> RTI1516_FOUND if 1516 compliant RTI is found
> RTI1516e_FOUND ...
Due to [1], the variables should ne named RTI_RTI{13,1516{,e}}_FOUND,
i.e. __FOUND. However, there might be a problem
with the RTI_FOUND variable regarding backwards compatibility: Since
FIND_PACKAGE(RTI) - without specification of any components - should
behave the same with the current single-component FindRTI.cmake as
well as with a future multi-component one, RTI_FOUND must be FALSE
even if a 1516 implementation is detected, i.e. RTI_FOUND does not
indicate an 1516 package's presence if FIND_PACKAGE(RTI) is invoked
without components. This might be surprising at first glance, but is
a particular problem when a single-component find module is advanced
towards multiple components. A possible conceptual solution could be:
- FIND_PACKAGE(RTI ...) must never run into config mode so that the
FindRTI.cmake module retains control of the RTI_FOUND variable; a
config file would mean that RTI_FOUND is forcedly set to TRUE.
Since the diverse RTI packages stem from different projects,
this should be well feasible.
- Calling FIND_PACKAGE(RTI) without components mimics the current
behavior, i.e. only a 1.3 package is searched, the variables are
set up like the single-component FindRTI.cmake does it now, and
RTI_FOUND just indicates the presence of a 1.3 package even if
a 1516 package is available on the system.
- Calling FIND_PACKAGE(RTI COMPONENTS HLA13) basically does the same,
but behaves as expected for a component-aware find module, i.e. it
also looks for a 1.3 package only, but sets up the variables right
in a multi-component manner: RTI_HLA13_{FOUND,LIBRARY,INCLUDE_DIR}.
RTI_FOUND indicates whether anything about RTI has been detected;
actually, this merely means that the component-specific *_*_FOUND
variables have received defined values, possibly even limited to
the components explicitly requested via the FIND_PACKAGE() call.
Anyway, a multi-component FindRTI.cmake is the way to go, IMO, and
should be strongly preferred to the addition of any further find
modules which are closely related and differ just slightly.
> find_package(RTI COMPONENT RTI1516)
>
> would only search for 1516.
>
> find_package(RTI COMPONENT RTI13 RTI1516)
>
> search for 1.3 and 1516 only etc...
>
>> Is this possible to implement this within a single find_package call?
>
> This is possible as long as the resulting variables are separate.
> (in our case there is some RTIxxx prefix)
Note that there may be difficiulties w.r.t. possible prerequisites in
this way: The *_*_{LIBRARY,INCLUDE_DIR} variables contain information
about the related component only, i.e. without prerequisite libraries
and include directories. The full information is provided by the non-
cached component-unspecific *_{LIBRARIES,INCLUDE_DIRS} variables, i.e.
FIND_PACKAGE(RTI COMPONENTS HLA13 RTI1516 RTI1516E)
would return RTI_{LIBRARIES,INCLUDE_DIRS} suitable to use the HLA13
and RTI1516 and RTI1516E components in the same target, whereas the
RTI_*_{LIBRARY,INCLUDE_DIR} variables don't comprise the respective
component's possible prerequisites. Thus, in order to use one of the
required components separately from the others, one can rely neither
on RTI_{LIBRARIES,INCLUDE_DIRS} nor on RTI_*_{LIBRARY,INCLUDE_DIR}.
Instead, one should use multiple FIND_PACKAGE() calls and save
their results immediately:
FIND_PACKAGE(RTI COMPONENTS HLA13)
SET(HLA13_LIBRARIES ${RTI_LIBRARIES})
SET(HLA13_INCLUDE_DIRS ${RTI_INCLUDE_DIRS})
FIND_PACKAGE(RTI COMPONENTS RTI1516)
SET(RTI1516_LIBRARIES ${RTI_LIBRARIES})
SET(RTI1516_INCLUDE_DIRS ${RTI_INCLUDE_DIRS})
FIND_PACKAGE(RTI COMPONENTS RTI1516E)
SET(RTI1516E_LIBRARIES ${RTI_LIBRARIES})
SET(RTI1516E_INCLUDE_DIRS ${RTI_INCLUDE_DIRS})
In other words: A multi-component FIND_PACKAGE() possibly needs to be
called multiple times, each time with the set of components you intend
to use collectively. BTW, this is one of the reasons why I am strongly
in favor of FIND_PACKAGE() not accumulating results, i.e. the results/
effects of a FIND_PACKAGE() call should
Re: [CMake] Contribute two new find package implementation.
2011/10/7 Mathias Fröhlich : > > Hi, > > On Friday 07 October 2011, Eric Noulard wrote: >> Nice to ear from you on CMake ML. >> >> Module contribution process is described here: >> http://www.cmake.org/Wiki/CMake:Module_Maintainers > Puh, ok. > My problem is that I cannot take maintainership in the sense I understand this > job for any few lines of code I am willing to contribute to the public. > I am contributing in *plenty* of projects with at least bug fixes to small > feature enhancements up to huge parts of a project. And this is from my point > of view just a tiny enhancement I would like to share to those people that > would otherwise just have to duplicate already done work. > > I can offer to respond to questions that arise over time. > But Maintainership is something huge ... Ok I understand. I'll get in touch with Petr to see if he has time to update its contribution if he has not I may offer to take over. >> Concerning 1516 and 1516e specific module may be it would be interesting >> to only have one module "FindRTI.cmake" . > Sure this is there and finds the rti13 libs. > >> I think we cannot really use the VERSION argument of find_package >> but may be >> >> find_package(RTI COMPONENTS HLA13 IEEE1516) >> would be nice? > Hmm, I have done seperate versions because I was willing to find all three > variants of rti libs. That means if all three are installed I would like to > find all of them and have them all available within the same applications > build system. Yes. find_package(RTI) would find all of them 1.3, 1516 and 1516e (which is 1516-2010 right?) This would define RTI13_FOUND if 1.3 compliant RTI is found RTI1516_FOUND if 1516 compliant RTI is found RTI1516e_FOUND ... find_package(RTI COMPONENT RTI1516) would only search for 1516. find_package(RTI COMPONENT RTI13 RTI1516) search for 1.3 and 1516 only etc... > Is this possible to implement this within a single find_package call? This is possible as long as the resulting variables are separate. (in our case there is some RTIxxx prefix) [...] > > I am fine with anything that allows me to build an application that uses all > of these libraries at the same time. > ... Think of a bridge that translates from one rti version to an other one. Or > may be an object browser that allows to connect to different rti's. I think I understand the need. > I would also invest some time initially to make this work. But as I sayed, > Maintainership is a huge thing - at least as I understand this. > > So, may be as a first step you will import Petr's current version? Like I said I will contact Petr directly and ask him whether if he wants to continue to maintain the CMake FindRTI.cmake, if not I'll take over and import your work + the CERTI modification and propose a unified version for CMake. >> I'll help to review and test the module (at least on Linux). > Well, the linux part is not the problem for me. This already works. > Windows would be good ... > And may be autodetecting some commercial vendors rti's is something I cannot > test. Same for me :-] I'll ask on CERTI ML for testing when it's done. -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Contribute two new find package implementation.
Hi, On Friday 07 October 2011, Eric Noulard wrote: > Nice to ear from you on CMake ML. > > Module contribution process is described here: > http://www.cmake.org/Wiki/CMake:Module_Maintainers Puh, ok. My problem is that I cannot take maintainership in the sense I understand this job for any few lines of code I am willing to contribute to the public. I am contributing in *plenty* of projects with at least bug fixes to small feature enhancements up to huge parts of a project. And this is from my point of view just a tiny enhancement I would like to share to those people that would otherwise just have to duplicate already done work. I can offer to respond to questions that arise over time. But Maintainership is something huge ... > Concerning 1516 and 1516e specific module may be it would be interesting > to only have one module "FindRTI.cmake" . Sure this is there and finds the rti13 libs. > I think we cannot really use the VERSION argument of find_package > but may be > > find_package(RTI COMPONENTS HLA13 IEEE1516) > would be nice? Hmm, I have done seperate versions because I was willing to find all three variants of rti libs. That means if all three are installed I would like to find all of them and have them all available within the same applications build system. Is this possible to implement this within a single find_package call? > The current module maintainer is Petr Gotthard but it seems > like the CMake included module has not been updated recently, > may be he does not have enough time to maintain it any more? > Petr are you listening to CMake ML? > > As a CERTI developer we did have the initial version of FindRTI.cmake from > Petr inside our tree: > http://cvs.savannah.gnu.org/viewvc/certi/scripts/FindRTI.cmake?revision=1.1 >2&root=certi&view=markup > > I had to update this copy in order to include 1516 lib names. > http://cvs.savannah.gnu.org/viewvc/certi/scripts/FindRTI.cmake?revision=1.1 >3&root=certi&view=markup > > I shall have proposed an update to CMake included module as well but I > lack time. > > If you are willing to maintain the FindRTI.cmake shipped with CMake > (if Petr is ok pass on) > may be you can merge the modifications you've just sent and the > one I did for CERTI source tree then follow the Module maintainer process > in order to have a new updated module in the next CMake release. I am fine with anything that allows me to build an application that uses all of these libraries at the same time. ... Think of a bridge that translates from one rti version to an other one. Or may be an object browser that allows to connect to different rti's. I would also invest some time initially to make this work. But as I sayed, Maintainership is a huge thing - at least as I understand this. So, may be as a first step you will import Petr's current version? > I'll help to review and test the module (at least on Linux). Well, the linux part is not the problem for me. This already works. Windows would be good ... And may be autodetecting some commercial vendors rti's is something I cannot test. Greetings Mathias -- Dr. Mathias Fröhlich, science + computing ag, Software Solutions Hagellocher Weg 71-75, D-72070 Tuebingen, Germany Phone: +49 7071 9457-268, Fax: +49 7071 9457-511 -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Philippe Miltin Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Contribute two new find package implementation.
2011/10/7 Mathias Fröhlich : > > Hi, > > I have done and would like to contribute two new find package implementations. > These are both IEEE standardized successors rti1516 and rti1516e of the RTI > libraries where cmake already has the predecessor library find package > implementation with FindRTI.cmake. > > Attached are the initial versions of FindRTI1516.cmake and FindRTI1516E.cmake. > Is it possible to include these or improoved versions into the standard > distribution? Hi Mathias, Nice to ear from you on CMake ML. Module contribution process is described here: http://www.cmake.org/Wiki/CMake:Module_Maintainers Concerning 1516 and 1516e specific module may be it would be interesting to only have one module "FindRTI.cmake" . I think we cannot really use the VERSION argument of find_package but may be find_package(RTI COMPONENTS HLA13 IEEE1516) would be nice? The current module maintainer is Petr Gotthard but it seems like the CMake included module has not been updated recently, may be he does not have enough time to maintain it any more? Petr are you listening to CMake ML? As a CERTI developer we did have the initial version of FindRTI.cmake from Petr inside our tree: http://cvs.savannah.gnu.org/viewvc/certi/scripts/FindRTI.cmake?revision=1.12&root=certi&view=markup I had to update this copy in order to include 1516 lib names. http://cvs.savannah.gnu.org/viewvc/certi/scripts/FindRTI.cmake?revision=1.13&root=certi&view=markup I shall have proposed an update to CMake included module as well but I lack time. If you are willing to maintain the FindRTI.cmake shipped with CMake (if Petr is ok pass on) may be you can merge the modifications you've just sent and the one I did for CERTI source tree then follow the Module maintainer process in order to have a new updated module in the next CMake release. I'll help to review and test the module (at least on Linux). -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] Contribute two new find package implementation.
Hi,
I have done and would like to contribute two new find package implementations.
These are both IEEE standardized successors rti1516 and rti1516e of the RTI
libraries where cmake already has the predecessor library find package
implementation with FindRTI.cmake.
Attached are the initial versions of FindRTI1516.cmake and FindRTI1516E.cmake.
Is it possible to include these or improoved versions into the standard
distribution?
Please review and may be apply.
Thanks
Mathias
--
Dr. Mathias Fröhlich, science + computing ag, Software Solutions
Hagellocher Weg 71-75, D-72070 Tuebingen, Germany
Phone: +49 7071 9457-268, Fax: +49 7071 9457-511
--
Vorstand/Board of Management:
Dr. Bernd Finkbeiner, Dr. Roland Niemeier,
Dr. Arno Steitz, Dr. Ingrid Zech
Vorsitzender des Aufsichtsrats/
Chairman of the Supervisory Board:
Philippe Miltin
Sitz/Registered Office: Tuebingen
Registergericht/Registration Court: Stuttgart
Registernummer/Commercial Register No.: HRB 382196
# Module to find IEEE 1516 HLA/RTI libraries
#
# This module tries to find rti1516 libraries and includes The
# following cmake variables are set depending on the availability of
# these libraries/includes.
#
# This code sets the following variables:
# RTI1516_INCLUDE_DIR, where to find RTI/RTI1516.h, etc.
# RTI1516_LIBRARY, the rti1516 library
# RTI1516_FEDTIME_LIBRARY, the rti1516 logical time library
# RTI1516_LIBRARIES, both required libraries
# RTI1516_FOUND, If true hla/rti1516 includes and libraries are available
#
#
# Distributed under the OSI-approved BSD License (the "License");
# see accompanying file Copyright.txt for details.
#
# This software is distributed WITHOUT ANY WARRANTY; without even the
# implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
# See the License for more information.
#
SET(RTI1516_INSTALL_PREFIX "" CACHE PATH "IEEE 1516 RTI/HLA install prefix path")
MARK_AS_ADVANCED(RTI1516_INSTALL_PREFIX)
FIND_PATH(RTI1516_INCLUDE_DIR
NAMES RTI/RTI1516.h
PATH_SUFFIXES include/rti1516 include/RTI1516 include
PATHS "${RTI1516_INSTALL_PREFIX}"
DOC "IEEE 1516 RTI include path"
)
FIND_LIBRARY(RTI1516_LIBRARY
NAMES rti1516 RTI1516
PATHS "${RTI1516_INSTALL_PREFIX}"
DOC "IEEE 1516 RTI Library"
)
FIND_LIBRARY(RTI1516_FEDTIME_LIBRARY
NAMES fedtime1516 FedTime1516
PATHS "${RTI1516_INSTALL_PREFIX}"
DOC "IEEE 1516 fedtime Logical Time Library"
)
# Convinience for using the default federation time, in any case
SET(RTI1516_LIBRARIES ${RTI1516_LIBRARY} ${RTI1516_FEDTIME_LIBRARY})
IF(NOT "${RTI1516_INCLUDE_DIR} ${RTI1516_LIBRARIES}" MATCHES NOTFOUND)
# Since rti1516e uses the same headers but a different namespace,
# distinguish the headers by this
INCLUDE(CheckCXXSourceCompiles)
SET(CMAKE_REQUIRED_INCLUDES ${RTI1516_INCLUDE_DIR})
SET(CMAKE_REQUIRED_LIBRARIES ${RTI1516_LIBRARIES})
CHECK_CXX_SOURCE_COMPILES("
#include
#include
int main() {
std::wstring version = rti1516::RTIversion();
return 0;
}
" _rti1516VersionCompiles)
ENDIF()
INCLUDE(FindPackageHandleStandardArgs)
FIND_PACKAGE_HANDLE_STANDARD_ARGS(rti1516
REQUIRED_VARS
RTI1516_INCLUDE_DIR
RTI1516_LIBRARY
RTI1516_FEDTIME_LIBRARY
_rti1516VersionCompiles
FAIL_MESSAGE "IEEE 1516 libraries not found!")
IF(RTI1516_FOUND)
MESSAGE(STATUS "IEEE 1516 libraries found.")
MESSAGE(STATUS "IEEE 1516 includes found: ${RTI1516_INCLUDE_DIR}")
MESSAGE(STATUS "IEEE 1516 RTI library found: ${RTI1516_LIBRARY}")
MESSAGE(STATUS "IEEE 1516 fedtime library found: ${RTI1516_FEDTIME_LIBRARY}")
ENDIF()
MARK_AS_ADVANCED(
RTI1516_INCLUDE_DIR
RTI1516_LIBRARY
RTI1516_FEDTIME_LIBRARY
)
# Module to find IEEE 1516E HLA/RTI libraries
#
# This module tries to find rti1516e libraries and includes The
# following cmake variables are set depending on the availability of
# these libraries/includes.
#
# This code sets the following variables:
# RTI1516E_INCLUDE_DIR, where to find RTI/RTI1516.h, etc.
# RTI1516E_LIBRARY, the rti1516E library
# RTI1516E_FEDTIME_LIBRARY, the rti1516E logical time library
# RTI1516E_LIBRARIES, both required libraries
# RTI1516E_FOUND, If true hla/rti1516E includes and libraries are available
#
#
# Distributed under the OSI-approved BSD License (the "License");
# see accompanying file Copyright.txt for details.
#
# This software is distributed WITHOUT ANY WARRANTY; without even the
# implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
# See the License for more information.
#
SET(RTI1516E_INSTALL_PREFIX "" CACHE PATH "IEEE 1516E RTI/HLA install prefix path")
MARK_AS_ADVANCED(RTI1516E_INSTALL_PREFIX)
FIND_PATH(RTI1516E_INCLUDE_DIR
NAMES RTI/RTI1516.h
PATH_SUFFIXES include/rti1516e include/RTI1516E include
PATHS "${RTI1516E_INSTALL_PREFIX}"
DOC "IEEE 1516E RTI include path"
)
FIND_LIBRARY(RTI1516E_LIBRARY
NAMES rti1516e RTI1516E
PATHS "${RTI1516E_INSTALL_PREFIX}"
DOC "IEEE 1516E RTI Library"
)
FIND_LIBRARY(RTI1516E_FEDTIME_LIBRARY
NAMES fed
