Re: [cmake-developers] Incomplete gfortran library link command sometimes mysteriously occurs with MinGW/MSYS on Wine-1.5.15 platform
On 2012-10-19 13:39-0400 Bill Hoffman wrote: On 10/19/2012 1:24 PM, Alan W. Irwin wrote: So far this morning there have been no takers, but I hope that changes since I am really stumped by CMake _intermittently_ not issuing the correct link command for libraries with no consistent pattern I can spot with regard to anything I change. Couple of things to try: run --trace on cmake and compare them. Maybe something odd is happening with your cmake variables. Also, look at the generated makefiles and find out what is different between the ones that work and the ones that don't. If this can not be reproduced by running a set command line (some script you write)... Thanks for those suggestions, Bill. The current status is I have sent a complete test case to David Cole who plans to run it when he has a chance this week on at least one Windows platform available to him. That test should show just how easy this issue is to replicate (or not). For that test case here, CMakes generates a bad link command for the epcomf Fortran library for the downloaded Windows binary version of CMake-2.8.9, but I have just discovered that a bootstrapped build of CMake-2.8.9 (using MinGW/MSYS for version 4.5.2 of gcc) generates the correct Fortran link command. I have attached the two relevant build.make files for you and David to look at. The diff between them shows a lot of noise due to different names for libraries used by downloaded versus bootstrapped CMake. I eliminated that diff noise as follows: wine@raven sed -e s?libephcom?ephcom?g -e s?libgnulliver?gnulliver?g -es?\.dll\.a?.lib?g /tmp/build.make |diff -au /tmp/bad_build.make - The result was --- /tmp/bad_build.make 2012-10-20 12:57:03.575441788 -0700 +++ - 2012-10-20 12:59:56.777968384 -0700 @@ -26,17 +26,14 @@ SHELL = /bin/sh # The CMake executable. -CMAKE_COMMAND = /Z/home/wine/newstart/cmake-2.8.9-win32-x86/bin/cmake.exe +CMAKE_COMMAND = /Z/home/wine/newstart/bootstrap_cmake/install_4.5.2/bin/cmake.exe # The command to remove a file. -RM = /Z/home/wine/newstart/cmake-2.8.9-win32-x86/bin/cmake.exe -E remove -f +RM = /Z/home/wine/newstart/bootstrap_cmake/install_4.5.2/bin/cmake.exe -E remove -f # Escaping for special characters. EQUALS = = -# The program to use to edit the cache. -CMAKE_EDIT_COMMAND = /Z/home/wine/newstart/cmake-2.8.9-win32-x86/bin/cmake-gui.exe - # The top-level source directory on which CMake was run. CMAKE_SOURCE_DIR = /z/home/wine/newstart/ephcom2_20121019 @@ -53,6 +50,7 @@ include bindings/f95/CMakeFiles/ephcomf.dir/flags.make bindings/f95/CMakeFiles/ephcomf.dir/ephcomf.f.obj: bindings/f95/CMakeFiles/ephcomf.dir/flags.make +bindings/f95/CMakeFiles/ephcomf.dir/ephcomf.f.obj: bindings/f95/CMakeFiles/ephcomf.dir/includes_Fortran.rsp bindings/f95/CMakeFiles/ephcomf.dir/ephcomf.f.obj: z:/home/wine/newstart/ephcom2_20121019/bindings/f95/ephcomf.f $(CMAKE_COMMAND) -E cmake_progress_report /Z/home/wine/newstart/ephcom2/build_dir/CMakeFiles $(CMAKE_PROGRESS_1) @$(CMAKE_COMMAND) -E cmake_echo_color --switch=$(COLOR) --green Building Fortran object bindings/f95/CMakeFiles/ephcomf.dir/ephcomf.f.obj @@ -81,8 +79,11 @@ dll/ephcomf.dll: dll/ephcom.lib dll/ephcomf.dll: dll/gnulliver.lib dll/ephcomf.dll: z:/home/wine/newstart/ephcom2_20121019/bindings/f95/ephcomf_mingw.def +dll/ephcomf.dll: bindings/f95/CMakeFiles/ephcomf.dir/objects1.rsp @$(CMAKE_COMMAND) -E cmake_echo_color --switch=$(COLOR) --red --bold Linking Fortran shared library ../../dll/ephcomf.dll - cd /Z/home/wine/newstart/ephcom2/build_dir/bindings/f95 /z/home/wine/newstart/MinGW/bin/gfortran.exe /z/home/wine/newstart/ephcom2_20121019/bindings/f95/ephcomf_mingw.def -shared -o ../../dll/ephcomf.dll $(ephcomf_OBJECTS) $(ephcomf_EXTERNAL_OBJECTS) ../../dll/ephcomfc.lib ../../dll/ephcomc.lib ../../dll/ephcom.lib ../../dll/gnulliver.lib + cd /Z/home/wine/newstart/ephcom2/build_dir/bindings/f95 /Z/home/wine/newstart/bootstrap_cmake/install_4.5.2/bin/cmake.exe -E remove -f CMakeFiles/ephcomf.dir/objects.a + cd /Z/home/wine/newstart/ephcom2/build_dir/bindings/f95 /z/home/wine/newstart/MinGW/bin/ar.exe cr CMakeFiles/ephcomf.dir/objects.a @CMakeFiles/ephcomf.dir/objects1.rsp + cd /Z/home/wine/newstart/ephcom2/build_dir/bindings/f95 /z/home/wine/newstart/MinGW/bin/gfortran.exe /z/home/wine/newstart/ephcom2_20121019/bindings/f95/ephcomf_mingw.def -shared -o ../../dll/ephcomf.dll -Wl,--out-implib,../../dll/ephcomf.lib -Wl,--major-image-version,0,--minor-image-version,0 -Wl,--whole-archive CMakeFiles/ephcomf.dir/objects.a -Wl,--no-whole-archive ../../dll/ephcomfc.lib ../../dll/ephcomc.lib ../../dll/ephcom.lib ../../dll/gnulliver.lib # Rule to build all files generated by this target. bindings/f95/CMakeFiles/ephcomf.dir/build: dll/ephcomf.dll You can see the link commands are very different, but also it is intriguing there are other differences as well between CMake results generated with two
[cmake-developers] Generator expressisons in target properties (was Re: conditionals in generator expressions)
Stephen Kelly steveire@... writes: Brad King wrote: The only option I see that might work is to extend the undefined behavior documentation of the LOCATION* properties to cover use of generator expressions with link libraries, and then try to refactor/copy the code out of cmTarget to cmGeneratorTarget to add the generator expressions feature. I think this limitation is perfectly acceptable. Great, thanks. I've implemented this so it's ready for 2.8.11. Together with making export() function at generate time instead of configure-time, I was able to refactor the rest of CMake to use cmGeneratorTarget, and therefore to be (almost) able to use generator expressions for link libraries. That's in the use-generator-target-2 branch in my clone. git://gitorious.org/~steveire/cmake/steveires-cmake.git I'll rebase and submit the contents of it in several parallel branches when 2.8.11 opens. I'll also fix the style issues in the commits etc. Also in my clone is the interface-target-properties branch. The commits there 'finish' the work needed to make linking work with generator expressions. The way I've implemented it there is to populate a LINK_LIBRARIES property as a result of calling target_link_libraries. The INTERFACE_LINK_LIBRARIES property can also be populated on a target, and it 'chains', which means that the INTERFACE_LINK_LIBRARIES from the dependency tree are all processed, and the DAG checker ensures there are no cycles in their content. That chaining is whitelisted in the cmGeneratorExpressionEvaluator because it is necessary to set up a DAG checker before evaluating. So, the properties that are whitelisted are the properties that always get a DAG checker set on them before they are evaluated. When linking to a target, the INTERFACE_LINK_LIBRARIES are automatically used too. The content of the INTERFACE_LINK_LIBRARIES is assumed to be mandatory, so this makes sense. For backwards compatibility, the debug and optimized keywords are also processed into generator expressions using $CONFIG: A side-effect of using generator expressions in the LINK_LIBRARIES property in this way is that all libraries will appear to be in the link implementation, and may appear again when processing the link interface. I don't know the consequences of that, if any. For now I consider the (IMPORTED_)?LINK_INTERFACE_LIBRARIES(_CONFIG)? properties obsolete and replaced by INTERFACE_LINK_LIBRARIES. I don't have any magic to read the old property when asked for the new one etc. This is mostly for simplicity, and because the IMPORTED and non imported old-properties have slightly different meanings (see the comments in ), but I may investigate further if magic is appropriate. Something I am certain of though is that the new name is needed for consistency with other new properties (INTERFACE_*) and for removal of the requirement for the IMPORTED_ prefix on imported targets. Both properties can be generated in export() and install(EXPORT) anyway, and really I expect minimal impact from this part. I've also come around to the idea that target_link_libraries(foo bar) should be enough to make foo compile and link with bar, removing the need for a new target_use_targets command and removing the need to populate the INCLUDE_DIRECTORIES of foo through include_directories() or otherwise, if bar has an appropriate interface. The reason I've accepted that target_link_libraries() is enough is that in order to link to bar, the include directories must be there when compiling, and in order to use the headers of bar, the appropriate COMPILE_DEFINITIONS must be used too. Similiarly, the appropriate COMPILE_OPTIONS (eg PIC) must be used too. As all of that is a prerequisite for linking anyway, and as it means adding the feature in a source-compatible way with existing CMake code, I think it's better to use target_link_libraries. Any duplication resulting from that is already removed for includes and defines, and we can add the same uniq on COMPILE_OPTIONS etc. In my branch I pseudo-implement part of that with some new generator expressions which process the LINK_LIBRARIES property. At this point, because multiple properties can use generator expressions, and because several properties will depend on the content of the LINK_LIBRARIES property, cycles in generator expressions become a problem for the first time (up to now they haven't been). This is to be expected whenever a declarative language is used. In the top commit in my clone I describe the problem more fully, and a way which might work to break cycles like that, but which require user-intervention. I don't think I have the full solution yet, so more ideas are welcome. Qt 5 (and Qt 4 if I can help it) and KDE will likely consume and produce libraries taking advantage of this INTERFACE generator properties feature, which will help drive adoption. Several modules in CMake would probably also benefit from it (eg do any libraries in X11 depend
Re: [cmake-developers] Incomplete gfortran library link command sometimes mysteriously occurs with MinGW/MSYS on Wine-1.5.15 platform
On 10/22/2012 3:34 AM, Alan W. Irwin wrote: The diff between them shows a lot of noise Can you send the CMakeFiles/* files? I suspect that it is detecting the compiler or platform different somehow. Also, send the CMakeCache.txt from both builds. You can send it directly to me to avoid filling the list with this stuff. -- Bill Hoffman Kitware, Inc. 28 Corporate Drive Clifton Park, NY 12065 bill.hoff...@kitware.com http://www.kitware.com 518 881-4905 (Direct) 518 371-3971 x105 Fax (518) 371-4573 -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Generator expressisons in target properties (was Re: conditionals in generator expressions)
On 10/22/2012 01:24 PM, Stephen Kelly wrote:
That's in the use-generator-target-2 branch in my clone.
git://gitorious.org/~steveire/cmake/steveires-cmake.git
I'll rebase and submit the contents of it in several parallel branches when
2.8.11 opens. I'll also fix the style issues in the commits etc.
Thanks. If possible please re-organize the topic to make as many of the
refactoring changes (e.g. moves to cmGeneratorTarget) to the front without
any functional changes. That way we can merge/test those first.
Also in my clone is the interface-target-properties branch. The commits there
'finish' the work needed to make linking work with generator expressions.
The cmComputeTargetDepends cannot be per-config because IDE generators use
one set of inter-target dependencies for all configurations. The line you
add in cmGlobalGenerator::ComputeTargetDepends:
+ const char *config =
this-LocalGenerators[0]-GetMakefile()-GetDefinition(CMAKE_BUILD_TYPE);//
TODO: Get from somewhere
is a red flag. You may have to do it for all configurations and take the
union of the dependencies for each target.
The way I've implemented it there is to populate a LINK_LIBRARIES property as
a
result of calling target_link_libraries. The INTERFACE_LINK_LIBRARIES property
can also be populated on a target, and it 'chains', which means that the
INTERFACE_LINK_LIBRARIES from the dependency tree are all processed, and the
DAG
checker ensures there are no cycles in their content.
That chaining is whitelisted in the cmGeneratorExpressionEvaluator because it
is
necessary to set up a DAG checker before evaluating. So, the properties that
are
whitelisted are the properties that always get a DAG checker set on them
before
they are evaluated.
When linking to a target, the INTERFACE_LINK_LIBRARIES are automatically used
too. The content of the INTERFACE_LINK_LIBRARIES is assumed to be mandatory,
so
this makes sense.
Okay. I'd prefer the term transitive to chains. The latter is already
used in our source for a different meaning (target prop chains to dir prop).
For backwards compatibility, the debug and optimized keywords are also
processed
into generator expressions using $CONFIG:
Nice. However:
+ else if (llt == OPTIMIZED)
+{
+l = std::string($CONFIG:Release:) + l + std::string();
+}
The optimized keyword is not just for Release. It is really not debug.
Look at how the llt is used elsewhere to be sure.
A side-effect of using generator expressions in the LINK_LIBRARIES property in
this way is that all libraries will appear to be in the link implementation,
and
may appear again when processing the link interface. I don't know the
consequences of that, if any.
Can you explain that in more detail, please?
For now I consider the (IMPORTED_)?LINK_INTERFACE_LIBRARIES(_CONFIG)?
properties obsolete and replaced by INTERFACE_LINK_LIBRARIES. I don't have any
magic to read the old property when asked for the new one etc. This is mostly
for simplicity, and because the IMPORTED and non imported old-properties have
slightly different meanings (see the comments in ), but I may investigate
further if magic is appropriate.
Okay. We will need carefully written documentation for each of these names
to distinguish them.
Something I am certain of though is that the new name is needed for
consistency
with other new properties (INTERFACE_*) and for removal of the requirement for
the IMPORTED_ prefix on imported targets. Both properties can be generated in
export() and install(EXPORT) anyway, and really I expect minimal impact from
this part.
The INTERFACE_ prefix is good. It's also nice that we don't need _CONFIG
versions of everything anymore.
I've also come around to the idea that
target_link_libraries(foo bar)
should be enough to make foo compile and link with bar
Your justification is reasonable. The code that adds INTERFACE_ properties
to 'bar' in the application could be made conditional if necessary anyway
for compatibility.
At this point, because multiple properties can use generator expressions, and
because several properties will depend on the content of the LINK_LIBRARIES
property, cycles in generator expressions become a problem for the first time
(up to now they haven't been). This is to be expected whenever a declarative
language is used. In the top commit in my clone I describe the problem more
fully, and a way which might work to break cycles like that, but which require
user-intervention. I don't think I have the full solution yet, so more ideas
are
welcome.
It will be difficult to define the behavior for cycles. I think rejecting
them and requiring the user to handle it is reasonable for now. We can
always define non-error behavior for them later in certain cases.
As it is not source compatible to put imported targets into FOO_LIBRARIES
where
paths were used before, I'd like to make a more-established convention of
Re: [cmake-developers] Generator expressisons in target properties (was Re: conditionals in generator expressions)
Brad King wrote:
On 10/22/2012 01:24 PM, Stephen Kelly wrote:
That's in the use-generator-target-2 branch in my clone.
git://gitorious.org/~steveire/cmake/steveires-cmake.git
I'll rebase and submit the contents of it in several parallel branches
when 2.8.11 opens. I'll also fix the style issues in the commits etc.
Thanks. If possible please re-organize the topic to make as many of the
refactoring changes (e.g. moves to cmGeneratorTarget) to the front without
any functional changes. That way we can merge/test those first.
Most of the moves to cmGeneratorTarget depend on the earlier commits. Eg,
'Port cmExportBuildFileGenerator to cmGeneratorTarget.' can't be committed
until cmExportBuildFileGenerator is executed at generate-time. 'Move
GetLinkInterface to cmGeneratorTarget.' can't be committed until 'Use a new
code path to compute target location at configure-time.' is committed.
The section from 'Add a null check to the generator target accessor.' to
'Move TraceDependencies to cmGeneratorTarget.' does not have dependencies
though, and is one of the sections I plan to submit in parallel when 2.8.11
opens.
Also in my clone is the interface-target-properties branch. The commits
there 'finish' the work needed to make linking work with generator
expressions.
The cmComputeTargetDepends cannot be per-config because IDE generators use
one set of inter-target dependencies for all configurations.
Ah, I was wondering about that when I wrote that patch, but forgot to put in
the email. I thought they would be able to have per-config dependencies.
set_property(TARGET foo LINK_LIBRARIES $$Config:Debug:debughelpers
will never work with IDE generators? That's not a limitation of the
generators but of the IDEs?
The way I've implemented it there is to populate a LINK_LIBRARIES
property as a result of calling target_link_libraries. The
INTERFACE_LINK_LIBRARIES property can also be populated on a target, and
it 'chains', which means that the INTERFACE_LINK_LIBRARIES from the
dependency tree are all processed, and the DAG checker ensures there are
no cycles in their content.
That chaining is whitelisted in the cmGeneratorExpressionEvaluator
because it is necessary to set up a DAG checker before evaluating. So,
the properties that are whitelisted are the properties that always get a
DAG checker set on them before they are evaluated.
When linking to a target, the INTERFACE_LINK_LIBRARIES are automatically
used too. The content of the INTERFACE_LINK_LIBRARIES is assumed to be
mandatory, so this makes sense.
Okay. I'd prefer the term transitive to chains. The latter is
already used in our source for a different meaning (target prop chains to
dir prop).
That's fine with me.
For backwards compatibility, the debug and optimized keywords are also
processed into generator expressions using $CONFIG:
Nice. However:
+ else if (llt == OPTIMIZED)
+{
+l = std::string($CONFIG:Release:) + l + std::string();
+}
The optimized keyword is not just for Release. It is really not
debug. Look at how the llt is used elsewhere to be sure.
Ok, that should be workable too with $NOT. I'll have a look at the other
uses of llt.
A side-effect of using generator expressions in the LINK_LIBRARIES
property in this way is that all libraries will appear to be in the link
implementation, and may appear again when processing the link interface.
I don't know the consequences of that, if any.
Can you explain that in more detail, please?
add_library(foo ...)
add_library(bar ...)
add_library(blub ...)
add_executable(exe ...)
target_link_libraries(bar LINK_PUBLIC foo)
# bar LINK_LIBRARIES is now:
# foo;$TARGET_PROPERTY:foo,INTERFACE_LINK_LIBRARIES
# bar INTERFACE_LINK_LIBRARIES is now:
# foo;$TARGET_PROPERTY:foo,INTERFACE_LINK_LIBRARIES
target_link_libraries(blub LINK_PUBLIC bar)
# blub LINK_LIBRARIES is now
# bar;$TARGET_PROPERTY:bar,INTERFACE_LINK_LIBRARIES
# blub INTERFACE_LINK_LIBRARIES is now
# bar;$TARGET_PROPERTY:bar,INTERFACE_LINK_LIBRARIES
target_link_libraries(exe LINK_PUBLIC blub)
# exe LINK_LIBRARIES is now
# blub;$TARGET_PROPERTY:blub,INTERFACE_LINK_LIBRARIES
In the interface-target-properties branch,
cmTarget::GetOriginalLinkLibraries(const char *) for the 'exe' target will
return 'blub;bar;foo'.
It's my understanding from reading the code that before generator
expressions become available in the LINK_LIBRARIES property, it would return
only 'blub'. The other libraries would be retrieved through the
LINK_INTERFACE_LIBRARIES in cmTarget::ComputeLinkInterface and populate the
LinkInterface.Libraries and a dependency graph would be calculated for
'exe'.
In my branch, the LinkInterface.Libraries would probably still get the same
content as before, but now everything in there is a duplicate of what's
already in the 'original' link libraries. That have consequences, but I'm
not certain.
I've also
Re: [CMake] Running library tests under MSVC2010
It isn't as bad as I might have made it sound. e.g.:
add_executable(mytest test.cpp)
set_target_properties(mytest PROPERTIES RUNTIME_OUTPUT_DIRECTORY
${CMAKE_BINARY_DIR})
add_test(mytest ${CMAKE_BINARY_DIR}/mytest)
On unix (I'm not sure about all but at least on gnu linux) CMake
tweaks by embedding library paths into executables (RPATH) which
allows the OS to use those paths at runtime.
As far as I know there is no equivalent feature on windows(?)
Nils
On 10/20/2012 01:21 PM, Martin Sustrik wrote:
On 19/10/12 11:14, Nils Gladitz wrote:
I use ${CMAKE_BINARY_DIR} in my RUNTIME_OUTPUT_DIRECTORY and also in my
explicit test paths in add_test.
I function wrapped the add_executable and add_test calls to take care of
it so the test definitions themselves are more compact and readable.
Ok. However, what I need seems to be the most basic use case: build a
library and run some tests.
Any way to do that without all the tweaks?
For example, on UNIX platforms everything works OK with no tweaks
whatsoever.
Martin
--
Nils Gladitz, B.Sc.
DICOM, Konnektivität und Entwicklung
Scivis wissenschaftliche Bildverarbeitung GmbH
Bertha-von-Suttner-Str. 5
D-37085 Göttingen
GERMANY
Handelsregister Nr. / Trade Register No. B3100 Göttingen
Geschäftsführer / Managing Directors Dr. Gernot Ebel, Dr. Uwe Engeland
Tel: 0049 (0)551 634181-28
E-Mail: glad...@scivis.de
Web: www.scivis.de
--
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] Continue install after a failure
Hi Andreas, thanks for your tip. Unfortunately, 'make -k install' doesn't help, as the entire install step is a single command (cmake -P ...), so once this fails, there is no other command make could continue with. Is there no way to do this natively in cmake? I could (in theory) add OPTIONAL to all install() commands, but that has the problem of being absolutely silent when a file is not found, and I'd need at least a message or warning. Is cmake really all-or-nothing in this aspect, or does anyone know a feature I'm overlooking? Thanks for any help. Petr On Sat, Oct 20, 2012 at 12:46 PM, Andreas Pakulat ap...@gmx.de wrote: Hi, On Sat, Oct 20, 2012 at 11:39 AM, Petr Kmoch petr.km...@gmail.com wrote: when running the install step of a CMake-generated buildsystem (i.e. 'make install' or building the VS project INSTALL), the run terminates after the first failure (e.g. when it cannot find a file which is to be installed). Is there a way to globally change this behaviour so that the error is reported (perhaps as a warning), but the install step goes on? For Makefile Generator you can run make -k install, that way make keeps on going even when errors occur. No idea about VS, NMake, Ninja or XCode generators probably depends on wether the respective tool has a switch for continuing if errors occur. Andreas -- 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] CMake rebuilds every time
I am sorry I missed your response. Here are the details: 1. I have a shell / batch script which does two things: a. cd build_dir cmake $SRC_PATH b. make # On Unix On Windows, for step b., we run devenv proj.sln /Build Release|x86 /out logfile_path Here is the top level CMakeLists.txt: http://pastebin.com/QWG4wSuf Here is a CMakeLists.txt in one of the subdirs: http://pastebin.com/QYGCpH7k These are fairly representative of how the CMakeLists.txt are. Regards, Arindam On Tue, Oct 16, 2012 at 9:04 PM, David Cole david.c...@kitware.com wrote: What does your CMakeLists look like? Only the necessary rebuild steps should be taken on an incremental build. How do you invoke a rebuild? (Just typing 'make' or some other mechanism?) On Mon, Oct 15, 2012 at 6:22 AM, Arindam Mukherjee arindam.muker...@gmail.com wrote: Hi, I have a cross-platform build setup using cmake 2.8.9 which builds on 5 different OSs. However it rebuilds every time even when neither the Makefile timestamps nor the source file timastamps had changed. Examining the generated Makefiles I can see that all .o, .i and .s targets have been marked .PHONY. Don't know if this is the reason for it. How to fix this to not rebuild every time but do incremental builds? Thanks, Arindam -- 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] CMake rebuilds every time
On Mon, Oct 22, 2012 at 4:06 PM, Arindam Mukherjee arindam.muker...@gmail.com wrote: I am sorry I missed your response. Here are the details: 1. I have a shell / batch script which does two things: a. cd build_dir cmake $SRC_PATH b. make # On Unix On Windows, for step b., we run devenv proj.sln /Build Release|x86 /out logfile_path Here is the top level CMakeLists.txt: http://pastebin.com/QWG4wSuf Here is a CMakeLists.txt in one of the subdirs: http://pastebin.com/QYGCpH7k These are fairly representative of how the CMakeLists.txt are. I should have added - we have source files with extension .C (i.e. .C in caps) and these are meant to be C++ sources. Regards, Arindam On Tue, Oct 16, 2012 at 9:04 PM, David Cole david.c...@kitware.com wrote: What does your CMakeLists look like? Only the necessary rebuild steps should be taken on an incremental build. How do you invoke a rebuild? (Just typing 'make' or some other mechanism?) On Mon, Oct 15, 2012 at 6:22 AM, Arindam Mukherjee arindam.muker...@gmail.com wrote: Hi, I have a cross-platform build setup using cmake 2.8.9 which builds on 5 different OSs. However it rebuilds every time even when neither the Makefile timestamps nor the source file timastamps had changed. Examining the generated Makefiles I can see that all .o, .i and .s targets have been marked .PHONY. Don't know if this is the reason for it. How to fix this to not rebuild every time but do incremental builds? Thanks, Arindam -- 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] help with cmake_parse_arguments
Eric Do you happen to know what docs you were looking at? It may be worth a little bit to post that to this mailing list so that hopefully the person that wrote those docs could be so kind as to update them with the correct syntax. I can't find the ones I was looking at before. But hopefully no one else will make the same mistake :) JB -- 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] CMake rebuilds every time
On Mon, Oct 22, 2012 at 6:38 AM, Arindam Mukherjee arindam.muker...@gmail.com wrote: On Mon, Oct 22, 2012 at 4:06 PM, Arindam Mukherjee arindam.muker...@gmail.com wrote: I am sorry I missed your response. Here are the details: 1. I have a shell / batch script which does two things: a. cd build_dir cmake $SRC_PATH b. make # On Unix On Windows, for step b., we run devenv proj.sln /Build Release|x86 /out logfile_path Here is the top level CMakeLists.txt: http://pastebin.com/QWG4wSuf Here is a CMakeLists.txt in one of the subdirs: http://pastebin.com/QYGCpH7k These are fairly representative of how the CMakeLists.txt are. I should have added - we have source files with extension .C (i.e. .C in caps) and these are meant to be C++ sources. Regards, Arindam On Tue, Oct 16, 2012 at 9:04 PM, David Cole david.c...@kitware.com wrote: What does your CMakeLists look like? Only the necessary rebuild steps should be taken on an incremental build. How do you invoke a rebuild? (Just typing 'make' or some other mechanism?) On Mon, Oct 15, 2012 at 6:22 AM, Arindam Mukherjee arindam.muker...@gmail.com wrote: Hi, I have a cross-platform build setup using cmake 2.8.9 which builds on 5 different OSs. However it rebuilds every time even when neither the Makefile timestamps nor the source file timastamps had changed. Examining the generated Makefiles I can see that all .o, .i and .s targets have been marked .PHONY. Don't know if this is the reason for it. How to fix this to not rebuild every time but do incremental builds? Thanks, Arindam -- 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 The *.C files will only be seen as C files on Windows because the file system is case insensitive, so there is no difference between c and C... Use .cpp or .cxx to name C++ source files. -- 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] Running library tests under MSVC2010
Hi Nils,
It isn't as bad as I might have made it sound. e.g.:
add_executable(mytest test.cpp)
set_target_properties(mytest PROPERTIES RUNTIME_OUTPUT_DIRECTORY
${CMAKE_BINARY_DIR})
add_test(mytest ${CMAKE_BINARY_DIR}/mytest)
Yes. Everything works OK now. My question was more of a theoretical
interest...
On unix (I'm not sure about all but at least on gnu linux) CMake
tweaks by embedding library paths into executables (RPATH) which
allows the OS to use those paths at runtime.
As far as I know there is no equivalent feature on windows(?)
The reason why I expected it to just work under MSVC is that when
working with MSVC without CMake, creating a dependency in test on the
library makes test automatically load the library even though it is not
on the system path. I have no idea how it works, I would expect MSVC IDE
simply to add relevant library to the path when running the test.
Anyway, with CMake-generated solution this doesn't seem to work. The
dependency is generated as expected, however, when trying to run the
test MSVC is unable to find the library.
Martin
--
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] INCLUDE_DIRECTORIES (command vs target property)
Hello,
The target property INCLUDE_DIRECTORIES overwrites the
include_directories command values.
A better way would have been that the values of the include_directories
command would appended to the values of the target property
INCLUDE_DIRECTORIES.
I think that would make more sense.
INCLUDE_DIRECTORIES(general_include_directories)
# Projet A
...
SET_TARGET_PROPERTIES(ProA PROPERTIES
INCLUDE_DIRECTORIES ${ProjAIncludeDirs})
...
# Projet B
...
SET_TARGET_PROPERTIES(ProB PROPERTIES
INCLUDE_DIRECTORIES ${ProjBIncludeDirs})
...
Grettings
Micha Renner
--
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] using find_library with a ExternalProject
On 10/21/2012 10:20 PM, Ian Monroe wrote:
So I had code like:
include(ExternalProject)
ExternalProject_Add(
mockcpp
DOWNLOAD_COMMAND hg clonessh://h...@bitbucket.org/godsme/mockcpp
CMAKE_ARGS -DCMAKE_INSTALL_PREFIX=${MOCKCPP_PREFIX}
UPDATE_COMMAND hg pull
)
find_library(MOCKCPP_LIBRARY
NAMES
mockcpp
PATHS
${MOCKCPP_PREFIX}/lib
NO_DEFAULT_PATH)
This worked just fine until I used it on a fresh build. Then cmake
wouldn't finish since at cmake-time the library doesn't exist.
This is a limitation of External project, you can not mix external
project with non-external project CMake code and have it work in a
portable manner. Since external project defers download, configure and
build until build time, there is nothing for the find_library to find at
configure time because the code is not even there in many cases.
The way to do it is to change the rest of the project into external
projects:
ExternalProject_Add(mockcpp)
ExternalProject_Add(MyProject)
Inside MyProject, you call find_library because mockcpp will be
downloaded, configured, and built by then.
-Bill
--
Bill Hoffman
Kitware, Inc.
28 Corporate Drive
Clifton Park, NY 12065
bill.hoff...@kitware.com
http://www.kitware.com
518 881-4905 (Direct)
518 371-3971 x105
Fax (518) 371-4573
--
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] INCLUDE_DIRECTORIES (command vs target property)
If you want to APPEND, then use set_property with APPEND.
http://cmake.org/cmake/help/v2.8.9/cmake.html#command:set_property
HTH,
David
On Mon, Oct 22, 2012 at 9:05 AM, Micha Renner micha.ren...@t-online.de wrote:
Hello,
The target property INCLUDE_DIRECTORIES overwrites the
include_directories command values.
A better way would have been that the values of the include_directories
command would appended to the values of the target property
INCLUDE_DIRECTORIES.
I think that would make more sense.
INCLUDE_DIRECTORIES(general_include_directories)
# Projet A
...
SET_TARGET_PROPERTIES(ProA PROPERTIES
INCLUDE_DIRECTORIES ${ProjAIncludeDirs})
...
# Projet B
...
SET_TARGET_PROPERTIES(ProB PROPERTIES
INCLUDE_DIRECTORIES ${ProjBIncludeDirs})
...
Grettings
Micha Renner
--
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] Continue install after a failure
On Mon, Oct 22, 2012 at 3:22 AM, Petr Kmoch petr.km...@gmail.com wrote: Hi Andreas, thanks for your tip. Unfortunately, 'make -k install' doesn't help, as the entire install step is a single command (cmake -P ...), so once this fails, there is no other command make could continue with. Is there no way to do this natively in cmake? I could (in theory) add OPTIONAL to all install() commands, but that has the problem of being absolutely silent when a file is not found, and I'd need at least a message or warning. Is cmake really all-or-nothing in this aspect, or does anyone know a feature I'm overlooking? Thanks for any help. Petr On Sat, Oct 20, 2012 at 12:46 PM, Andreas Pakulat ap...@gmx.de wrote: Hi, On Sat, Oct 20, 2012 at 11:39 AM, Petr Kmoch petr.km...@gmail.com wrote: when running the install step of a CMake-generated buildsystem (i.e. 'make install' or building the VS project INSTALL), the run terminates after the first failure (e.g. when it cannot find a file which is to be installed). Is there a way to globally change this behaviour so that the error is reported (perhaps as a warning), but the install step goes on? For Makefile Generator you can run make -k install, that way make keeps on going even when errors occur. No idea about VS, NMake, Ninja or XCode generators probably depends on wether the respective tool has a switch for continuing if errors occur. Andreas -- 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 is all-or-nothing with respect to an install tree. If the cmake install script hits a FATAL_ERROR message then it stops and will not continue beyond that point... The best way to Continue install after a failure is to eliminate the failure, and try again. HTH, David -- 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] CMake 2.8.8 Upgrade problem with Xcode on OS X 10.8
Just following up after a little while... On Sat, 8 Sep 2012 10:48:11 -0400, David Cole said: Does this happen regardless of which Xcode you select, or only with the -DP4 one? Happens with any of them. Does this still happen for you if you use CMake from the 'next' branch? Seems fixed in 2.8.10rc2 BTW. Cheers, -- Sean McBride, B. Eng s...@rogue-research.com Rogue Researchwww.rogue-research.com Mac Software Developer Montréal, Québec, Canada -- 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] CMake 2.8.8 Upgrade problem with Xcode on OS X 10.8
On Mon, Oct 22, 2012 at 11:26 AM, Sean McBride s...@rogue-research.com wrote: Just following up after a little while... On Sat, 8 Sep 2012 10:48:11 -0400, David Cole said: Does this happen regardless of which Xcode you select, or only with the -DP4 one? Happens with any of them. Does this still happen for you if you use CMake from the 'next' branch? Seems fixed in 2.8.10rc2 BTW. Excellent -- thanks for trying with rc2 and updating us here. Cheers, -- Sean McBride, B. Eng s...@rogue-research.com Rogue Researchwww.rogue-research.com Mac Software Developer Montréal, Québec, Canada -- 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] cmake trouble
Hello:
I am using cmake for three months now.
but was trouble in a situation 。for details bellow: (in Windows,using Microsoft
Visual Studio 2008)
ADD_LIBRARY(test SHARED ${LIBTEST_SRC} ${LIBHELLO_SRC})
#ADD_LIBRARY(test STATIC ${LIBTEST_SRC} ${LIBHELLO_SRC})
#add executable
AUX_SOURCE_DIRECTORY(. FAN_SRC)
TARGET_LINK_LIBRARIES(fan test)
ADD_EXECUTABLE(fan ${FAN_SRC})
1.if i put TARGET_LINK_LIBRARIES(fan test) before ADD_EXECUTABLE command,this
does not work ,why??
2. but if i ADD_LIBRARY(test STATIC ${LIBTEST_SRC} ${LIBHELLO_SRC}) ，it is
ok，why ??
3.if i put TARGET_LINK_LIBRARIES(fan test) after ADD_EXECUTABLE command，it
works ,why ??
I am waiting for your help !!
With best wishes.
--
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] cmake trouble
Hi,
On Mon, Oct 22, 2012 at 5:35 PM, 张峰 fangler2...@126.com wrote:
1.if i put TARGET_LINK_LIBRARIES(fan test) before ADD_EXECUTABLE
command,this does not work ,why??
Because until yout call add_executable(), the target name doesn't exist.
You have to use the target name as first parameter of
target_link_libraries().
2. but if i ADD_LIBRARY(test STATIC ${LIBTEST_SRC} ${LIBHELLO_SRC}) ，it
is ok，why ??
I don't understand the question.
3.if i put TARGET_LINK_LIBRARIES(fan test) after ADD_EXECUTABLE
command，it works ,why ??
For the reason I explained in 1.
Joel 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
[CMake] CPack: Project and independent subproject
Hello everyone,
My c++ project contains a Library folder, an Applications folder and a
Demos folder like this:
Project/
|- Library/
|- include/
|- src/
|- Applications/
|- appliA/
|- include/
|- src/
...
|- Demos/
|- demoA/
|- include/
|- src/
...
The applications and demos use the Library (which is a static library).
I can build all the application correctly in different level (directly
inside demoA/ for example or in Project/).
I create custom target to build my package: demoA-package,
demoA-package_source
My problem is when I want to create a package (tar.gz, dmg, nsis or
others...), I can't figure how to put just the executable of demosA
inside the package: I have all the executable and the library.
This is a part of my CMakeLists.txt:
install(TARGETS ${PROJECT_NAME}
DESTINATION Demos
COMPONENT ${PROJECT_NAME})
set(CPACK_PACKAGE_NAME ${PROJECT_NAME})
set(CPACK_PACKAGE_VENDOR Me)
set(CPACK_PACKAGE_DESCRIPTION_SUMMARY Example test framework: demos
${PROJECT_NAME})
set(CPACK_PACKAGE_VERSION_MAJOR 1)
set(CPACK_PACKAGE_VERSION_MINOR 0)
set(CPACK_PACKAGE_VERSION_PATCH 0)
set(CPACK_PACKAGE_VERSION
${CPACK_PACKAGE_VERSION_MAJOR}.${CPACK_PACKAGE_VERSION_MINOR}.${CPACK_PACKAGE_VERSION_PATCH})
set(CPACK_SOURCE_IGNORE_FILES
/bin/;/.svn/;/.git/;${CPACK_SOURCE_IGNORE_FILES})
set(CPACK_OUTPUT_CONFIG_FILE
${CMAKE_CURRENT_BINARY_DIR}/CPackConfig.cmake)
set(CPACK_SOURCE_OUTPUT_CONFIG_FILE
${CMAKE_CURRENT_BINARY_DIR}/CPackSourceConfig.cmake)
add_custom_target(${PROJECT_NAME}-package cpack --config
${CPACK_OUTPUT_CONFIG_FILE})
add_custom_target(${PROJECT_NAME}-package_source cpack --config
${CPACK_SOURCE_OUTPUT_CONFIG_FILE})
include(CPack)
cpack_add_component(${PROJECT_NAME}
DISPLAY_NAME ${PROJECT_NAME})
I searched some methods to put the wanted files inside a package but I
only found how to ignore some files.
Does anyone have those kind of problem?
Thanks,
Romain
--
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] cmake trouble
Hello:
I am using cmake for three months now.
but was trouble in a situation 。for details bellow: (in Windows)
ADD_LIBRARY(test SHARED ${LIBTEST_SRC} ${LIBHELLO_SRC})
#ADD_LIBRARY(test STATIC ${LIBTEST_SRC} ${LIBHELLO_SRC})
#add executable
AUX_SOURCE_DIRECTORY(. FAN_SRC)
TARGET_LINK_LIBRARIES(fan test)
ADD_EXECUTABLE(fan ${FAN_SRC})
1.if i put TARGET_LINK_LIBRARIES(fan test) before ADD_EXECUTABLE command,this
does not work ,why??
2. but if i ADD_LIBRARY(test STATIC ${LIBTEST_SRC} ${LIBHELLO_SRC}) ，it is
ok，why ??
3.if i put TARGET_LINK_LIBRARIES(fan test) after ADD_EXECUTABLE command，it
works ,why ??
I am waiting for your help !!
With best wishes.
--
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] cmake trouble
Hello,
First off, you cannot call both add_executable and add_library in the same
CMakeLists file. Here is what I can say about your other questions:
1. All commands that require a target have to come after you have created
the target via add_executable or add_library. This is simply because you need
to have a target before you can adds things to it.
2. I am not real sure why this would work. But, for common practices, you
should always call target_link_libraries after your call to add_library or
add_executable for the reason stated above.
3. Again, this is the same answer. It will work as long as you make the
call to the command after add_library or add_executable.
Hope this helps.
Eric
From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of ??
Sent: Monday, October 22, 2012 10:25 AM
To: cmake@cmake.org
Subject: [CMake] cmake trouble
Hello:
I am using cmake for three months now.
but was trouble in a situation 。for details bellow: (in Windows)
ADD_LIBRARY(test SHARED ${LIBTEST_SRC} ${LIBHELLO_SRC})
#ADD_LIBRARY(test STATIC ${LIBTEST_SRC} ${LIBHELLO_SRC})
#add executable
AUX_SOURCE_DIRECTORY(. FAN_SRC)
TARGET_LINK_LIBRARIES(fan test)
ADD_EXECUTABLE(fan ${FAN_SRC})
1.if i put TARGET_LINK_LIBRARIES(fan test) before ADD_EXECUTABLE command,this
does not work ,why??
2. but if i ADD_LIBRARY(test STATIC ${LIBTEST_SRC} ${LIBHELLO_SRC}) ，it is
ok，why ??
3.if i put TARGET_LINK_LIBRARIES(fan test) after ADD_EXECUTABLE command，it
works ,why ??
I am waiting for your help !!
With best
wishes.app:lj:%E6%AD%A4%E8%87%B4%E6%95%AC%E7%A4%BC?ljtype=blngljblngcont=0ljtran=With%20best%20%20wishes.
--
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] using find_library with a ExternalProject
On Mon, Oct 22, 2012 at 6:07 AM, Bill Hoffman bill.hoff...@kitware.com wrote:
On 10/21/2012 10:20 PM, Ian Monroe wrote:
So I had code like:
include(ExternalProject)
ExternalProject_Add(
mockcpp
DOWNLOAD_COMMAND hg clonessh://h...@bitbucket.org/godsme/mockcpp
CMAKE_ARGS -DCMAKE_INSTALL_PREFIX=${MOCKCPP_PREFIX}
UPDATE_COMMAND hg pull
)
find_library(MOCKCPP_LIBRARY
NAMES
mockcpp
PATHS
${MOCKCPP_PREFIX}/lib
NO_DEFAULT_PATH)
This worked just fine until I used it on a fresh build. Then cmake
wouldn't finish since at cmake-time the library doesn't exist.
This is a limitation of External project, you can not mix external project
with non-external project CMake code and have it work in a portable manner.
Since external project defers download, configure and build until build
time, there is nothing for the find_library to find at configure time
because the code is not even there in many cases.
The way to do it is to change the rest of the project into external
projects:
ExternalProject_Add(mockcpp)
ExternalProject_Add(MyProject)
Inside MyProject, you call find_library because mockcpp will be downloaded,
configured, and built by then.
So what was the target use-case for ExternalProject? From the name it
sounds like it was meant exactly for making your non-external project
(aka your project) be able to pull in dependencies from external
projects.
To make the project itself an external project gives up a lot of
flexibility in cmake configuration. And would just plan mess up my
source tree. :)
Ian
--
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] ctest - run commands before and after tests run
At CMake/Testing With CTest Wiki page (http://www.cmake.org/Wiki/CMake_Testing_With_CTest), it is mentioned that: CTest has several additional features that include: ... Customization of the testing by providing: ... Ability to run commands before and after tests are run I need to do something alike: to be able to run small program before any of tests are run on make test, that will gather some system info (in my particular case, number of GPUs available on system), and then make this info somehow available (best way would be through command line arguments) to test programs specified in my add_test() commands. Is this possible, and how? Thanks. -- 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] using find_library with a ExternalProject
On 10/22/2012 12:34 PM, Ian Monroe wrote: So what was the target use-case for ExternalProject? From the name it sounds like it was meant exactly for making your non-external project (aka your project) be able to pull in dependencies from external projects. The target use case was to create a simple way to build large complicated projects that depend on lots of third party software. http://www.kitware.com/media/html/BuildingExternalProjectsWithCMake2.8.html To make the project itself an external project gives up a lot of flexibility in cmake configuration. And would just plan mess up my source tree.:) Yes, and no. It still creates a direct cmake project for your project. You can use the external project to create a super build for your project. This could be used to bootstrap and setup a project with all of its depends. Then you can work directly in the project after the initial configuration. Because the source in most times does not even exist, it would be impossible for the find_* stuff to find anything. This is just how it works. -Bill -- 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] cmake trouble
Hi, On Mon, Oct 22, 2012 at 6:04 PM, Eric Clark ecl...@ara.com wrote: First off, you cannot call both add_executable and add_library in the same CMakeLists file. I think there's something missing here, but its perfectly possible to have one or more library and executable targets specified in the same cmake file. So this works just fine: add_library(foo bar.cpp) add_executable(bar foo.cpp) There are build-systems that have such limitations, but cmake is not one. Andreas -- 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] cmake trouble
Eric Clark wrote: Hello, First off, you cannot call both add_executable and add_library in the same CMakeLists file. Here is what I can say about your other questions: Of course you can. 1. All commands that require a target have to come after you have created the target via add_executable or add_library. This is simply because you need to have a target before you can adds things to it. That is indeed correct. Eike -- signature.asc Description: This is a digitally signed message part. -- 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] cmake trouble
-Original Message- From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of Rolf Eike Beer Sent: Monday, October 22, 2012 12:11 PM To: cmake@cmake.org Subject: Re: [CMake] cmake trouble Eric Clark wrote: Hello, First off, you cannot call both add_executable and add_library in the same CMakeLists file. Here is what I can say about your other questions: Of course you can. Yes, but only if you call project() twice, correct? Maybe I should have been more specific. What I meant was that you cannot create two targets for the same project (i.e you cannot build an executable and a dll in the same project). In the code that was posted, there was no call to project between the call to add_library and add_executable. Certainly there is nothing wrong with calling project more than once in a list file, but I have found that it is a rare case that you want to do this... This could be just my experience, but I can only speak for what I know. I should have been more specific, but if you are going to say of course you can, you should probably also explain that this means you need two calls to project() as well because the code that was posted did not have two calls to project as far as what he posted... Please, feel free to correct me if I am wrong here... But, I tried this once and it did not work and after seeing what I had done, it didn't make sense either... Thanks, Eric 1. All commands that require a target have to come after you have created the target via add_executable or add_library. This is simply because you need to have a target before you can adds things to it. That is indeed correct. Eike -- -- 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] cmake trouble
Andreas, I just replied to a message from another gentleman on here and I may be way off base. But, I tried to do this once and it did not work. The only way that I could get it to work was to add another project() call between the two... I could have had some other issues because it has been quite a while since I had this problem and I do not remember the specific error that I got, so I am by no means saying anyone is wrong because I am sure that many of you are way more familiar with CMake than I am, this is a learning experience for me as well. I was just trying to help the guy out and when I looked at his original posting I saw test as the same name being passed to add_executable and add_library... I went back to look at the code again and he did have one called test and the other called fan that was my mistake and my misreading it. My apologies for saying the wrong thing, I was only trying to help... Eric -Original Message- From: Andreas Pakulat [mailto:ap...@gmx.de] Sent: Monday, October 22, 2012 12:17 PM To: Eric Clark Cc: 张峰; cmake@cmake.org Subject: Re: [CMake] cmake trouble Hi, On Mon, Oct 22, 2012 at 6:04 PM, Eric Clark ecl...@ara.com wrote: First off, you cannot call both add_executable and add_library in the same CMakeLists file. I think there's something missing here, but its perfectly possible to have one or more library and executable targets specified in the same cmake file. So this works just fine: add_library(foo bar.cpp) add_executable(bar foo.cpp) There are build-systems that have such limitations, but cmake is not one. Andreas -- 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] cmake trouble
-Original Message- From: Andreas Pakulat [mailto:ap...@gmx.de] Sent: Monday, October 22, 2012 12:17 PM To: Eric Clark Cc: 张峰; cmake@cmake.org Subject: Re: [CMake] cmake trouble Hi, On Mon, Oct 22, 2012 at 6:04 PM, Eric Clark ecl...@ara.com wrote: First off, you cannot call both add_executable and add_library in the same CMakeLists file. I think there's something missing here, but its perfectly possible to have one or more library and executable targets specified in the same cmake file. So this works just fine: add_library(foo bar.cpp) add_executable(bar foo.cpp) Sorry, me again, but I have a question... If I do use the above code using a Visual Studio generator, will this create to separate projects in Visual Studio? There are build-systems that have such limitations, but cmake is not one. Andreas -- 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] cmake trouble
Eric Clark wrote: From: Andreas Pakulat [mailto:ap...@gmx.de] On Mon, Oct 22, 2012 at 6:04 PM, Eric Clark ecl...@ara.com wrote: First off, you cannot call both add_executable and add_library in the same CMakeLists file. I think there's something missing here, but its perfectly possible to have one or more library and executable targets specified in the same cmake file. So this works just fine: add_library(foo bar.cpp) add_executable(bar foo.cpp) Sorry, me again, but I have a question... If I do use the above code using a Visual Studio generator, will this create to separate projects in Visual Studio? You will have one solution file, but 2 projects in it. Eike -- signature.asc Description: This is a digitally signed message part. -- 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] cmake trouble
Eric Clark wrote: Eric Clark wrote: Hello, First off, you cannot call both add_executable and add_library in the same CMakeLists file. Here is what I can say about your other questions: Of course you can. Yes, but only if you call project() twice, correct? No, even if you don't call project at all (but you need to call project() in a higher level CMakeLists.txt then). Maybe I should have been more specific. What I meant was that you cannot create two targets for the same project (i.e you cannot build an executable and a dll in the same project). In the code that was posted, there was no call to project between the call to add_library and add_executable. Certainly there is nothing wrong with calling project more than once in a list file, but I have found that it is a rare case that you want to do this... This could be just my experience, but I can only speak for what I know. The only thing that does not work then is the projectname_SOURCE_DIR variable that is set by CMake when you call project(). But otherwise everything is fine. Eike -- signature.asc Description: This is a digitally signed message part. -- 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] cmake trouble
-Original Message- From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of Rolf Eike Beer Sent: Monday, October 22, 2012 12:48 PM To: cmake@cmake.org Subject: Re: [CMake] cmake trouble Eric Clark wrote: From: Andreas Pakulat [mailto:ap...@gmx.de] On Mon, Oct 22, 2012 at 6:04 PM, Eric Clark ecl...@ara.com wrote: First off, you cannot call both add_executable and add_library in the same CMakeLists file. I think there's something missing here, but its perfectly possible to have one or more library and executable targets specified in the same cmake file. So this works just fine: add_library(foo bar.cpp) add_executable(bar foo.cpp) Sorry, me again, but I have a question... If I do use the above code using a Visual Studio generator, will this create to separate projects in Visual Studio? You will have one solution file, but 2 projects in it. Thank you Eike! Forgive my ignorance here... but what will it use to name the two projects? Eike -- -- 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] cmake trouble
Eric Clark wrote: -Original Message- From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of Rolf Eike Beer Sent: Monday, October 22, 2012 12:48 PM To: cmake@cmake.org Subject: Re: [CMake] cmake trouble Eric Clark wrote: From: Andreas Pakulat [mailto:ap...@gmx.de] On Mon, Oct 22, 2012 at 6:04 PM, Eric Clark ecl...@ara.com wrote: First off, you cannot call both add_executable and add_library in the same CMakeLists file. I think there's something missing here, but its perfectly possible to have one or more library and executable targets specified in the same cmake file. So this works just fine: add_library(foo bar.cpp) add_executable(bar foo.cpp) Sorry, me again, but I have a question... If I do use the above code using a Visual Studio generator, will this create to separate projects in Visual Studio? You will have one solution file, but 2 projects in it. Thank you Eike! Forgive my ignorance here... but what will it use to name the two projects? The name of the target, i.e. the first argument to add_library() and add_executable(). Eike -- signature.asc Description: This is a digitally signed message part. -- 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] cmake trouble
-Original Message- From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of Rolf Eike Beer Sent: Monday, October 22, 2012 12:51 PM To: cmake@cmake.org Subject: Re: [CMake] cmake trouble Eric Clark wrote: -Original Message- From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of Rolf Eike Beer Sent: Monday, October 22, 2012 12:48 PM To: cmake@cmake.org Subject: Re: [CMake] cmake trouble Eric Clark wrote: From: Andreas Pakulat [mailto:ap...@gmx.de] On Mon, Oct 22, 2012 at 6:04 PM, Eric Clark ecl...@ara.com wrote: First off, you cannot call both add_executable and add_library in the same CMakeLists file. I think there's something missing here, but its perfectly possible to have one or more library and executable targets specified in the same cmake file. So this works just fine: add_library(foo bar.cpp) add_executable(bar foo.cpp) Sorry, me again, but I have a question... If I do use the above code using a Visual Studio generator, will this create to separate projects in Visual Studio? You will have one solution file, but 2 projects in it. Thank you Eike! Forgive my ignorance here... but what will it use to name the two projects? The name of the target, i.e. the first argument to add_library() and add_executable(). Awesome! Thank you for the answers and the quick reply! I have only been using CMake for a little over a year and again I am sorry for posting an incorrect answer. I always thought that I had to have one project() call for each add_executable and/or add_library. It is very good to know that that is not the case. However, I am curious if you think it is good practice to do such a thing? Eike -- -- 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] CMake-based build systems that are useful for study purposes?
On 2012-10-22 17:55- Eric Clark wrote: Awesome! Thank you for the answers and the quick reply! I have only been using CMake for a little over a year and again I am sorry for posting an incorrect answer. I always thought that I had to have one project() call for each add_executable and/or add_library. It is very good to know that that is not the case. However, I am curious if you think it is good practice to do such a thing? To join this conversation late, but to give it a new twist with a new subject line it is typical practice to have one project() call (done in the top-level CMakeLists.txt file) for each software project (e.g., a complete source tree that is typically distributed as an independent tarball) no matter how many libraries and executables are built for that project. When I first learned CMake years ago I looked at a number of projects with CMake-based build systems to see what was typical usage, and I suggest you might want to do the same. I used to advocate studying the CMake-based build system for PLplot that I helped to implement, but that was essentially done so many years ago (although it is still maintained extensively) that I am sure there are much better best practices out there now especially considering all the additional useful CMake features that have been introduced over the years. I initially did a lot of my learning based on the CMake-based build systems for CMake itself and also for KDE so one of those might be worthy studying now, but they also might have the same problem (too many years of history without necessarily keeping up with best practices) that PLplot does. Are the CMake and KDE build systems still the best paradigms for study or are there better ones for study that can be recommended now? Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- 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] CPack: Project and independent subproject
2012/10/22 Romain LEGUAY romain.leg...@gmail.com:
Hello everyone,
My c++ project contains a Library folder, an Applications folder and a Demos
folder like this:
Project/
|- Library/
|- include/
|- src/
|- Applications/
|- appliA/
|- include/
|- src/
...
|- Demos/
|- demoA/
|- include/
|- src/
...
The applications and demos use the Library (which is a static library).
I can build all the application correctly in different level (directly
inside demoA/ for example or in Project/).
I create custom target to build my package: demoA-package,
demoA-package_source
My problem is when I want to create a package (tar.gz, dmg, nsis or
others...), I can't figure how to put just the executable of demosA inside
the package: I have all the executable and the library.
If you want to have control over what is installed the better to do that
is to create COMPONENT.
This is a part of my CMakeLists.txt:
install(TARGETS ${PROJECT_NAME}
DESTINATION Demos
COMPONENT ${PROJECT_NAME})
like this but I doubt that you can name a COMPONENT with the same
name as the name of your project.
then you must either define:
set(CPACK_INSTALL_CMAKE_PROJECTS
${CMAKE_CURRENT_BINARY_DIR};${PROJECT_NAME};${PROJECT_NAME}:/)
see documentation
cpack --help-variable CPACK_INSTALL_CMAKE_PROJECTS
set(CPACK_PACKAGE_NAME ${PROJECT_NAME})
set(CPACK_PACKAGE_VENDOR Me)
set(CPACK_PACKAGE_DESCRIPTION_SUMMARY Example test framework: demos
${PROJECT_NAME})
set(CPACK_PACKAGE_VERSION_MAJOR 1)
set(CPACK_PACKAGE_VERSION_MINOR 0)
[]
I searched some methods to put the wanted files inside a package but I only
found how to ignore some files.
Does anyone have those kind of problem?
By the does your Demo/ directory have a project(...) command in its
CMakeLists.txt?
--
Erk
Le gouvernement représentatif n'est pas la démocratie --
http://www.le-message.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] bootstrap of cmake 2.8.9 fails on HP-UX PA-RISC
I've hit a snag on an HPPA machine using the HP compiler aCC. This host is HPUX 11.11 on 9000/800. I don't know enough about C++ to make heads or tails of the error message below and searches turn up nothing useful. thanks, Amul - CMake 2.8.9, Copyright 2000-2011 Kitware, Inc. C compiler on this system is: cc C++ compiler on this system is: aCC Makefile processor on this system is: make aCC is not GNU compiler cc does not need -Ae aCC does not have setenv aCC does not have unsetenv aCC does not have environ in stdlib.h aCC does not have STL in std:: namespace aCC does not have ANSI streams aCC has strstream.h aCC has operator!=(string, char*) aCC does not have stl iterator_traits aCC has old iterator_category aCC does not have standard template allocator aCC has old non-template allocator aCC has stl containers supporting allocator objects aCC has header cstddef aCC does not require template friends to use aCC supports member templates aCC has standard template specialization syntax aCC does not have argument dependent lookup aCC does not have struct stat with st_mtim member aCC has ios::binary openmode aCC does not have ANSI for scoping - aCC -I/testarea1/shaha/cmake/cmake-2.8.9/Bootstrap.cmk -I/testarea1/shaha/cmake/cmake-2.8.9/Source -I/testarea1/shaha/cmake/cmake-2.8.9/Bootstrap.cmk -c /testarea1/shaha/cmake/cmake-2.8.9/Source/cmMakefile.cxx -o cmMakefile.o Error 20: /testarea1/shaha/cmake/cmake-2.8.9/Source/cmMakefile.cxx, line 3315 # ';' expected before '::'. std::ios_base::openmode omode = std::ios_base::out | std::ios_base::trunc; ^^ Error 419: /testarea1/shaha/cmake/cmake-2.8.9/Source/cmMakefile.cxx, line 3315 # 'openmode' is used as a type, but has not been defined as a type. std::ios_base::openmode omode = std::ios_base::out | std::ios_base::trunc; Error 172: /testarea1/shaha/cmake/cmake-2.8.9/Source/cmMakefile.cxx, line 3315 # Undeclared variable 'ios_base'. std::ios_base::openmode omode = std::ios_base::out | std::ios_base::t Error 172: /testarea1/shaha/cmake/cmake-2.8.9/Source/cmMakefile.cxx, line 3315 # Undeclared variable 'ios_base'. std::ios_base::openmode omode = std::ios_base::out | std::ios_base::trunc; Error 20: /testarea1/shaha/cmake/cmake-2.8.9/Source/cmMakefile.cxx, line 3315 # ';' expected before '::'. std::ios_base::openmode omode = std::ios_base::out | std::ios_base::trunc; ^^ Error 20: /testarea1/shaha/cmake/cmake-2.8.9/Source/cmMakefile.cxx, line 3315 # ';' expected before '::'. d::ios_base::openmode omode = std::ios_base::out | std::ios_base::trunc; ^^ Error 172: /testarea1/shaha/cmake/cmake-2.8.9/Source/cmMakefile.cxx, line 3315 # Undeclared variable 'out'. std::ios_base::openmode omode = std::ios_base::out | std::ios_base::trunc; _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. -- 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] CMake-based build systems that are useful for study purposes?
Alan, Thank you for such a detailed response. I am pretty new to this mailing list and have only responded to a few questions on here, but I have really thought the responsiveness on here is the best of any of the message boards that I belong to and I really appreciate it, so I like to give back as well. Anyway, the project that I work on is not your typical application. It is a framework and a couple of applications built off of the framework. Each of the applications have a pluggable interface that outside organizations use to build their own plugins/modules that work together to form the End-User Application. We do not actually develop for users, we develop for developers. So, I may be way off base, but when developing this I decided to follow a structure like below: src/CMakeLists.txt project(OurFramework) add_subdirectory(CoreModule1) add_subdirectory(CoreModule2) add_subdirectory(CoreModule3) add_subdirectory(CoreModule4) - End File And then in each of the core module's directory, they would have their own list file like so: - src/CoreModule1/CMakeLists.txt project(CoreModule1) include(CommonConfigurationFile) ... # Add the files here and the stuff specific to this module. -- End File The above is how the core framework is structured. The pluggable applications have a similar structure except that the top-level is not necessarily all of the plugins/modules for the entire application, it may be just a subset. There are ~100 plugins that we develop internally and who knows how many externally. I would love your opinion on what I have done here. Since this being developed for developers, it is always nice to get the developer's (our end-user's) perspective. Do you think I am missing the purpose of the project() command all together? Thanks, Eric -Original Message- From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca] Sent: Monday, October 22, 2012 1:58 PM To: Eric Clark Cc: Rolf Eike Beer; cmake@cmake.org Subject: CMake-based build systems that are useful for study purposes? On 2012-10-22 17:55- Eric Clark wrote: Awesome! Thank you for the answers and the quick reply! I have only been using CMake for a little over a year and again I am sorry for posting an incorrect answer. I always thought that I had to have one project() call for each add_executable and/or add_library. It is very good to know that that is not the case. However, I am curious if you think it is good practice to do such a thing? To join this conversation late, but to give it a new twist with a new subject line it is typical practice to have one project() call (done in the top-level CMakeLists.txt file) for each software project (e.g., a complete source tree that is typically distributed as an independent tarball) no matter how many libraries and executables are built for that project. When I first learned CMake years ago I looked at a number of projects with CMake-based build systems to see what was typical usage, and I suggest you might want to do the same. I used to advocate studying the CMake-based build system for PLplot that I helped to implement, but that was essentially done so many years ago (although it is still maintained extensively) that I am sure there are much better best practices out there now especially considering all the additional useful CMake features that have been introduced over the years. I initially did a lot of my learning based on the CMake-based build systems for CMake itself and also for KDE so one of those might be worthy studying now, but they also might have the same problem (too many years of history without necessarily keeping up with best practices) that PLplot does. Are the CMake and KDE build systems still the best paradigms for study or are there better ones for study that can be recommended now? Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- 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] CMake-based build systems that are useful for study purposes?
On 2012-10-22 20:25- Eric Clark wrote: I would love your opinion on what I have done here. Since this being developed for developers, it is always nice to get the developer's (our end-user's) perspective. Do you think I am missing the purpose of the project() command all together? I am out of my depth here because I have never worked with such a complex collection of projects such as yours. As a general rule, though (as others have said previously) there are no limits to the amount and kind of software you can build and test under one project command. That said, when a project gets too big, it might be useful to split it up into semi-independent units (with one project command each) that can be built separately. I do that myself for two separate software projects that are part of the overall Time Ephemerides project. The first one of those (ephcom) can stand on its own. It builds several different C libraries, utilities that depend on those libraries, and both Fortran and Python bindings for those C libraries (all under on project command). The second one of those projects (te_gen) builds a te_gen Fortran library that depends on the ephcom Fortran bindings library. It also builds quite a few Fortran applications that depend on the te_gen Fortran library. All this is under a second project command. So right now I build, test, and install ephcom by hand then do the same thing for te_gen by hand (with an automatic check in that build system that the installed ephcom can be found). I know there is a way under CMake to automate the build of both the ephcom and te_gen projects from one overall hypothetical Time Ephemerides parent project. I haven't looked further into such a possibility because only two projects are involved, but if you have a lot of different projects with an interesting dependency graph between them, I think automation of the build of each of your projects would be essential. I hope those general ideas help, but I also hope others with more expertise at multi-project software will comment further if I have made some mistakes describing what is possible with the project command. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- 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-commits] CMake branch, master, updated. v2.8.9-578-g9c42e98
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, master has been updated via 9c42e9831d5e73b68467783c74c251b905b103d6 (commit) from df5c1db8c0abf0b82f6b7c1289b0325323517333 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9c42e9831d5e73b68467783c74c251b905b103d6 commit 9c42e9831d5e73b68467783c74c251b905b103d6 Author: Kitware Robot kwro...@kitware.com AuthorDate: Mon Oct 22 00:01:04 2012 -0400 Commit: Kitware Robot kwro...@kitware.com CommitDate: Mon Oct 22 00:01:04 2012 -0400 CMake Nightly Date Stamp diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake index b4971ae..12ab9e9 100644 --- a/Source/CMakeVersion.cmake +++ b/Source/CMakeVersion.cmake @@ -2,5 +2,5 @@ set(CMake_VERSION_MAJOR 2) set(CMake_VERSION_MINOR 8) set(CMake_VERSION_PATCH 9) -set(CMake_VERSION_TWEAK 20121021) +set(CMake_VERSION_TWEAK 20121022) #set(CMake_VERSION_RC 1) --- Summary of changes: Source/CMakeVersion.cmake |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v2.8.9-1178-g4aaeb80
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, next has been updated via 4aaeb805fa8261a9edfbe12f3de562e918a35d8c (commit) via 0cc00b06d807a6cbdd74eb1f8f518c2266eecabc (commit) from 61af3150500ca2657c86268e11dd6f40e3d55b4b (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4aaeb805fa8261a9edfbe12f3de562e918a35d8c commit 4aaeb805fa8261a9edfbe12f3de562e918a35d8c Merge: 61af315 0cc00b0 Author: Brad King brad.k...@kitware.com AuthorDate: Mon Oct 22 13:59:22 2012 -0400 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Mon Oct 22 13:59:22 2012 -0400 Merge topic 'expand-LOCATION-documentation' into next 0cc00b0 Document LOCATION undefined behavior with use of LINKER_LANGUAGE. http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0cc00b06d807a6cbdd74eb1f8f518c2266eecabc commit 0cc00b06d807a6cbdd74eb1f8f518c2266eecabc Author: Stephen Kelly steve...@gmail.com AuthorDate: Fri Oct 19 16:07:01 2012 +0200 Commit: Brad King brad.k...@kitware.com CommitDate: Mon Oct 22 13:59:04 2012 -0400 Document LOCATION undefined behavior with use of LINKER_LANGUAGE. diff --git a/Source/cmDocumentLocationUndefined.h b/Source/cmDocumentLocationUndefined.h index d1be77a..9aecf21 100644 --- a/Source/cmDocumentLocationUndefined.h +++ b/Source/cmDocumentLocationUndefined.h @@ -16,8 +16,8 @@ \n \ Do not set properties that affect the location of a target after \ action . These include properties whose names match \ - \(RUNTIME|LIBRARY|ARCHIVE)_OUTPUT_(NAME|DIRECTORY)(_CONFIG)?\ \ - or \(IMPLIB_)?(PREFIX|SUFFIX)\. \ + \(RUNTIME|LIBRARY|ARCHIVE)_OUTPUT_(NAME|DIRECTORY)(_CONFIG)?\, \ + \(IMPLIB_)?(PREFIX|SUFFIX)\, or \LINKER_LANGUAGE\. \ Failure to follow this rule is not diagnosed and leaves the location \ of the target undefined. --- Summary of changes: hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v2.8.9-1182-g88d77e7
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 88d77e7f29a71f9c583419f184508c5fff822960 (commit)
via e386992152ac3ba5fe2abb66a56ea6ae99d6e8f3 (commit)
via 95d590ddbac80780f437252de4522b78f4069f45 (commit)
via 04421042b3eb5977208929ba01faf7816c2f8f69 (commit)
from 4aaeb805fa8261a9edfbe12f3de562e918a35d8c (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=88d77e7f29a71f9c583419f184508c5fff822960
commit 88d77e7f29a71f9c583419f184508c5fff822960
Merge: 4aaeb80 e386992
Author: Brad King brad.k...@kitware.com
AuthorDate: Mon Oct 22 14:09:50 2012 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Mon Oct 22 14:09:50 2012 -0400
Merge topic 'genex-validate-target-property-names' into next
e386992 GexEx: Validate Target names and property names differently.
95d590d GenEx: Create cmGeneratorTargets for imported targets.
0442104 GenEx: Add an accessor for imported targets in a makefile.
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e386992152ac3ba5fe2abb66a56ea6ae99d6e8f3
commit e386992152ac3ba5fe2abb66a56ea6ae99d6e8f3
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Fri Oct 19 13:11:59 2012 +0200
Commit: Brad King brad.k...@kitware.com
CommitDate: Mon Oct 22 14:05:48 2012 -0400
GexEx: Validate Target names and property names differently.
In the unit test, use the same IMPORTED_LOCATION trick that
the ExportImport test uses.
diff --git a/Source/cmGeneratorExpressionEvaluator.cxx
b/Source/cmGeneratorExpressionEvaluator.cxx
index 287066a..ee1b60a 100644
--- a/Source/cmGeneratorExpressionEvaluator.cxx
+++ b/Source/cmGeneratorExpressionEvaluator.cxx
@@ -277,8 +277,12 @@ static const struct TargetPropertyNode : public
cmGeneratorExpressionNode
$TARGET_PROPERTY:... expression requires one or two parameters);
return std::string();
}
-cmsys::RegularExpression nameValidator;
-nameValidator.compile(^[A-Za-z0-9_.-]+$);
+cmsys::RegularExpression targetNameValidator;
+// The ':' is supported to allow use with IMPORTED targets. At least
+// Qt 4 and 5 IMPORTED targets use ':' as the namespace delimiter.
+targetNameValidator.compile(^[A-Za-z0-9_.:-]+$);
+cmsys::RegularExpression propertyNameValidator;
+propertyNameValidator.compile(^[A-Za-z0-9_]+$);
cmGeneratorTarget* target = context-Target;
std::string propertyName = *parameters.begin();
@@ -301,9 +305,9 @@ static const struct TargetPropertyNode : public
cmGeneratorExpressionNode
std::string targetName = parameters.front();
propertyName = parameters[1];
- if (!nameValidator.find(targetName.c_str()))
+ if (!targetNameValidator.find(targetName.c_str()))
{
-if (!nameValidator.find(propertyName.c_str()))
+if (!propertyNameValidator.find(propertyName.c_str()))
{
::reportError(context, content-GetOriginalExpression(),
Target name and property name not supported.);
@@ -335,7 +339,7 @@ static const struct TargetPropertyNode : public
cmGeneratorExpressionNode
return std::string();
}
-if (!nameValidator.find(propertyName.c_str()))
+if (!propertyNameValidator.find(propertyName.c_str()))
{
::reportError(context, content-GetOriginalExpression(),
Property name not supported.);
@@ -480,7 +484,8 @@ struct TargetFilesystemArtifact : public
cmGeneratorExpressionNode
std::string name = *parameters.begin();
cmsys::RegularExpression targetValidator;
-targetValidator.compile(^[A-Za-z0-9_.-]+$);
+// The ':' is supported to allow use with IMPORTED targets.
+targetValidator.compile(^[A-Za-z0-9_.:-]+$);
if (!targetValidator.find(name.c_str()))
{
::reportError(context, content-GetOriginalExpression(),
diff --git a/Tests/IncludeDirectories/TargetIncludeDirectories/CMakeLists.txt
b/Tests/IncludeDirectories/TargetIncludeDirectories/CMakeLists.txt
index d71f92e..7cb1b42 100644
--- a/Tests/IncludeDirectories/TargetIncludeDirectories/CMakeLists.txt
+++ b/Tests/IncludeDirectories/TargetIncludeDirectories/CMakeLists.txt
@@ -17,6 +17,7 @@ create_header(bing)
create_header(bung)
create_header(arguments)
create_header(list)
+create_header(target)
set(CMAKE_INCLUDE_CURRENT_DIR ON)
@@ -24,6 +25,7 @@ include_directories(${CMAKE_CURRENT_BINARY_DIR}/bar)
include_directories($1:${CMAKE_CURRENT_BINARY_DIR}/bang)
add_executable(TargetIncludeDirectories main.cpp)
+
set_property(TARGET TargetIncludeDirectories APPEND PROPERTY
