Re: [CMake] Dependency on library in a separate branch
On 06/27/2011 12:43 AM, Klaim - Joël Lamotte wrote:
> 2011/6/26 David Cole
>
>> In your top level CMakeLists.txt:
>>
>> add_subdirectory(B)
>> add_subdirectory(A)
>> add_subdirectory(C)
>>
>> A & C must come after B since they both depend on B.
>>
>> Does that help?
>>
>>
> Thanks for your answer. It don't seem so, but let me explain you the full
> context:
>
> in the root directory I have
>
> add_subdirectory( tools )
>
>
> in the tools directory i have
>
> add_subdirectory(B)
> add_subdirectory(A)
>
> I suppose I already thought that there was some kind of order in dependency
> declaration, so it looks like the same you tell me, but to be complete:
>
> In directory A I have the CMakeLists.txt file to define the executable A, no
> add_subdirectory().
> In directory B I have the CMakeLists.txt file to define the library B, with
>
> add_subdirectory(C)
>
> So it seems that your suggestion don't work but the difference remains in
> the tree structure so I'm not sure what is impacted.
> Maybe I did something wrong somewhere else.
>
> The full repostory is up to date now there:
> http://code.google.com/p/art-of-sequence/source/browse/
> In tools directory, project A is aosdesigner, project B is aoslcpp, project
> C is the test project under aoslcpp.
>
> I feel really dumb, I'm sure it's obvious but can't find why it don't work
> with aosdesigner project that now requires aoslcpp
With the directory structure
/myrepo/tools/aosdesigner
/myrepo/tools/aoslcpp
/myrepo/tools/aoslcpp/test
aosdesigner must be informed about aoslcpp's include directory because
it is not inherited by aosdesigner as it is inherited by aoslcpp/test
since the latter is entered after aoslcpp issued INCLUDE_DIRECTORIES().
Include directories have directory scope whereas regular targets are
global, so you can refer to aoslcpp from aosdesigner's CMakeLists.txt
although the aoslcpp target has been defined in a sibling directory
next to aosdesigner's one, but the same does not work for include
directories. In aosdesigner's CMakeLists.txt, you should use
INCLUDE_DIRECTORIES(${CMAKE_SOURCE_DIR}/tools/aoslcpp/include)
or
INCLUDE_DIRECTORIES(../aoslcpp/include)
to make aoslcpp's include directory available for aosdesigner. Note
that if aosdesigner also needs XSD, you should move FIND_PACKAGE(XSD)
to a higher-level CMakeLists.txt file, probably tools/CMakeLists.txt.
'hope that helps.
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] CDash broken after production mode is set to true
cmake-boun...@cmake.org wrote on 23.06.2011 12:42:42: > From: mika.raj...@patria.fi > To: cmake@cmake.org > Date: 23.06.2011 12:43 > Subject: Re: [CMake] CDash broken after production mode is set to true > Sent by: cmake-boun...@cmake.org > > - Forwarded by Mika Rajala/PATRIA on 23.06.2011 12:42 - > > From:Mika Rajala/PATRIA > To:mika.raj...@patria.fi > Date:23.06.2011 12:42 > Subject:Re: [CMake] CDash broken after production mode is set to true > > > Hi > > I tried installing a different browser and, with that, it seems to work. > > However, the fonts are still different from what they were before, so > something has changed. > > I have some screenshots so it's easy to verify this. > > What i still don't understand, is what happened to the client subscription. > > For SiteId, after a seemingly successful submission, It gets some crap > which i cannot type since i don't know the character codes for all those things > > possibly something in raw binary. > > off to "happy" bug hunting, please post your suggestions if you have anything. > > -mika > > > > From:mika.raj...@patria.fi > To:cmake@cmake.org > Date:23.06.2011 11:00 > Subject:[CMake] CDash broken after production mode is set to true > Sent by:cmake-boun...@cmake.org > > > > Hi > > I was all set up with my cdash server, after setting production mode to > true, things stop working. > > Clients when they attempt to receive their id when they submit to cdash > server get some junk as answer, they don't list up the schedule build thing. > > Fonts change, menus won't work. > > For instance, the Administration menu, when i look at a dashboard. > > > Any ideas? > > -mika___ > 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 Yeah, I found it, after getting really happy with PHP and IE The hex code was the UTF-8 BOM crap, which indicates that the rest of the file is in UTF-8. EF BB BF Windows notepad saved that to the config.php file, that i modified to set production mode to true. For some happy reason within PHP, the hex code EF BB BF is echoed, when a file with it is "included". For CDash / CTest, this means that the thing is added three times to the file that the CDash client gets when it submits itself to the CDash server. This was also the reason why IE could not show the menu from the administration thing. I wouldn't wonder if that could somehow be used to hack into ones computer. Firefox seemed to work regardless of this, maybe it just removes that sequence. Why doesn't CTest / CMake / IE ? Oh, and if you are wondering how I removed it, I used notepad++. Under encoding you find "Encode in UTF-8 without BOM". -mika ___ 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] Dependency on library in a separate branch
2011/6/27 Klaim - Joël Lamotte
>
> The full repostory is up to date now there:
> http://code.google.com/p/art-of-sequence/source/browse/
> In tools directory, project A is aosdesigner, project B is aoslcpp, project
> C is the test project under aoslcpp.
>
>
In case it helps, what I find strange is that there is no error on the CMake
project generation process.
The missing include directory isn't reported even if the aoslcpp (B) name is
used ( in
http://code.google.com/p/art-of-sequence/source/browse/tools/aosdesigner/CMakeLists.txt
)
target_link_libraries( aosdesigner ${QT_LIBRARIES} aoslcpp )
(aoslcpp <=> A, aosdesigner <=> B)
So I'm not sure if it helps.
___
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] Dependency on library in a separate branch
2011/6/26 David Cole > In your top level CMakeLists.txt: > > add_subdirectory(B) > add_subdirectory(A) > add_subdirectory(C) > > A & C must come after B since they both depend on B. > > Does that help? > > Thanks for your answer. It don't seem so, but let me explain you the full context: in the root directory I have add_subdirectory( tools ) in the tools directory i have add_subdirectory(B) add_subdirectory(A) I suppose I already thought that there was some kind of order in dependency declaration, so it looks like the same you tell me, but to be complete: In directory A I have the CMakeLists.txt file to define the executable A, no add_subdirectory(). In directory B I have the CMakeLists.txt file to define the library B, with add_subdirectory(C) So it seems that your suggestion don't work but the difference remains in the tree structure so I'm not sure what is impacted. Maybe I did something wrong somewhere else. The full repostory is up to date now there: http://code.google.com/p/art-of-sequence/source/browse/ In tools directory, project A is aosdesigner, project B is aoslcpp, project C is the test project under aoslcpp. I feel really dumb, I'm sure it's obvious but can't find why it don't work with aosdesigner project that now requires aoslcpp Klaim - Joël Lamotte ___ 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] XCode4 and archiving
We will be getting to various Xcode 4 issues over the coming months. In the meantime, I would look into whether there's a way to suppress the generation of the INSTALL_PATH lines rather than having to run a post-processing script. If I remember this later on I'll check into it myself and report back. HTH, David On Sun, Jun 26, 2011 at 12:11 PM, Johan Knutzen wrote: > I found a workaround, if anybody is interested. The problem lies in the > cmake generator setting the INSTALL_PATH to "" in the project file. Not sure > why cmake does this, but a fix is to remove all entries. > > Here is a bash script which takes a pbxproj file as argument and fixes it: > #! /bin/bash > sed -i".bak" '/INSTALL_PATH/d' $1 > > Would be helpful if somebody working on cmake would comment, and perhaps > fix this issue. > > Johan > > > --- Den sön 2011-06-26 skrev Johan Knutzen : > > > Från: Johan Knutzen > > Ämne: [CMake] XCode4 and archiving > > Till: cmake@cmake.org > > Datum: söndag 26 juni 2011 16:00 > > Hey! > > > > I've experienced a few hickups when using cmake with XCode > > 4, and one of them is the ability to create archives. In the > > IDE you do this by clicking Product->Archive, which > > results in an archive which you later can sign with > > different provisioning profiles when distributing iOS apps > > to beta testers. > > > > However, for projects generated using cmake the archiving > > command does not work. The result of that command should be > > an archiving listed in the organizer, but that is not the > > case when you have a cmake generated project. > > > > Does anyone have a solution or work around for this? > > > > Johan > > ___ > > 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 > ___ 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] Fwd: Problem finding DLLS to use with tests
I was writing exactly about this, then found this email.
Let me elaborate the problem a bit more, since what we need really is
a best pratice.
Suppose you have a project with multiple libraries and a test project.
The problem is that generated DLLs are not on PATH, so the exe will
not find it. Usually the binaries are put in the build folder in
separate directories, so the test executable won't find these if you
run it directly.
I see three possible solutions:
- Put the binaries , in the build folder, under the same output
directory. This can be done by changing the appropriate CMAKE_
setting.
- Run the tests from the installation directory. This requires that
you do an INSTALL before running the tests
- Do a post-build step to copy the binaries and the tests somewhere.
Something like an INSTALL phase, but related only to test data (so ,
for instance , you won't have to copy source/configuration files)
- Change the path to let the exe find all the DLLs
Approach 1 will change the build folder default behavoir, and you
still to find a way to copy there the possible external dependencies.
Approach 2 is probably non really appropriate since the INSTALL phase
may do many things other than copying binaries
Approach 3 requires a custom setup step, but will possibly allow this.
Also, instead of a post build step, this can be done as a pre-build
TEST step (I don't know if it is possible)
Approach 4 may be really hard to achieve.
So, what is the best pratice to solve this problem, if there's one?
How should be ctest configured?
Also, while solving this, I faced another problem: if we use external
libs (say TCL or Qt), is there a standard way to copy the BINARIES of
these libs (found using find_package) where we want (i.e. the test
binary folder).
Thank you in advance for any hint!
QbProg
2011/6/23 :
> So, you are manually running your tests, for example, the ‘test_julian.exe’
> or ‘testcpp.exe’? Running them from a command prompt gives you that same
> error about the application has failed to start? And the name of the dll’s
> exactly match? And you have tried copying the .dll into the same directory
> and running it manually?
>
>
>
> You can use Dependency Walker to run a program and debug the issues it has
> with DLL. Some versions of Visual Studio come with a version of it. You can
> run depends.exe from a visual studio command prompt and pass it the
> executable. If you don’t have it, you can get it from
> http://www.dependencywalker.com/. You can profile and executable by hitting
> F7 (I usually checkmark all the options to on) and it will tell you all
> about what it is doing to bootstrap you exe, including where it fails.
> Usually, this will give you a better idea of what happened, where it looked
> for the DLL, and why it rejected ones that seemed like they should have
> worked. In particular, it might be finding that DLL fine, but the DLL is
> returning 0 from DllMain() and failing to be loaded.
>
>
>
> Hope that helps!
>
>
>
> Aaron C. Meadows
>
> From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of
> Stephen Torri
> Sent: Thursday, June 23, 2011 1:19 PM
> To: cmake@cmake.org
> Subject: [CMake] Fwd: Problem finding DLLS to use with tests
>
>
>
> On Thu, Jun 23, 2011 at 11:37 AM, wrote:
>
> Can you post your CMakeLists.txt? Did you get different errors for each of
> the 3 solutions you tried, or were they all the same error? What was the
> exception code?
>
>
>
> I got the same error. I did not receive a exception throw when I ran the
> testing code via Visual Studio. I got a message that said:
>
>
>
> "The application has failed to start because
> boost_unit_test_framework-vc100-mt-gd-1_46_1.dll was not found. Reinstalling
> the application may fix the problem".
>
>
>
> It looks like I either need to copy the boost dlls I use to my test
> directory or somehow add the boost directory to the PATH environment
> variable.
>
>
>
> -- Master CMakeLists.txt
>
> cmake_minimum_required ( VERSION 2.8 )
>
> SET(CMAKE_MODULE_PATH "${CMAKE_SOURCE_DIR}/cmake_modules/")
>
> PROJECT(myproject)
>
> SET ( ${PROJECT_NAME}_MAJOR_VERSION 0 )
> SET ( ${PROJECT_NAME}_MINOR_VERSION 5 )
> SET ( ${PROJECT_NAME}_PATCH_LEVEL 0 )
>
> SET(BOOST_ROOT "C:/Program Files (x86)/boost/boost_1_46_1" CACHE PATH
> "Installation directory for boost")
>
> #-
> # DEBUG
> #-
> OPTION(DEBUG_TLE_PARSER "Enable debugging of TLE parser." OFF)
> IF(DEBUG_TLE_PARSER)
> SET (DEBUG_PARSER 1)
> ENDIF(DEBUG_TLE_PARSER)
>
> #-
> # Unix Configuration
> #-
> IF(UNIX)
>
> SET(INSTALL_BIN_DIR bin CACHE PATH "Installation directory for
> executables")
> SET(INSTALL_LIB_DIR lib CACHE PATH "Installation directory for libraries")
> SET(INSTALL_INC_DIR include CACHE
Re: [CMake] Dependency on library in a separate branch
In your top level CMakeLists.txt:
add_subdirectory(B)
add_subdirectory(A)
add_subdirectory(C)
A & C must come after B since they both depend on B.
Does that help?
Hope so,
David
2011/6/26 Klaim - Joël Lamotte
> Hi,
>
> I'm having trouble understanding how I should solve this case correctly in
> CMake :
>
> I want my project A to include+link my project B. I already made it with
> project C but it don't work with A.
> I think the problems comes from the directory structure :
>
> /myrepo/tools/A (exe/Qt)
> /myrepo/tools/B (shared library)
> /myrepo/tools/B/C (exe)
>
> Each of those folders have a CMakeFiles.txt file that add_subdirectory(
> the_sub_directories ).
>
> B uses include_directories() and C use target_link_libraries( C B )
> So C does include and compile+link with code using B code.
>
> A code runs fine alone, but now I need it to use B.
> I've added
>
> target_link_libraries( A ${QT_LIBRARIES} B )
>
> to make sure it does uses B but the generated projects don't have the B
> include directory.
>
> I know that I could use an advanced variable to get the include file, but I
> don't find it consistent with the fact that
> C executable does implicitely use the include file from B. A being
> configured the same, it should work too... no?
>
> I think it's related to the projects CMakeFiles.txt positions in the
> directory hierarchy but I'm still often wrestling with CMake so I'm not
> sure.
>
> What would be the idiomatic CMake way of making A include+link B?
>
> The real code is open source so I can show you exactly what is my current
> setup if it helps (but I guess it's a noob question...)
>
>
> Klaim - Joël Lamotte
>
> ___
> 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] Dependency on library in a separate branch
Hi,
I'm having trouble understanding how I should solve this case correctly in
CMake :
I want my project A to include+link my project B. I already made it with
project C but it don't work with A.
I think the problems comes from the directory structure :
/myrepo/tools/A (exe/Qt)
/myrepo/tools/B (shared library)
/myrepo/tools/B/C (exe)
Each of those folders have a CMakeFiles.txt file that add_subdirectory(
the_sub_directories ).
B uses include_directories() and C use target_link_libraries( C B )
So C does include and compile+link with code using B code.
A code runs fine alone, but now I need it to use B.
I've added
target_link_libraries( A ${QT_LIBRARIES} B )
to make sure it does uses B but the generated projects don't have the B
include directory.
I know that I could use an advanced variable to get the include file, but I
don't find it consistent with the fact that
C executable does implicitely use the include file from B. A being
configured the same, it should work too... no?
I think it's related to the projects CMakeFiles.txt positions in the
directory hierarchy but I'm still often wrestling with CMake so I'm not
sure.
What would be the idiomatic CMake way of making A include+link B?
The real code is open source so I can show you exactly what is my current
setup if it helps (but I guess it's a noob question...)
Klaim - Joël Lamotte
___
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] XCode4 and archiving
I found a workaround, if anybody is interested. The problem lies in the cmake generator setting the INSTALL_PATH to "" in the project file. Not sure why cmake does this, but a fix is to remove all entries. Here is a bash script which takes a pbxproj file as argument and fixes it: #! /bin/bash sed -i".bak" '/INSTALL_PATH/d' $1 Would be helpful if somebody working on cmake would comment, and perhaps fix this issue. Johan --- Den sön 2011-06-26 skrev Johan Knutzen : > Från: Johan Knutzen > Ämne: [CMake] XCode4 and archiving > Till: cmake@cmake.org > Datum: söndag 26 juni 2011 16:00 > Hey! > > I've experienced a few hickups when using cmake with XCode > 4, and one of them is the ability to create archives. In the > IDE you do this by clicking Product->Archive, which > results in an archive which you later can sign with > different provisioning profiles when distributing iOS apps > to beta testers. > > However, for projects generated using cmake the archiving > command does not work. The result of that command should be > an archiving listed in the organizer, but that is not the > case when you have a cmake generated project. > > Does anyone have a solution or work around for this? > > Johan > ___ > 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
Re: [CMake] Enabling C99 in CMake
On 25/06/2011 07:30, "Michael Hertling" wrote: >On 06/24/2011 04:16 PM, Owen Shepherd wrote: >> I think the appropriate solution here is a project-specific dialect >>flag - >> perhaps one taking options in the GNU format since it seems most >>familiar. >> One could perhaps generalise this further - a file-specific dialect flag >> which defaults to the value of the project-specific flag > >If there are individual compilers for C89/C99, and a projects needs a >C99 one, any dialect flags - project/directory/target/file specific - >would be of no use, wouldn't they? Rather, one must specify the C99 >compiler if it isn't found automatically by CMake during the initial >configuration, and the project might consider to check the compiler's >C99 capabilities. Sorry - I should have said property rather than flag. That is, something along the lines of set_target_properties(the_target PROPERTIES C_DIALECT C99) Or set_source_files_properties(myfile.c PROPERTIES C_DIALECT C99) (I'm not entirely sure here whether the source file property should be C_DIALECT or just DIALECT. The language, after all, should be unambiguous at this point) It would then be the responsibility of the Cmake machinery to choose the right compiler and set it up for building code with the given dialect. -- Owen Shepherd http://www.owenshepherd.net owen.sheph...@e43.eu (general) / oshephe...@shef.ac.uk (academic) ___ 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] XCode4 and archiving
Hey! I've experienced a few hickups when using cmake with XCode 4, and one of them is the ability to create archives. In the IDE you do this by clicking Product->Archive, which results in an archive which you later can sign with different provisioning profiles when distributing iOS apps to beta testers. However, for projects generated using cmake the archiving command does not work. The result of that command should be an archiving listed in the organizer, but that is not the case when you have a cmake generated project. Does anyone have a solution or work around for this? Johan ___ 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] Getting file list from build directory
You could run ar -x at cmake runtime using execute_process(...) and then glob the objects. If your archive is created by cmake, you could write a shell script, that unpacks the archive and do what you wants with the object files. Andreas Am 26.06.2011 07:38, schrieb Dan Furtney: I have a CMakeLists.txt file file that creates an archive from several files. It includes a custom command that dumps the list of objects from the archive using ar –x. I need to link these objects with another custom command. What is the best way to get the list of objects into the link line? Currently the object files are dumping to CMAKE_CURRENT_BINARY_DIR. I tried glob but the files need to be present at cmake run-time. Thanks again for any help. ___ 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
