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] implements Comparable
Darn - sorry, I posted this to the wrong mail list.
From: EXT-Harris, Scott H
Sent: Saturday, October 08, 2011 5:04 PM
To: cmake@cmake.org
Cc: EXT-Harris, Scott H
Subject: implements Comparable
Hi,
How can I get SWIG to generate a java class that "implements Comparable"?
Let's say I have a C++ class X and an SWIG interface X that generates a
compareTo(X rhs) method.
If I use the Java class generated by SWIG in a TreeMap then the second put will
throw this exception:
CREATION exception: java.lang.ClassCastException: com.myCompany.project.X
in exception handler got exception: java.lang.NullPointerException
But if I modify the generated X.java file from
public class X {
to
public class X implements Comparable {
then the exception is not thrown and the compareTo function is used as expected.
Can I get SWIG to add "implements Comparable to the class?
FYI: For example of the test code:
X first = new X(1);
X last = new X(9);
TreeMapmm = new TreeMap();
String old = mm.put(last, "last");
// this next line throws the exeption
old = mm.put(first, "first");
Thanks,
Scott
--
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] implements Comparable
Hi,
How can I get SWIG to generate a java class that "implements Comparable"?
Let's say I have a C++ class X and an SWIG interface X that generates a
compareTo(X rhs) method.
If I use the Java class generated by SWIG in a TreeMap then the second put will
throw this exception:
CREATION exception: java.lang.ClassCastException: com.myCompany.project.X
in exception handler got exception: java.lang.NullPointerException
But if I modify the generated X.java file from
public class X {
to
public class X implements Comparable {
then the exception is not thrown and the compareTo function is used as expected.
Can I get SWIG to add "implements Comparable to the class?
FYI: For example of the test code:
X first = new X(1);
X last = new X(9);
TreeMapmm = new TreeMap();
String old = mm.put(last, "last");
// this next line throws the exeption
old = mm.put(first, "first");
Thanks,
Scott
--
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] Xcode resources for different projects in different directories.
Sounds like a bug/missing feature. File a bug with a example project that
demonstrates the issue on the bugtracker, and hopefully someone will have
time to take a look at it ;)
/Johan
On Sat, Oct 8, 2011 at 4:00 PM, Daniel Dekkers wrote:
> Hi,
>
> I think I've asked this earlier, but still no solution, so i'll try again.
>
> I'm targeting Xcode (iOS) and would like to have multiple projects (and one
> library) in a single workspace. In the individual projects, I set...
>
> SET_TARGET_PROPERTIES( ${APP_NAME} PROPERTIES RESOURCE "${RSRC_FILES}" )
>
> ...to make Xcode aware of the resources (so Xcode will copy them to the
> bundle before building).
>
> But.. all the resources of all the projects end up in /Resources, a top
> level Xcode folder, except for the Info.plist, that goes in a /Resources
> folder in the project itself. This (of course) gives problems because there
> are different files with the same names (icons) and I don't want all the
> resources of all the projects in all the bundles.
>
> So, it would be nice of I could let CMake put the resources of an
> individual project in the /Resources directory of that individual project.
> But no idea how to do that.
>
> Kind Regards,
>
> Daniel Dekkers
>
>
>
>
> --
> 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
>
--
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] Xcode resources for different projects in different directories.
Hi,
I think I've asked this earlier, but still no solution, so i'll try again.
I'm targeting Xcode (iOS) and would like to have multiple projects (and one
library) in a single workspace. In the individual projects, I set...
SET_TARGET_PROPERTIES( ${APP_NAME} PROPERTIES RESOURCE "${RSRC_FILES}" )
...to make Xcode aware of the resources (so Xcode will copy them to the bundle
before building).
But.. all the resources of all the projects end up in /Resources, a top level
Xcode folder, except for the Info.plist, that goes in a /Resources folder in
the project itself. This (of course) gives problems because there are different
files with the same names (icons) and I don't want all the resources of all the
projects in all the bundles.
So, it would be nice of I could let CMake put the resources of an individual
project in the /Resources directory of that individual project. But no idea how
to do that.
Kind Regards,
Daniel Dekkers
--
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] Shouldn't CMAKE_VERBOSE_MAKEFILE add false to VS 2010 vcxproj files?
Update: I locally fixed CMake's support for CMAKE_VERBOSE_MAKEFILE on
Visual Studio 10 (or higher), and submitted a bug report:
0012504: Fix CMAKE_VERBOSE_MAKEFILE for Visual Studio 10 vcxproj files
http://public.kitware.com/Bug/view.php?id=12504
It seems to me that only a few lines of code in
cmVisualStudioGeneratorOptions::SetVerboseMakefile should be changed. I
hope the fix can be included with the next release.
I wrote on 20 September 2010:
When I choose Visual Studio 9 (MSVC 2008) as generator, switching on
CMAKE_VERBOSE_MAKEFILE causes an extra line in the generated vcproj
file, saying:
SuppressStartupBanner="FALSE"
However, when I choose Visual Studio 10 (MSVC 2010), switching on
CMAKE_VERBOSE_MAKEFILE does not seem to have an effect. Right? I would
have liked to have the following line added to section of
the generated vcxproj file:
false
Doing so would trigger the compiler to print its commandline arguments
onto the output stream or output window, while it is compiling. Which I
find pretty helpful!
Note that the fix I'm proposing now at
public.kitware.com/Bug/view.php?id=12504 generates:
This fix does *not* trigger those annoying "D9035" compiler warnings
("option 'nologo-' has been deprecated"). :-)
Kind regards,
Niels
--
Niels Dekker
http://www.xs4all.nl/~nd/dekkerware
Scientific programmer at LKEB, Leiden University Medical Center
--
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] ExternalProject, target_link_libraries(), and Multi-configuration Builds.
On 10/08/2011 05:33 AM, michael lowell roberts wrote: > Hi all, > > I'm attempting to use the ExternalProject module to compile and link against > a library and I've run into a problem that I'm not certain how to address. > I'm using CMake 2.8.6 and Visual Studio 10 Express. > > The external project, in my case, is a CMake-compiled project and CMake > predictably builds a matching configuration in the external project. > > The target_link_libraries() command, however, only allows for two > configurations, at most, mapped to labels "debug" and "optimized." > > This allows for only two of the four default build configurations to > complete successfully. > > For example, in my build scripts, I have told target_link_libraries() to map > "debug" configurations to the Debug version of library and optimized > configurations map to the "RelWithDebInfo" build of the library. Therefore, > if I build the "Release" configuration, I get linker errors because the > external project was also built with the "Release" configuration but I need > to link against "RelWithDebInfo." > > It seems to be that no matter how the target_link_library() mappings are set > up, only half of the default configurations will build properly because of > the dualism that target_link_libraries() uses. > > How do I get all four default build configurations working? > > Regards, > Mike Could you boil down this issue to a minimal but self-contained exemplary project and post it here for further investigation? Regards, Michael -- 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] simple cmake example
On Fri, Oct 7, 2011 at 11:23 PM, Tim Coddington
wrote:
> Thank you. After adapting your file ccmake complains about line 7:
>
> include(${MRPT_USE_FILE})
>
> "CMake Error at CMakeLists.txt:7 (include):
> include called with wrong number of arguments. Include only takes
> one file."
>
> How is MRPT_USE_FILE defined?
>
Sorry. In the 2 minutes I spent on creating the example for you I did
not look up the finder for MRPT but assumed it followed the standard
that most other packages use. Do as Michael says for that..
John
--
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] simple cmake example
On 10/08/2011 05:23 AM, Tim Coddington wrote:
> Thank you. After adapting your file ccmake complains about line 7:
>
> include(${MRPT_USE_FILE})
>
> "CMake Error at CMakeLists.txt:7 (include):
>include called with wrong number of arguments. Include only takes
> one file."
>
> How is MRPT_USE_FILE defined?
AFAICS, it's not defined at all in MRPT's configuration file, so leave
out this INCLUDE(${MRPT_USE_FILE}) line and try anew. Besides, MRPT's
config file has several flaws which I tend to rate as quite critical:
ADD_DEFINITIONS(), INCLUDE_DIRECTORIES() and LINK_DIRECTORIES(). Such
functions shouldn't appear in config files or find modules since they
modify the current scope's compilation environment, something a user
might not expect.
Additionally, I'd recommend to use two CMakeLists.txt files in your
exemplary project: A top-Level one containing ADD_SUBDIRECTORY(src),
and a src/CMakeLists.txt identical to the one John has proposed but
with adapted paths, of course, i.e.
SET(${PROJECT_NAME}_SRC
file3.cpp
file4.cpp
main.cpp
)
SET(${PROJECT_NAME}_HDR
file1.h
file2.h
file3.h
file4.h
)
INCLUDE_DIRECTORIES(${CMAKE_CURRENT_SOURCE_DIR})
and without the CMAKE_MINIMUM_REQUIRED() AND PROJECT() commands.
IMO, the CMakeLists.txt files should follow the project's organization,
and you organize the sources in the src subdirectory, so there should
be a src/CMakeLists.txt. The top-level CMakeLists.txt suits perfectly
to add things like additional targets to generate documentation or to
account for further source directories, e.g. supplementary or third
party components which you possibly don't want to mix up with your
project's actual source tree.
Regards,
Michael
> On Fri, 2011-10-07 at 18:27 -0400, John Drescher wrote:
>> On Fri, Oct 7, 2011 at 6:00 PM, Tim Coddington
>> wrote:
>>> Hi
>>> I recently started working with open source code that uses cmake for
>>> build. I've been able to make do since most of the CMakeLists.txt files
>>> are provided or specific instructions are given.
>>>
>>> I'm about to embark on my first contribution to build a driver for an
>>> IMU and I want to build an example that is very similar to mine but it's
>>> been "extracted" from an existing code tree, i.e. current CMakeLists.txt
>>> files would port easily.
>>>
>>> I'm having problems constructing what should be a relatively
>>> straightforward CMakeLists.txt file for the extracted code that I want
>>> to run in isolation. I've been reading tutorials, etc but I don't seem
>>> to get it. Please consider
>>> taking my general C++ example described below and tell me what (exactly)
>>> the CMakeLists.txt should look.
>>>
>>> [Ubuntu 11.04, cmake 2.8.3, C++ code]
>>>
>>> Given:
>>> Top level directory "proj/" and subdir "proj/src"
>>>
>>> The proj/ directory shall contain the parent CMakeLists.txt and
>>> proj/src shall contain a child CMakeLists.txt (if
>>> necessary/appropriate).
>>>
>>> The src/ directory contains these source related files:
>>>
>>> file1.h >> header only no associated cpp file
>>> file2.h >> header only "
>>> file3.h
>>> file3.cpp
>>> file4.h
>>> file4.cpp
>>> main.cpp
>>>
>>> In addition to standard references, some of these files depend on
>>> external library which is found with the FIND_PACKAGE(MRPT REQUIRED
>>> hwdrivers slam)[note: these libraries come from Mobile Robot
>>> Programming Toolkit]
>>>
>>> Please tell me what the two (or one) CMakeLists.txt file(s) should
>>> contain in order to build this code.
>>>
>>
>> Something like the following:
>>
>> cmake_minimum_required(VERSION 2.8)
>>
>> PROJECT(MYProjectName)
>>
>> FIND_PACKAGE(MRPT REQUIRED hwdrivers slam)
>> include(${MRPT_USE_FILE})
>>
>> # Set your files and resources here
>> SET(${PROJECT_NAME}_SRC
>> ./src/file3.cpp
>> ./src/file4.cpp
>> ./src/main.cpp
>> )
>>
>> SET(${PROJECT_NAME}_HDR
>> ./src/file1.h
>> ./src/file2.h
>> ./src/file3.h
>> ./src/file4.h
>> )
>>
>> include_directories(src)
>>
>> ADD_EXECUTABLE( ${PROJECT_NAME} ${${PROJECT_NAME}_SRC}
>> ${${PROJECT_NAME}_HDR})
>>
>> TARGET_LINK_LIBRARIES( ${PROJECT_NAME} ${MRPT_LIBRARIES)
--
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
