Re: [cmake-developers] Setting the link interface and dependencies in one command
Stephen Kelly wrote: > target_link_libraries(foo > LINK_PUBLIC > qtcore > qtnetwork > ) > > is equivalent to > > target_link_libraries(foo > qtcore > qtnetwork > ) > > * foo will link against qtcore and qtnetwork I should have also noted that both qtcore and qtnetwork will also be in the LINK_INTERFACE_LIBRARIES. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Setting the link interface and dependencies in one command
Stephen Kelly wrote: >> Other possible names? Perhaps LINK_PUBLIC and LINK_PRIVATE? >> Perhaps LINK AND LINK_ONLY? > > I'll implement it as you suggest with LINK_PUBLIC and LINK_PRIVATE, which > are most clear to me. We can change it once we have an implementation to > talk about. Well that didn't take long. I pushed a target-link-libraries-interfaces branch to stage. In the branch: target_link_libraries(foo LINK_PRIVATE qtxml LINK_PUBLIC qtcore qtnetwork ) and target_link_libraries(foo LINK_PUBLIC qtcore qtnetwork LINK_PRIVATE qtxml ) are equivalent to: target_link_libraries(foo qtcore qtnetwork qtxml ) target_link_libraries(foo LINK_INTERFACE_LIBRARIES qtcore qtnetwork ) both mean: * foo will link against qtxml, qtcore and qtnetwork * qtcore and qtnetwork will be in the LINK_INTERFACE_LIBRARIES ... target_link_libraries(foo LINK_PUBLIC qtcore qtnetwork ) is equivalent to target_link_libraries(foo qtcore qtnetwork ) * foo will link against qtcore and qtnetwork ... target_link_libraries(foo LINK_PRIVATE qtcore ) is equivalent to: target_link_libraries(foo qtcore ) target_link_libraries(foo TARGET_LINK_LIBRARIES "" ) * foo will link against qtcore * qtcore will not be in the LINK_INTERFACE_LIBRARIES ... target_link_libraries(foo LINK_PRIVATE qtxml ) target_link_libraries(foo LINK_PUBLIC qtcore qtnetwork ) is equivalent to: target_link_libraries(foo qtcore qtxml qtnetwork ) target_link_libraries(foo TARGET_LINK_LIBRARIES qtcore qtnetwork ) * foo will link against qtxml, qtcore and qtnetwork * qtcore and qtnetwork will be in the LINK_INTERFACE_LIBRARIES What do you think? 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] Setting the link interface and dependencies in one command
Brad King wrote:
> On 10/5/2011 9:47 AM, Stephen Kelly wrote:
>> Thanks for all of your explanations. It seems that introducing a way to
>> do this with one command has some support.
>>
>> So if SOME_FEATURE is true,
>>
>> target_link_libraries(foo bar SOME_KEYWORD baz)
>> if (SOME_FEATURE)
>>target_link_libraries(foo mar SOME_KEYWORD maz)
>> endif()
>>
>> would have to result in bar and mar not being part of the link interface,
>> and baz and maz being part of the link interface.
>>
>> How do we decide on a keyword there? LINK_INTERFACE_DEPENDENCIES perhaps?
>
> One possible problem with making it a keyword is that the name could
> appear in a list of libraries and invisibly transform a
> target_link_libraries call.
Do you mean a library or target called LINK_INTERFACE_DEPENDENCIES? Or do
you mean like this:
target_link_libraries(somelib ${ARGS_FROM_SOMEWHERE_ELSE})
where the variable could be a list containing the term
LINK_INTERFACE_DEPENDENCIES?
> What we need is a pair of keywords to switch
> between link+interface and
> link-only dependencies. We allow the keywords only if one of the two is
> the second argument to the command after the target name. For example,
> they can be called "LINK_INTERFACE" for link+interface and "LINK_DEPENDS"
> for link-only:
>
>target_link_libraries(foo LINK_INTERFACE bar LINK_DEPENDS baz)
>if(SOME_FEATURE)
> target_link_libraries(foo LINK_INTERFACE mar LINK_DEPENDS maz)
>endif()
Is this also succeptable to the same
target_link_libraries(somelib ${ARGS_FROM_SOMEWHERE_ELSE})
effect?
>
> Other possible names? Perhaps LINK_PUBLIC and LINK_PRIVATE?
> Perhaps LINK AND LINK_ONLY?
I'll implement it as you suggest with LINK_PUBLIC and LINK_PRIVATE, which
are most clear to me. We can change it once we have an implementation to
talk about.
All the best,
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] Setting the link interface and dependencies in one command
On 10/5/2011 9:47 AM, Stephen Kelly wrote: Thanks for all of your explanations. It seems that introducing a way to do this with one command has some support. So if SOME_FEATURE is true, target_link_libraries(foo bar SOME_KEYWORD baz) if (SOME_FEATURE) target_link_libraries(foo mar SOME_KEYWORD maz) endif() would have to result in bar and mar not being part of the link interface, and baz and maz being part of the link interface. How do we decide on a keyword there? LINK_INTERFACE_DEPENDENCIES perhaps? One possible problem with making it a keyword is that the name could appear in a list of libraries and invisibly transform a target_link_libraries call. What we need is a pair of keywords to switch between link+interface and link-only dependencies. We allow the keywords only if one of the two is the second argument to the command after the target name. For example, they can be called "LINK_INTERFACE" for link+interface and "LINK_DEPENDS" for link-only: target_link_libraries(foo LINK_INTERFACE bar LINK_DEPENDS baz) if(SOME_FEATURE) target_link_libraries(foo LINK_INTERFACE mar LINK_DEPENDS maz) endif() Other possible names? Perhaps LINK_PUBLIC and LINK_PRIVATE? Perhaps LINK AND LINK_ONLY? -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-developers] MSBuild dependency files
I just noticed that MSBuild has support for dependency files. These seem to work similarly to how you might augment a makefile with 'gcc -M'. This would save a lot of reloading of projects that want to generate dependencies from build files, since the dependencies would be external to the project files. Does anyone know how this works and if CMake might be able to make use of this feature for custom targets? 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Strange VS output file field
On Wed, Oct 5, 2011 at 3:45 PM, James Bigler wrote: > On Fri, Aug 19, 2011 at 10:41 AM, David Cole wrote: > >> On Thu, Aug 18, 2011 at 4:56 PM, David Cole >> wrote: >> > On Thu, Aug 18, 2011 at 1:30 PM, David Cole >> wrote: >> >> On Tue, Aug 9, 2011 at 6:19 PM, James Bigler >> wrote: >> >>> I recently switched to 2.8.5 and noticed something strange. >> >>> >> >>> I have several files that build into a Debug|Release agnostic place. >> If I >> >>> build it in one then switch to the other the files don't regenerate, >> because >> >>> the build rule has been satisfied. >> >>> >> >>> With CMake 2.8.5 and VS 2010 I noticed something strange. It wanted >> to >> >>> build the files in both debug and release. I then looked at the >> vsproj >> >>> files and I noticed this: >> >>> >> >>> > >>> >> Condition="'$(Configuration)|$(Platform)'=='RelWithDebInfo|Win32'">C:\code\build-32-vs10-c40\lib\myfile_build.txt;%(Outputs) >> >>> >> >>> %(Outputs)??? Why is that in there. If I manually remove $(Outputs) >> then >> >>> it stops rebuilding my files. >> >>> >> >>> James >> >>> >> >>> >> >>> ___ >> >>> cmake-developers mailing list >> >>> cmake-developers@cmake.org >> >>> http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers >> >>> >> >>> >> >> >> >> The "%(Attribute)" notation means inherit the value from the same >> >> element in my "parent". So for a file's attribute, it typically >> >> inherits the value from the same named attribute in the project. >> >> >> >> In this case, I'm not entirely sure why it's there, but it's been >> >> there right from the very first commit adding the VS 10 generator to >> >> CMake: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7491f529 >> >> >> >> I can't think of the reason why it might be needed off the top of my >> >> head, so ... I'll try to remove it and see if all the tests pass. If >> >> they do, I suppose it should be ok to remove it. Does anybody else >> >> reading this thread have any other information? >> >> >> >> Thanks, >> >> David >> >> >> > >> > I constructed a custom build command that runs a batch file and >> > outputs a text file solely via the VS10 IDE... and there was no >> > "%(Outputs)" in the vcxproj file. So I think it's safe to remove this. >> > I'll push a change that does that. >> > >> > Thanks for the report, >> > David >> > >> >> This bug is quite possibly a report of the same thing, although, as >> noted in the bug, I could not reproduce the problem: >> http://public.kitware.com/Bug/view.php?id=12302 >> > > Drat! > > This doesn't actually seem to help. I'll see if I can create a smaller > test program that illustrates the issue. > > Does anyone know of a way to figure out why VS wants to build something > similar to a "make -d"? > > It would be really helpful to understand what is causing VS to rebuild > stuff. > > James > I've been buried in this for the past day and I think I might know what is going on. Unfortunately there doesn't appear to be an elegant solution to this other than perhaps filing a bug with Microsoft. >From my experimentation, it appears that custom build rules require being registered in the custombuild.command.1.tlog file that is put into the %(Intermediate Directory) location of the project. Since this location is generally different for Debug and Release builds, each configuration needs to run *all* the custom build rules at least once to populate this file. This the output from MSBuild when more detailed logging is enabled. Forcing rebuild of all source files due to missing command tlog "D:\win7x64\bugs\cmake-extra-build\VS-2010\cat-file\Release\custombuild.command.1.tlog". (TaskId:14) I'm not sure how to work around this aside from putting all non configuration dependent targets into a special project that has an intermediate directory that isn't %(Configuration) dependent. That doesn't seem like a lot of fun. Why MSBuild can't simply just populate the files without actually running the build commands if the dependencies are met seems like a little bit like a "missing feature", however it could be the mechanism to determine dependencies relies on that file being populated. Unfortunately for me where I have *many* non-configuration dependent custom build rules I have to rebuild all the files for each configuration. :( 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0012499]: VS 2010 custom rules with no output need to not have a command line
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=12499 == Reported By:James Bigler Assigned To: == Project:CMake Issue ID: 12499 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2011-10-06 12:48 EDT Last Modified: 2011-10-06 12:48 EDT == Summary:VS 2010 custom rules with no output need to not have a command line Description: I've noticed with some of my projects that the ZERO_CHECK project always runs. I think I narrowed it down to the fact that the rule for ZERO_CHECK.rule has a command line. The custom build machinery in VS 2010 seems to think that because the Output file, which in this case is non-existent and designed to be that way, needs to be built. D:\WIN7X64\BUGS\CMAKE-EXTRA-BUILD\BUILD-64-VS10\CMAKEFILES\ZERO_CHECK does not exist; source compilation required. (TaskId:14) CMakeFiles\ZERO_CHECK.rule will be compiled. (TaskId:14) If I remove the script from the command line that seems to do nothing, then the build behaves the way that it should. setlocal :cmEnd endlocal & call :cmErrorLevel %errorlevel% & goto :cmDone :cmErrorLevel exit /b %1 :cmDone if %errorlevel% neq 0 goto :VCEnd (TaskId:14) Steps to Reproduce: I've attached a simple CMake project. 1. Configure it and build twice. The second build will always build the ZERO_CHECK project. 2. Open the Property Pages for ZERO_CHECK.rule and remove the contents of the Command Line entry. 3. Delete the files in /x64/Debug/ZERO_CHECK/* This is needed to update the custom target files found in this directory that are used by MSbuild to determine dependencies. 4. Build twice. The second build will not rebuild the ZERO_CHECK project. Editing the CMakeLists.txt file will cause a rebuild as expected (though it will overwrite your local changes to the project files). == Issue History Date ModifiedUsername FieldChange == 2011-10-06 12:48 James Bigler New Issue 2011-10-06 12:48 James Bigler File Added: cmake-extra-build.7z == -- 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] [PATCH] LoadCommand test: cleanup
On 10/6/2011 8:24 AM, Rolf Eike Beer wrote:
Bill, that Watcom stuff was introduced by you in
9891260a6dab66c9ea44b5c2e244f3128625baf5.
I simply assumed it was a debug leftover as setting a variable to the value
it already has looks pretty pointless to me.
diff --git a/Tests/LoadCommand/CMakeCommands/CMakeLists.txt
b/Tests/LoadCommand/CMakeCommands/CMakeLists.txt
index 953d05c..5cdbc59 100644
--- a/Tests/LoadCommand/CMakeCommands/CMakeLists.txt
+++ b/Tests/LoadCommand/CMakeCommands/CMakeLists.txt
@@ -5,9 +5,6 @@ IF (MUDSLIDE_TYPE MATCHES MUCHO)
ADD_DEFINITIONS(-DMUCHO_MUDSLIDE)
ENDIF (MUDSLIDE_TYPE MATCHES MUCHO)
-IF(WATCOM)
- SET(CMAKE_C_FLAGS "${CMAKE_C_FLAGS}")
-ENDIF(WATCOM)
Hmmm... It could be some sort of odd escape thing going on that an
extra pass by the CMake parser fixes... I guess we can push it into the
dashboard and see if it fails. I can not remember at this point, but
watcom is a picky odd compiler.
-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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [PATCH] LoadCommand test: cleanup
>From be44756ad12e28b7640076f485f6a740ca6598d7 Mon Sep 17 00:00:00 2001
From: Rolf Eike Beer
Date: Thu, 6 Oct 2011 12:04:12 +0200
This removes some useless checking. The results of these things are never
properly checked so they should not count as testcases. At the end they only
needlessly clutter the output.
---
Tests/LoadCommand/CMakeCommands/CMakeLists.txt |3 ---
Tests/LoadCommand/CMakeLists.txt |6 --
Tests/LoadCommand/LoadedCommand.h.in |6 --
3 files changed, 0 insertions(+), 15 deletions(-)
Bill, that Watcom stuff was introduced by you in
9891260a6dab66c9ea44b5c2e244f3128625baf5.
I simply assumed it was a debug leftover as setting a variable to the value
it already has looks pretty pointless to me.
diff --git a/Tests/LoadCommand/CMakeCommands/CMakeLists.txt
b/Tests/LoadCommand/CMakeCommands/CMakeLists.txt
index 953d05c..5cdbc59 100644
--- a/Tests/LoadCommand/CMakeCommands/CMakeLists.txt
+++ b/Tests/LoadCommand/CMakeCommands/CMakeLists.txt
@@ -5,9 +5,6 @@ IF (MUDSLIDE_TYPE MATCHES MUCHO)
ADD_DEFINITIONS(-DMUCHO_MUDSLIDE)
ENDIF (MUDSLIDE_TYPE MATCHES MUCHO)
-IF(WATCOM)
- SET(CMAKE_C_FLAGS "${CMAKE_C_FLAGS}")
-ENDIF(WATCOM)
INCLUDE_DIRECTORIES(${CMAKE_ROOT}/include ${CMAKE_ROOT}/Source)
ADD_LIBRARY(cmCMAKE_TEST_COMMAND MODULE cmTestCommand.c)
diff --git a/Tests/LoadCommand/CMakeLists.txt b/Tests/LoadCommand/CMakeLists.txt
index e99105a..846cbb0 100644
--- a/Tests/LoadCommand/CMakeLists.txt
+++ b/Tests/LoadCommand/CMakeLists.txt
@@ -12,12 +12,6 @@ INCLUDE (CheckFunctionExists)
CHECK_FUNCTION_EXISTS(printfHAVE_PRINTF)
CHECK_FUNCTION_EXISTS(vsblabla HAVE_VSBLABLA)
-INCLUDE (${CMAKE_ROOT}/Modules/CheckIncludeFile.cmake)
-CHECK_INCLUDE_FILE("sys/prctl.h"HAVE_SYS_PRCTL_H)
-
-INCLUDE (${CMAKE_ROOT}/Modules/CheckLibraryExists.cmake)
-CHECK_LIBRARY_EXISTS(m ceil "" HAVE_LIBM)
-
CONFIGURE_FILE(${LoadCommand_SOURCE_DIR}/LoadedCommand.h.in
${LoadCommand_BINARY_DIR}/LoadedCommand.h)
diff --git a/Tests/LoadCommand/LoadedCommand.h.in
b/Tests/LoadCommand/LoadedCommand.h.in
index 7a0a15d..7516a66 100644
--- a/Tests/LoadCommand/LoadedCommand.h.in
+++ b/Tests/LoadCommand/LoadedCommand.h.in
@@ -5,9 +5,3 @@
/* Check for functions */
#cmakedefine HAVE_PRINTF
#cmakedefine HAVE_VSBLABLA
-
-/* Check for headers */
-#cmakedefine HAVE_SYS_PRCTL_H
-
-/* Check for libraries */
-#cmakedefine HAVE_LIBM
--
1.7.6.4
--
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-developers] [CMake 0012496]: Compiler tests ignore variables from command line when using toolchain file
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=12496
==
Reported By:Markus Klinik
Assigned To:
==
Project:CMake
Issue ID: 12496
Category: CMake
Reproducibility:always
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2011-10-06 03:50 EDT
Last Modified: 2011-10-06 03:50 EDT
==
Summary:Compiler tests ignore variables from command line
when using toolchain file
Description:
Have a toolchain file that sets cache variables. On the
command line, override the default values using the -D option. The overrides
are ignored by the configure-time compiler tests, but the overrides go to the
generated makefiles.
Example:
--- toolchain.cmake
set(ANDROID_NDK_ROOT "/home/nosuchuser/android-ndk-r6b" CACHE PATH "Android NDK
root")
message("ANDROID_NDK_ROOT is: " ${ANDROID_NDK_ROOT})
--- end of toolchain.cmake
--- CMakeLists.txt
project(foobar)
--- end of CMakeLists.txt
run cmake with the following command:
$ cmake -DANDROID_NDK_ROOT=/home/mkl/android-ndk
-DCMAKE_TOOLCHAIN_FILE=../toolchain.cmake ..
and observe that ANDROID_NDK_ROOT takes on the default value for the compiler
tests:
ANDROID_NDK_ROOT is: /home/mkl/android-ndk
ANDROID_NDK_ROOT is: /home/mkl/android-ndk
-- The C compiler identification is GNU
-- The CXX compiler identification is GNU
-- Check for working C compiler: /usr/bin/gcc
ANDROID_NDK_ROOT is: /home/nosuchuser/android-ndk-r6b
-- Check for working C compiler: /usr/bin/gcc -- works
-- Detecting C compiler ABI info
ANDROID_NDK_ROOT is: /home/nosuchuser/android-ndk-r6b
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
ANDROID_NDK_ROOT is: /home/nosuchuser/android-ndk-r6b
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
ANDROID_NDK_ROOT is: /home/nosuchuser/android-ndk-r6b
-- Detecting CXX compiler ABI info - done
-- Configuring done
-- Generating done
==
Issue History
Date ModifiedUsername FieldChange
==
2011-10-06 03:50 Markus Klinik New Issue
==
--
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
