[CMake] Contribute two new find package implementation.

Eric Noulard eric.noulard at gmail.com
Fri Oct 7 13:06:29 EDT 2011


2011/10/7 Mathias Fröhlich <M.Froehlich at 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


More information about the CMake mailing list