Re: [cmake-developers] Apple tests for target_link_libraries failing
Bill Hoffman wrote:
So, basically we this:
set(CMAKE_LINK_INTERFACE_LIBRARIES )
add_library(libA SHARED classA.cpp)
add_library(libB SHARED classB.cpp)
add_library(libC SHARED classC.cpp)
generate_export_header(libA)
generate_export_header(libB)
generate_export_header(libC)
target_link_libraries(libB libA)
target_link_libraries(libC libA libB)
add_executable(exec
main.cpp
)
target_link_libraries(exec libC )
So, setting CMAKE_LINK_INTERFACE_LIBRARIES to is supposed to make the
transitive linking of A and B not happen when linking C. I tried adding
some print stuff in the code. But, I am not sure where to look.
I added the following:
void cmTarget::SetPropertyDefault(const char* property,
const char* default_value)
{
+ bool debug = false;
+ if(strcmp(LINK_INTERFACE_LIBRARIES, property) == 0)
+debug = true;
+ if(debug) std::cerr this-GetName() \n;
// Compute the name of the variable holding the default value.
std::string var = CMAKE_;
var += property;
-
+ if(debug) std::cerr var \n;
if(const char* value = this-Makefile-GetDefinition(var.c_str()))
{
+if(debug) std::cerr found it value \n;
this-SetProperty(property, value);
}
else if(default_value)
{
+if(debug) std::cerr not found default_value \n;
this-SetProperty(property, default_value);
}
}
diff --git a/Source/cmTargetLinkLibrariesCommand.cxx b/Source/cmTargetLin
kLibrariesCommand.cxx
index 805959d..d2be3fa 100644
--- a/Source/cmTargetLinkLibrariesCommand.cxx
+++ b/Source/cmTargetLinkLibrariesCommand.cxx
@@ -219,6 +219,7 @@ cmTargetLinkLibrariesCommand::HandleLibrary(const cha
r* lib,
// Handle normal case first.
if(!this-DoingInterface)
{
+std::cerr this-Target-GetName() Not doing interface \
n;
this-Makefile
I ended up with this:
libA
CMAKE_LINK_INTERFACE_LIBRARIES
found it
libB
CMAKE_LINK_INTERFACE_LIBRARIES
found it
libC
CMAKE_LINK_INTERFACE_LIBRARIES
found it
libB Not doing interface
libC Not doing interface
libC Not doing interface
Do you have other prints that I should add? How is this supposed to work?
-Bill
How exactly it works I am not entirely certain. I followed the suggestion in
this thread:
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/1865/focus=1868
and it just worked for me.
I assume the contents of LINK_INTERFACE_LIBRARIES gets read somewhere else
to create the actual link line. each of libA libB and libC do not get added
to the link_interfaces, and using set(CMAKE_LINK_INTERFACE_LIBRARIES )
should be the same as using
target_link_libraries(libA LINK_INTERFACE_LIBRARIES )
for each library.
It works for me, but I don't know why it doesn't work for you. Maybe Brad
can have some insight?
Thanks,
Steve.
--
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] Apple tests for target_link_libraries failing
On 10/12/2011 2:22 AM, Stephen Kelly wrote: using set(CMAKE_LINK_INTERFACE_LIBRARIES ) should be the same as using target_link_libraries(libA LINK_INTERFACE_LIBRARIES ) for each library. It is. The example under discussion has the same behavior even if you explicitly set it on each target. It works for me, but I don't know why it doesn't work for you. Maybe Brad can have some insight? The Modules/Platform/Darwin.cmake contains these lines: # Need to list dependent shared libraries on link line. When building # with -isysroot (for universal binaries), the linker always looks for # dependent libraries under the sysroot. Listing them on the link # line works around the problem. SET(CMAKE_LINK_DEPENDENT_LIBRARY_FILES 1) which were added here: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2cff26fa#patch1 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=82fcaebe#patch4 The behavior we are seeing in the test on Apple can be changed to the expected behavior by adding SET(CMAKE_LINK_DEPENDENT_LIBRARY_FILES 0) to the CMakeLists.txt file. However, I don't remember the details of why I had to add that to Darwin.cmake in the first place. Hopefully there is a better fix for the original problem. -Brad -- 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] Apple tests for target_link_libraries failing
On Wed, Oct 12, 2011 at 10:30 AM, Stephen Kelly steve...@gmail.com wrote: Brad King wrote: On 10/12/2011 2:22 AM, Stephen Kelly wrote: using set(CMAKE_LINK_INTERFACE_LIBRARIES ) should be the same as using target_link_libraries(libA LINK_INTERFACE_LIBRARIES ) for each library. It is. The example under discussion has the same behavior even if you explicitly set it on each target. snip The behavior we are seeing in the test on Apple can be changed to the expected behavior by adding SET(CMAKE_LINK_DEPENDENT_LIBRARY_FILES 0) to the CMakeLists.txt file. However, I don't remember the details of why I had to add that to Darwin.cmake in the first place. Hopefully there is a better fix for the original problem. Ok, knowing why it fails on APPLE is good enough for me for now. The tests can be enabled on APPLE again later, I've flipped the if condition so we can see why it fails on some non-APPLE platforms too. I already grepped for CMAKE_LINK_DEPENDENT_LIBRARY_FILES and it seems to not appear anywhere else but Darwin.cmake. I remember the tests failing on freebsd and some windows too, so if you have any idea why that might be, I'd be interested to know. Thanks, Steve. -- 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 $ git grep CMAKE_LINK_DEPENDENT_LIBRARY_FILES ChangeLog.txt:CMAKE_LINK_DEPENDENT_LIBRARY_FILES boolean. Modules/Platform/Darwin.cmake:SET(CMAKE_LINK_DEPENDENT_LIBRARY_FILES 1) Source/cmComputeLinkInformation.cxx: if(this-Makefile-IsOn(CMAKE_LINK_DEPENDENT_LIBRARY_FILES)) Source/cmDocumentVariables.cxx: cm-DefineProperty(CMAKE_LINK_DEPENDENT_LIBRARY_FILES, The important occurrence would seem to be the one in Source/cmComputeLinkInformation.cxx... -- 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] Apple tests for target_link_libraries failing
On 10/12/2011 10:38 AM, David Cole wrote: On Wed, Oct 12, 2011 at 10:30 AM, Stephen Kellysteve...@gmail.com wrote: I already grepped for CMAKE_LINK_DEPENDENT_LIBRARY_FILES and it seems to not appear anywhere else but Darwin.cmake. I remember the tests failing on freebsd and some windows too, so if you have any idea why that might be, I'd be interested to know. $ git grep CMAKE_LINK_DEPENDENT_LIBRARY_FILES ChangeLog.txt:CMAKE_LINK_DEPENDENT_LIBRARY_FILES boolean. Modules/Platform/Darwin.cmake:SET(CMAKE_LINK_DEPENDENT_LIBRARY_FILES 1) Source/cmComputeLinkInformation.cxx: if(this-Makefile-IsOn(CMAKE_LINK_DEPENDENT_LIBRARY_FILES)) Source/cmDocumentVariables.cxx: cm-DefineProperty(CMAKE_LINK_DEPENDENT_LIBRARY_FILES, The important occurrence would seem to be the one in Source/cmComputeLinkInformation.cxx... I think Steve meant that it does not appear in other platform info files. -Brad -- 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] Some documentation patches
On 10/12/2011 11:10 AM, Nicolas Desprès wrote: I have extracted some documentation patches I have made while I was working on the ninja-generator and some enhancement for ccmake. I would like to submit them now. They are addressing: - usage messages - doxygen documentation - online help in ccmake Fantastic. This is a lot of tedious cleanup work. Thanks for doing it! Here are a few comments from review: - The Factor toggle key help instructions commit adds lines longer than 79 characters. Please reformat them to use shorter lines. - Some of the patches remove trailing whitespace from lines unrelated to the real change. Please identify the set of files from which you've blanket-removed whitespace, create a commit that does just that, and then rebase the rest of the patches on it. That will make the changes easier to see/review/blame. - Please prefix each commit message with the section affected, when applicable. For example, ccmake: or doxygen: . Thanks, -Brad -- 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
[CMake] Catch result after test
Hi, How can I catch test result before writed in LastTest.log? In which file is ordered the creation of files? - LastTest.log, - LastTestsFailed.log, - CTestCostData.txt located in build/Testing/Temporary. Best regards, Mohamed. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Shouldn't CMAKE_VERBOSE_MAKEFILE add SuppressStartupBannerfalse/... to VS 2010 vcxproj files?
Update: I locally fixed CMake's support for CMAKE_VERBOSE_MAKEFILE on Visual Studio 10 (or higher), and submitted a bug report: 0012504: Fix CMAKE_VERBOSE_MAKEFILE for Visual Studio 10 vcxproj files http://public.kitware.com/Bug/view.php?id=12504 Committed by Brad King: http://cmake.org/gitweb?p=cmake.git;h=25116a3c Thank you, Brad! Kind regards, Niels -- Niels Dekker http://www.xs4all.nl/~nd/dekkerware Scientific programmer at LKEB, Leiden University Medical Center -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] Un-program Visual Studio (msvc 10) compiler in cygwin
Hi I have tried different ways to escape the MSVC compiler. I have installed Cygwin on Windows 7 and try this out in Cygwin I tried to - set CMAKE_CC_COMPILER=compiler.exe in CMakeLists.txt (before project()) - cmake.exe -D CMAKE_CC_COMPILER=compiler.exe . - cmake.exe -D CMAKE_CC_COMPILER=/c/compiler/compiler.exe . But when cmake.exe is executed, it finds the MSVC compiler: $ which compiler.exe /c/compiler/compiler.exe $ cat cmake.sh cmake.exe -D CMAKE_C_COMPILER=compiler.exe . $ ./cmake.sh -- Building for: Visual Studio 10 -- ... Is it because I don't include -G My generator? if so what is included in a generator? Thank you very much Paul -- 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] ProjectConfig.cmake, export() and multiple libraries
Hi all, I have a project which provides a set of shared libraries, some libraries being dependent on other ones: For example: libcore libmodule1 - libcore libmodule2 - libcore libmoduleA - libmodule1 As this is a CMake based project, I've read on the internet that I should provide a ProjectConfig.cmake file to allow other CMake based projects to use the libraries. So I tried to do that after reading the tutorial on the CMake's wiki and I have a working ProjectConfig.cmake for an installed tree which contains all the targets (I did not succeed to have it working for an in build tree though). The problem is that I want each of my libraries to be self-supported (for example, I'd like to use find_package() in module1 to find core). I want to be able to have different version for each library which depends on specific versions of the other libraries. If I am correct, that means I need to generate one ProjectConfig.cmake and one ProjectConfigVersion.cmake for each library. This way, I should be able to create a project which does find_package(core 1.3) and find_package(module2 0.3) if it needs only the module2. But the Module2Config.cmake tries do redeclare the core imported target which is already created by the CoreConfig.cmake. Indeed I already have this problem directly in the Module2's CMakeLists.txt as I tried to find_package(core 1.3) here in order to define the include directories and to link to the core. If I try to not export core when generating Module2Config.cmake, I get an error telling me that module2 depends on core so it must be exported. So, to sum it up, I'd like each module to find its dependencies as if it was third party libraries (installed tree and in build tree must be supported). Then, everything should be ok to create a project which uses only a few of the modules. Any hints? -- 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] Un-program Visual Studio (msvc 10) compiler in cygwin
Hi I have tried different ways to escape the MSVC compiler. I have installed Cygwin on Windows 7 and try this out in Cygwin I tried to - set CMAKE_CC_COMPILER=compiler.exe in CMakeLists.txt (before project()) - cmake.exe -D CMAKE_CC_COMPILER=compiler.exe . - cmake.exe -D CMAKE_CC_COMPILER=/c/compiler/compiler.exe . But when cmake.exe is executed, it finds the MSVC compiler: $ which compiler.exe /c/compiler/compiler.exe $ cat cmake.sh cmake.exe -D CMAKE_C_COMPILER=compiler.exe . $ ./cmake.sh -- Building for: Visual Studio 10 -- ... Is it because I don't include -G My generator? if so what is included in a generator? If you don't provide a generator CMake will pick a default one. Which is very likely a MSVC one if you have MSVC installed. If you run cmake --help it will print you a list of valid generators at the end. 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] XMOS ASM / C Compiler support progress and questions
Hi List,
I'm currently working on better integrating the XMOS toolchain [1]
(version 11.2.2) into CMake 2.8.5, among other things (such as TI
C6000 support). I've today managed to integrate the detection of the
XMOS assembler. Basically, all I had to do is to insert these three
lines in the file CMakeDetermingASMCompiler.cmake (find my modified
version attached, feel free to include in future versions):
LIST(APPEND CMAKE_ASM${ASM_DIALECT}_COMPILER_ID_VENDORS XMOS )
SET(CMAKE_ASM${ASM_DIALECT}_COMPILER_ID_VENDOR_FLAGS_XMOS --version)
SET(CMAKE_ASM${ASM_DIALECT}_COMPILER_ID_VENDOR_REGEX_XMOS XMOS Limited)
Furthermore, the file XMOS-ASM.cmake (attached, may be included as
well) has to be added to Modules/Compilers/. In this file the valid
extensions get set, which in our case are xc (special language from
XMOS to program their CPUs), s and S. I'm cheating a bit when
specifying the assembler executable because I use xcc instead of xas,
but this is necessary in order to get the xc-files processed
correctly. I'll clean this up at one point, but this workaround has
worked for us the past two years, and nothing lasts longer than a
working workaround.
The toolchain file to use looks as follows:
SET(CMAKE_SYSTEM_VERSION 2.8)
INCLUDE(CMakeForceCompiler)
SET(CMAKE_SYSTEM_NAME generic)
CMAKE_FORCE_C_COMPILER(xcc GNU)
CMAKE_FORCE_CXX_COMPILER(xcc GNU)
SET(CMAKE_COMPILER_IS_GNUCXX 1)
SET(CMAKE_ASM_COMPILER xcc)
I would prefer to not to have not force the compiler, but the recent
XMOS toolchain require an additional command line argument to specify
the processor to compile for: `-target'. As far as I'm aware there is
no way to pass additional compiler flags to the compiler checking
operations.
Cheers
Bernhard
[1] https://www.xmos.com/products/development-tools
XMOS-ASM.cmake
Description: Binary data
CMakeDetermineASMCompiler.cmake
Description: Binary data
--
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: Save stripped debugging information
On 10/03/2011 09:18 AM, Yuri Timenkov wrote:
Hi Michael,
On Sun, Oct 2, 2011 at 6:07 PM, Michael Hertling mhertl...@online.dewrote:
On 10/01/2011 10:07 AM, Yuri Timenkov wrote:
that's the problem: you don't know neither file name nor it's location,
especially in multi-configuration generators.
You *do* know a debug file's name and location, either because you must
generate it explicitly (objcopy approach) or via the concerned target's
$TARGET_FILE_DIR:... generator expression in custom targets/commands
(Visual approach). Otherwise, a debug file with unknown name and/or
location would be rather useless.
I'm sorry that you misunderstood me, but I was concerned about install()
commands.
CMake already does a lot of things to make different platforms and
generators work in same way. As it was noted before, install already knows
about such subtleties between generators and platforms like export
libraries. So why not make it aware of separate debug information?
Because, IMO, the platform/generator independent extraction and/or
recognition of debug info files is significantly more difficult to
specify than the handling of DLLs along with their import libraries
in VS, e.g. AFAICS, the latter works well since the import libraries
are generated next to their DLLs sharing the same base name, and both
are covered by INSTALL()'s RUNTIME/ARCHIVE DESTINATION clauses which
also have a defined meaning on *nix. For VS alone, the installation
of debug info files would in fact be as easy as the installation of
an import library, but how would you specify and parameterize this
task on *nix? With the GNU toolchain, CMake can't know in advance if
and how debug info files are generated, where they're written to etc.
In order to not be misunderstood: I'm not opposed to introduce a new
INSTALL(TARGETS ... DEBUG DESTINATION ...)
subcommand, but it should definitely have a chance to work on all
platforms/generators and not limit the user's choices. If you have
an idea how such an enhancement may be designed, feel free to come
up with it, of course. Possibly, it might also be applicable to an
INSTALL(TARGETS ... PROFILE DESTINATION ...)
subcommand.
Adding objcopy/whatever to separate debug information to out-of-box CMake is
just one more step to unifying different platforms and generators.
On *nix, the extraction of debug information need not to be a step
that can be simply added. As I've already remarked in this thread,
it might involve the linker (build-ID approach), it might involve
supplementary tools (objcopy approach), it might involve both and
it might require the user to pass parameters (build-ID string).
[...]
If it were possible to emulate vs behavior for gcc things would be much
easier in some cases. [...]
In which cases?
install debug into separate location for further usage, like generating
runtime and devel packages. The third one is debug.
IMO, this is already possible with installation components:
INSTALL(FILES debug-files DESTINATION ... COMPONENT debug)
However, the basic problem remains: How does CMake get to know
the debug files on *non-VS* platforms? If this is once solved,
the debug files' pure installation should be fairly easy.
[...]
Regards,
Michael
On Oct 1, 2011 8:09 AM, Michael Hertling mhertl...@online.de wrote:
On 09/30/2011 08:39 AM, Rolf Eike Beer wrote:
On 09/29/2011 06:15 AM, Yuri Timenkov wrote:
When I was investigating similar problem, I found alternative
approach
at
http://code.google.com/p/dynamorio/source/browse/trunk/CMakeLists.txt.
The thing is to change linker rules, to something like this:
set(CMAKE_C_CREATE_SHARED_LIBRARY
# standard rule
CMAKE_C_COMPILER CMAKE_SHARED_LIBRARY_C_FLAGS
LANGUAGE_COMPILE_FLAGS LINK_FLAGS
CMAKE_SHARED_LIBRARY_CREATE_C_FLAGS
CMAKE_SHARED_LIBRARY_SONAME_C_FLAGTARGET_SONAME -o TARGET
OBJECTS
LINK_LIBRARIES
# now create a .debug copy
${CMAKE_OBJCOPY} --only-keep-debug TARGET TARGET.debug
# link original to point at .debug copy
# directory components are removed, so ../lib/ is fine
${CMAKE_OBJCOPY} --add-gnu-debuglink=TARGET.debug TARGET
# Strip all information from target binary.
${CMAKE_STRIP} --strip-debug --discard-all --preserve-dates
TARGET
)
I don't exactly remember benefits from this approach but it kind of
works.
The benefits are that one needs to define these rule variables once as
they're inherited by the subdirectories. The downside is that the rule
variables are used by Makefile generators only, whereas the target-
associated custom commands are a more generic approach.
And I agree that functionality like installing debug symbols in
install()
rules out of box would be quite handy.
INSTALL() is essentially about copying files and directories, so it
doesn't depend on the toolchain; in particular, you can use INSTALL()
for projects which are configured with PROJECT(... NONE), i.e. without
any toolchain. By contrast, extracting debug symbols does highly
depend
on
Re: [CMake] ProjectConfig.cmake, export() and multiple libraries
On 10/12/2011 11:31 AM, Jérémie Delaitre wrote:
Hi all,
I have a project which provides a set of shared libraries, some libraries
being dependent on other ones:
For example:
libcore
libmodule1 - libcore
libmodule2 - libcore
libmoduleA - libmodule1
As this is a CMake based project, I've read on the internet that I should
provide a ProjectConfig.cmake file to allow other CMake based projects to
use the libraries. So I tried to do that after reading the tutorial on the
CMake's wiki and I have a working ProjectConfig.cmake for an installed tree
which contains all the targets (I did not succeed to have it working for an
in build tree though).
The problem is that I want each of my libraries to be self-supported (for
example, I'd like to use find_package() in module1 to find core). I want to
be able to have different version for each library which depends on specific
versions of the other libraries. If I am correct, that means I need to
generate one ProjectConfig.cmake and one ProjectConfigVersion.cmake for each
library.
This way, I should be able to create a project which does find_package(core
1.3) and find_package(module2 0.3) if it needs only the module2. But the
Module2Config.cmake tries do redeclare the core imported target which is
already created by the CoreConfig.cmake. Indeed I already have this problem
directly in the Module2's CMakeLists.txt as I tried to find_package(core
1.3) here in order to define the include directories and to link to the
core.
If I try to not export core when generating Module2Config.cmake, I get an
error telling me that module2 depends on core so it must be exported.
So, to sum it up, I'd like each module to find its dependencies as if it
was third party libraries (installed tree and in build tree must be
supported). Then, everything should be ok to create a project which uses
only a few of the modules.
Any hints?
Imported targets require to be protected against being redefined
within the same scope, i.e. the following line from the tutorial
include(${FOOBAR_CMAKE_DIR}/FooBarLibraryDepends.cmake)
must not be executed unconditionally. See the discussion spawned
at the end of [1] for more information and a possible solution.
BTW, with your current approach, the lines
FIND_PACKAGE(core 1.3)
FIND_PACKAGE(module2 0.3)
in another project might pose a problem: After the first line, core's
export file has been processed, the imported target core is defined
and points to the 1.3 core library. Now, if Module2Config.cmake issues
FIND_PACKAGE(core 1.2), e.g., and a valid CoreConfig.cmake for 1.2 is
found but differs from the 1.3 version, the export file for core 1.2
won't le loaded because of the above-mentioned include guard, or if
the include guard is version-sensitive, you will redefine the core
imported target, and CMake bails out. Therefore, if the libraries'
versions are important to you, you should add them to the targets'
names, or make the latters differ from version to version by other
means. So, module2 will use the core1.2 imported target whereas the
overall project refers to core1.3. Anyway, using multiple versions
of a library within the same binary requires particular carefulness.
Regards,
Michael
[1] http://www.mail-archive.com/cmake@cmake.org/msg35873.html
--
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] Protobuf Module
PROTOBUF_GENERATE_CPP does not seem to work at all in ubuntu. I was working
with 2.8.3 and since it wasn't working I have compiled the latest cmake
(2.8.6) but still no luck. I also tried with --debug-output but after
finding protobuf no other related output.
Here's the relevant segment:
FIND_PACKAGE(Protobuf)
IF(PROTOBUF_FOUND)
INCLUDE_DIRECTORIES(${PROTOBUF_INCLUDE_DIRS})
INCLUDE_DIRECTORIES(${CMAKE_CURRENT_BINARY_DIR})
PROTOBUF_GENERATE_CPP(PROTO_SRCS PROTO_HDRS data.proto)
ENDIF()
Yet the protoc compiler is never invoked and the data.pb.cc and .h
files are never created (even tried without the IF statement).
Any ideas?
James
--
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] Which style of file extension is better for optional CMake files?
On Wed, Oct 12, 2011 at 12:16 AM, Ryuan Choi ryuan.c...@samsung.com wrote: Dear CMake Developers, Can I know which style is more closed to CMake style? a) CMakeLists.txt and PlatformXXX.cmake for optional platform specific source lists in same folder. b) CMakeLists.txt and CMakeListsXXX.cmake in same folder. Because there are many platform specific files in my project, CMakeLists.txt should be seperated. I'd like to know which one is better and fix them better way. Below is related bug and you can see more information. https://bugs.webkit.org/show_bug.cgi?id=56705 Best Regards, Ryuan Choi -- 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 I think it's mostly a matter of style... so you could go either way. Personally, I would choose the PlatformXXX.cmake names over the other ones. The other ones are too close to CMakeLists.txt and could be confused for them by a quick scan of the file name. So, for human readability and understanding, I would prefer the PlatformXXX.cmake names. 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] Fwd: Save stripped debugging information
On 10/03/2011 09:18 AM, Yuri Timenkov wrote: Hi Michael, On Sun, Oct 2, 2011 at 6:07 PM, Michael Hertling mhertl...@online.dewrote: On 10/01/2011 10:07 AM, Yuri Timenkov wrote: that's the problem: you don't know neither file name nor it's location, especially in multi-configuration generators. You *do* know a debug file's name and location, either because you must generate it explicitly (objcopy approach) or via the concerned target's $TARGET_FILE_DIR:... generator expression in custom targets/commands (Visual approach). Otherwise, a debug file with unknown name and/or location would be rather useless. I'm sorry that you misunderstood me, but I was concerned about install() commands. CMake already does a lot of things to make different platforms and generators work in same way. As it was noted before, install already knows about such subtleties between generators and platforms like export libraries. So why not make it aware of separate debug information? Because, IMO, the platform/generator independent extraction and/or recognition of debug info files is significantly more difficult to specify than the handling of DLLs along with their import libraries in VS, e.g. AFAICS, the latter works well since the import libraries are generated next to their DLLs sharing the same base name, and both are covered by INSTALL()'s RUNTIME/ARCHIVE DESTINATION clauses which also have a defined meaning on *nix. For VS alone, the installation of debug info files would in fact be as easy as the installation of an import library, but how would you specify and parameterize this task on *nix? With the GNU toolchain, CMake can't know in advance if and how debug info files are generated, where they're written to etc. I think you got something reverse here. To actually get the debug information in a separate file with binutils you need to run objcopy. You _specify_ to objcopy where to put the debug file. So CMake would need to specify this, i.e. can always know where these files end up. The build-id thing is optional, and as far as I understand this the primary use case is to find the debug symbols corresponding to an executable. The usual thing with gnu-debug-link is still done on those binaries, so the build-id thing is on top of that. This would only affect the install stage at all, i.e. if CMake would install these debug symbols in the global debug directory. So, to make things short: -call objcopy with target filename and the output filename - both come from CMake, no magic -optionally, and only on installation, check if the file has a build-id (using readelf, objdump or whatever) and place a link from /usr/lib/debug/.build-id (or whereever) to the debug file So AFAICT there is no magic knowledge or searching for something involved at all. Or am I getting something seriously wrong here? 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] Linker flags not considered
Hi all, I would like to build a project using intel fortran compiler. When building the project I would like to add/change two linker flags: - /stack:12800 - /subsystem:windows (when launched, the executable (GUI) will not launch any additional terminal) To do so, I simply added in my CMakeLists.txt file the following line: set(CMAKE_EXE_LINKER_FLAGS /stack:12800 /subsystem:windows) Unfortunately, when starting my application, there is still a terminal window that pops up. So the /subsystem:windows seems to have been skipped by the linker (and I guess also the /stack:12800 flag). I also try (by the way what is the difference ?): set(LINK_FLAGS /stack:12800 /subsystem:windows) but it also produced the same unwanted effect. did I miss something somewhere ? thanks for your help Eric -- Eric Pellegrini Calcul Scientifique Institut Laue-Langevin Grenoble, France -- \n 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] Linker flags not considered
On Mi., 12. Okt. 2011 17:05:52 CEST, pellegrini pellegr...@ill.fr wrote: Hi all, I would like to build a project using intel fortran compiler. When building the project I would like to add/change two linker flags: - /stack:12800 - /subsystem:windows (when launched, the executable (GUI) will not launch any additional terminal) This usually means you want to add the WIN32 flag in your ADD_EXECUTABLE call. See the documentation of it. 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] Linker flags not considered - solved
that's work ! Great ! Thanks a lot Rolf Rolf Eike Beer a écrit : On Mi., 12. Okt. 2011 17:05:52 CEST, pellegrini pellegr...@ill.fr wrote: Hi all, I would like to build a project using intel fortran compiler. When building the project I would like to add/change two linker flags: - /stack:12800 - /subsystem:windows (when launched, the executable (GUI) will not launch any additional terminal) This usually means you want to add the WIN32 flag in your ADD_EXECUTABLE call. See the documentation of it. 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 -- Eric Pellegrini Calcul Scientifique Institut Laue-Langevin Grenoble, France -- 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] Delivering imported libraries with binaries on Linux
Hello: I am working on a project that relies on third party libraries, for example MyVendor.so. I am using cmake 2.6. When the third party shared object is checked out, it is installed in svnroot/Thirdparty/MyVendor/lib/MyVendor.so I add the library has an imported library. When I build the application, the location of the library is linked to the precise location above. How do I: 1) Encode cmake to generate a make file that copies the library into a location relative to the binary, like ../lib so that I can then use that directory as an import location. I can copy the file myself manually but it would nice if I could use cmake to help with doing this automatically. I know that if I was handwriting a makefile I could in effect build a library target by copying one from a different location. 2) How do I ensure that CPack maintains that relative structure so that internally the application looks in ../lib for the file to dynamically load? Thanks Matthew Harelick -- 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] XMOS ASM / C Compiler support progress and questions
Hi,
On Wednesday 12 October 2011, Bernhard Sputh wrote:
Hi List,
I'm currently working on better integrating the XMOS toolchain [1]
(version 11.2.2) into CMake 2.8.5, among other things (such as TI
C6000 support).
Cool :-)
Please create an entry in the bug tracker for that, so it doesn't get lost.
I've today managed to integrate the detection of the
XMOS assembler. Basically, all I had to do is to insert these three
lines in the file CMakeDetermingASMCompiler.cmake (find my modified
version attached, feel free to include in future versions):
LIST(APPEND CMAKE_ASM${ASM_DIALECT}_COMPILER_ID_VENDORS XMOS )
SET(CMAKE_ASM${ASM_DIALECT}_COMPILER_ID_VENDOR_FLAGS_XMOS --version)
SET(CMAKE_ASM${ASM_DIALECT}_COMPILER_ID_VENDOR_REGEX_XMOS XMOS Limited)
Furthermore, the file XMOS-ASM.cmake (attached, may be included as
well) has to be added to Modules/Compilers/. In this file the valid
extensions get set, which in our case are xc (special language from
XMOS to program their CPUs), s and S. I'm cheating a bit when
specifying the assembler executable because I use xcc instead of xas,
but this is necessary in order to get the xc-files processed
correctly. I'll clean this up at one point, but this workaround has
worked for us the past two years, and nothing lasts longer than a
working workaround.
Since 2.8.5 the ASM language is the one to use for assembler files which are
processed by the C or C++ compiler, i.e. which may need to be preprocessed.
I.e. you shouldn't even have to set CMAKE_ASM_COMPILER, when enabling ASM it
will use the value of CMAKE_C_COMPILER for CMAKE_ASM_COMPILER.
The toolchain file to use looks as follows:
SET(CMAKE_SYSTEM_VERSION 2.8)
INCLUDE(CMakeForceCompiler)
SET(CMAKE_SYSTEM_NAME generic)
CMAKE_FORCE_C_COMPILER(xcc GNU)
CMAKE_FORCE_CXX_COMPILER(xcc GNU)
SET(CMAKE_COMPILER_IS_GNUCXX 1)
SET(CMAKE_ASM_COMPILER xcc)
Why do you set the compiler id to GNU ?
That's not a good idea I'd say.
I would prefer to not to have not force the compiler, but the recent
XMOS toolchain require an additional command line argument to specify
the processor to compile for: `-target'. As far as I'm aware there is
no way to pass additional compiler flags to the compiler checking
operations.
How does the syntax look exactly ?
xcc -target Foo
or
xcc -target=Foo ...
?
In the second case, it should work if you do
set(CMAKE_C_COMPILER xcc -target=Foo)
Alex
--
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] ExternalProject and clean targets
I'm building external packages in my CMake system using the ExternalPackages_Add function. When a package is built this way and I execute a 'make clean' at the top of my build tree, all targets are cleaned including the external packages. Is there a way to remove the external package targets from the the default clean target? -- Lori A. Pritchett-Sheats, PhD. CCS-2, Computational Physics and Methods Office: 505-665-6675 Fax: 505-665-4972 Los Alamos National Laboratory P.O. Box 1663 MS D413 Los Alamos, NM 87544 -- 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] Protobuf Module
On Wed, Oct 12, 2011 at 8:46 AM, James Anderson
japanwikidon...@gmail.comwrote:
PROTOBUF_GENERATE_CPP does not seem to work at all in ubuntu. I was working
with 2.8.3 and since it wasn't working I have compiled the latest cmake
(2.8.6) but still no luck. I also tried with --debug-output but after
finding protobuf no other related output.
Here's the relevant segment:
FIND_PACKAGE(Protobuf)
IF(PROTOBUF_FOUND)
INCLUDE_DIRECTORIES(${PROTOBUF_INCLUDE_DIRS})
INCLUDE_DIRECTORIES(${CMAKE_CURRENT_BINARY_DIR})
PROTOBUF_GENERATE_CPP(PROTO_SRCS PROTO_HDRS data.proto)
ENDIF()
Yet the protoc compiler is never invoked and the data.pb.cc and .h files are
never created (even tried without the IF statement).
James,
PROTO_SRCS PROTO_HDRS (in the code snippit you list above) are simply
lists of source header files to generate. You need to use them in a
target in order for CMake to cause them to be generated.
E.g.
add_executable(foo foo.cc ${PROTO_SRCS} ${PROTO_HDRS})
target_link_libraries(foo ${PROTOBUF_LIBRARIES})
Hope that solves your problem.
--
Philip Lowman
--
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] Which style of file extension is better for optional CMake files?
I think it's mostly a matter of style... so you could go either way. Personally, I would choose the PlatformXXX.cmake names over the other ones. The other ones are too close to CMakeLists.txt and could be confused for them by a quick scan of the file name. So, for human readability and understanding, I would prefer the PlatformXXX.cmake names. Thank you for the answer. I realized that I have a mistake in my question. For now, we are using CMakeListsXXX.txt which CMakeLists.txt include - not CMakeListsXXX.cmake. sorry for my typo. All of them are list of source, but CMakeListsXXX.txt is optional. My bug is to change CMakeListsXXX.txt to PlatformXXX.cmake because I didn't see CMakeListsXXX.txt As you mentioned, if I can choose anything, I'll keep the current. Best Regards, Ryuan Choi -- 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, next, updated. v2.8.6-1565-gf48a0be
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 f48a0be07ebcdbe5d6c6a10d34e70cce164d9a9b (commit) via 83df8b5ca77c96ed82ca120e2a0499ec7273c41a (commit) from a34b8e73704df3451e902c9ae7fb3da75e50c7fa (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=f48a0be07ebcdbe5d6c6a10d34e70cce164d9a9b commit f48a0be07ebcdbe5d6c6a10d34e70cce164d9a9b Merge: a34b8e7 83df8b5 Author: Stephen Kelly steve...@gmail.com AuthorDate: Wed Oct 12 10:22:46 2011 -0400 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Wed Oct 12 10:22:46 2011 -0400 Merge topic 'cmake-link-interface-libraries' into next 83df8b5 Start enabling these tests only on non-APPLE. http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=83df8b5ca77c96ed82ca120e2a0499ec7273c41a commit 83df8b5ca77c96ed82ca120e2a0499ec7273c41a Author: Stephen Kelly steve...@gmail.com AuthorDate: Mon Oct 10 16:44:38 2011 +0200 Commit: Stephen Kelly steve...@gmail.com CommitDate: Wed Oct 12 16:21:43 2011 +0200 Start enabling these tests only on non-APPLE. Now we know why tests fail on APPLE, we can check other platforms. diff --git a/Tests/CMakeCommands/target_link_libraries/CMakeLists.txt b/Tests/CMakeCommands/target_link_libraries/CMakeLists.txt index 68a0f18..69a94bd 100644 --- a/Tests/CMakeCommands/target_link_libraries/CMakeLists.txt +++ b/Tests/CMakeCommands/target_link_libraries/CMakeLists.txt @@ -229,7 +229,7 @@ expect_pass(False False # However, if we do clear it and don't explicitly link the executable to it, # it fails, # whether we specify the link_interface_libraries properly or not. -if (APPLE) +if (NOT APPLE) expect_fail(True False classB classC LIBS --- Summary of changes: .../target_link_libraries/CMakeLists.txt |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.6-1567-gf872eb8
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 f872eb8c94dc50787192e0e23d570ee494788ae8 (commit)
via cf93d63c0ac5d2a5da21dd78812938dace4067e0 (commit)
from f48a0be07ebcdbe5d6c6a10d34e70cce164d9a9b (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=f872eb8c94dc50787192e0e23d570ee494788ae8
commit f872eb8c94dc50787192e0e23d570ee494788ae8
Merge: f48a0be cf93d63
Author: Alexander Neundorf neund...@kde.org
AuthorDate: Wed Oct 12 16:15:29 2011 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Wed Oct 12 16:15:29 2011 -0400
Merge topic 'DetectMasmCompilerId' into next
cf93d63 fix #12465: detect the masm compiler ID (MSVC)
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=cf93d63c0ac5d2a5da21dd78812938dace4067e0
commit cf93d63c0ac5d2a5da21dd78812938dace4067e0
Author: Alex Neundorf neund...@kde.org
AuthorDate: Thu Oct 6 17:57:32 2011 +0200
Commit: Alex Neundorf neund...@kde.org
CommitDate: Thu Oct 6 17:57:32 2011 +0200
fix #12465: detect the masm compiler ID (MSVC)
Alex
diff --git a/Modules/CMakeDetermineASMCompiler.cmake
b/Modules/CMakeDetermineASMCompiler.cmake
index 171e31f..0a70d0a 100644
--- a/Modules/CMakeDetermineASMCompiler.cmake
+++ b/Modules/CMakeDetermineASMCompiler.cmake
@@ -107,6 +107,10 @@ IF(NOT CMAKE_ASM${ASM_DIALECT}_COMPILER_ID)
SET(CMAKE_ASM${ASM_DIALECT}_COMPILER_ID_VENDOR_FLAGS_XL -qversion)
SET(CMAKE_ASM${ASM_DIALECT}_COMPILER_ID_VENDOR_REGEX_XL XL C)
+ LIST(APPEND CMAKE_ASM${ASM_DIALECT}_COMPILER_ID_VENDORS MSVC )
+ SET(CMAKE_ASM${ASM_DIALECT}_COMPILER_ID_VENDOR_FLAGS_MSVC /?)
+ SET(CMAKE_ASM${ASM_DIALECT}_COMPILER_ID_VENDOR_REGEX_MSVC Microsoft)
+
LIST(APPEND CMAKE_ASM${ASM_DIALECT}_COMPILER_ID_VENDORS TI_DSP )
SET(CMAKE_ASM${ASM_DIALECT}_COMPILER_ID_VENDOR_FLAGS_TI_DSP -h)
SET(CMAKE_ASM${ASM_DIALECT}_COMPILER_ID_VENDOR_REGEX_TI_DSP Texas
Instruments)
---
Summary of changes:
Modules/CMakeDetermineASMCompiler.cmake |4
1 files changed, 4 insertions(+), 0 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.6-1570-g49c1cf5
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 49c1cf5cd65752a6a28591b9dd9f4b6a0ab220e8 (commit)
via 0d44ce2bf4ced68e6d61b1733002988e0a8e6a40 (commit)
via 83e4a45609ef436d032b3c527bce9b0382cfe329 (commit)
from f872eb8c94dc50787192e0e23d570ee494788ae8 (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=49c1cf5cd65752a6a28591b9dd9f4b6a0ab220e8
commit 49c1cf5cd65752a6a28591b9dd9f4b6a0ab220e8
Merge: f872eb8 0d44ce2
Author: Alexander Neundorf neund...@kde.org
AuthorDate: Wed Oct 12 16:24:49 2011 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Wed Oct 12 16:24:49 2011 -0400
Merge topic 'SilentMakeOutputOnBSD' into next
0d44ce2 Silence make on OpenBSD in FindPackageModeTest(#12508)
83e4a45 KWSys Nightly Date Stamp
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0d44ce2bf4ced68e6d61b1733002988e0a8e6a40
commit 0d44ce2bf4ced68e6d61b1733002988e0a8e6a40
Author: Alex Neundorf neund...@kde.org
AuthorDate: Wed Oct 12 22:20:18 2011 +0200
Commit: Alex Neundorf neund...@kde.org
CommitDate: Wed Oct 12 22:20:18 2011 +0200
Silence make on OpenBSD in FindPackageModeTest(#12508)
BSD make doesn't use -v for printing its name and version, and so
complains on stderr that this is a bad command line option, used
in Tests/FindPackageModeMakefileTest/CMakeLists.txt .
Silence stderr to make that ugly output go away.
Patch by David Coppy.
Alex
diff --git a/Tests/FindPackageModeMakefileTest/CMakeLists.txt
b/Tests/FindPackageModeMakefileTest/CMakeLists.txt
index def8d63..3674f0e 100644
--- a/Tests/FindPackageModeMakefileTest/CMakeLists.txt
+++ b/Tests/FindPackageModeMakefileTest/CMakeLists.txt
@@ -7,6 +7,7 @@ if(UNIX AND ${CMAKE_GENERATOR} MATCHES Makefile)
# is AFAIK a GNU make extension. Alex
execute_process(COMMAND ${CMAKE_MAKE_PROGRAM} -v
OUTPUT_VARIABLE makeVersionOutput
+ ERROR_QUIET
TIMEOUT 10)
string(TOUPPER ${makeVersionOutput} MAKE_VERSION_OUTPUT)
if(${MAKE_VERSION_OUTPUT} MATCHES .*GNU MAKE.*)
---
Summary of changes:
Source/kwsys/kwsysDateStamp.cmake|2 +-
Tests/FindPackageModeMakefileTest/CMakeLists.txt |1 +
2 files changed, 2 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.6-1575-g280a278
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 280a27891bddf2d9c8446d6a124dfd5c42fce037 (commit)
via a481d84ff72f554bc2e98fe4d9d63f960cf0ebfc (commit)
from b6440da5b53aa0ac837bd521be45163c1d72f347 (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=280a27891bddf2d9c8446d6a124dfd5c42fce037
commit 280a27891bddf2d9c8446d6a124dfd5c42fce037
Merge: b6440da a481d84
Author: Philip Lowman phi...@yhbt.com
AuthorDate: Wed Oct 12 23:45:03 2011 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Wed Oct 12 23:45:03 2011 -0400
Merge topic 'FindProtoBuf_doc_clarify' into next
a481d84 FindProtoBuf: Documented limitation of the public macro
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a481d84ff72f554bc2e98fe4d9d63f960cf0ebfc
commit a481d84ff72f554bc2e98fe4d9d63f960cf0ebfc
Author: Philip Lowman phi...@yhbt.com
AuthorDate: Wed Oct 12 23:44:40 2011 -0400
Commit: Philip Lowman phi...@yhbt.com
CommitDate: Wed Oct 12 23:44:40 2011 -0400
FindProtoBuf: Documented limitation of the public macro
diff --git a/Modules/FindProtobuf.cmake b/Modules/FindProtobuf.cmake
index 38f5a75..5344304 100644
--- a/Modules/FindProtobuf.cmake
+++ b/Modules/FindProtobuf.cmake
@@ -39,7 +39,11 @@
# target_link_libraries(bar ${PROTOBUF_LIBRARIES})
#
# NOTE: You may need to link against pthreads, depending
-# on the platform.
+# on the platform.
+#
+# NOTE: The PROTOBUF_GENERATE_CPP macro add_executable() or add_library()
+# calls only work properly within the same directory.
+#
#
#
# PROTOBUF_GENERATE_CPP (public function)
---
Summary of changes:
Modules/FindProtobuf.cmake |6 +-
1 files changed, 5 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, master, updated. v2.8.6-35-g731d61d
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 731d61d8d9119417e5cc0b10ef167183d137cb00 (commit) from 83e4a45609ef436d032b3c527bce9b0382cfe329 (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=731d61d8d9119417e5cc0b10ef167183d137cb00 commit 731d61d8d9119417e5cc0b10ef167183d137cb00 Author: KWSys Robot kwro...@kitware.com AuthorDate: Thu Oct 13 00:01:03 2011 -0400 Commit: KWSys Robot kwro...@kitware.com CommitDate: Thu Oct 13 00:10:00 2011 -0400 KWSys Nightly Date Stamp diff --git a/Source/kwsys/kwsysDateStamp.cmake b/Source/kwsys/kwsysDateStamp.cmake index d542d7e..7bde0b0 100644 --- a/Source/kwsys/kwsysDateStamp.cmake +++ b/Source/kwsys/kwsysDateStamp.cmake @@ -18,4 +18,4 @@ SET(KWSYS_DATE_STAMP_YEAR 2011) SET(KWSYS_DATE_STAMP_MONTH 10) # KWSys version date day component. Format is DD. -SET(KWSYS_DATE_STAMP_DAY 12) +SET(KWSYS_DATE_STAMP_DAY 13) --- Summary of changes: Source/kwsys/kwsysDateStamp.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
