2011/10/7 Mathias Fröhlich <m.froehl...@science-computing.de>:
>
> 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
