[cmake-developers] [CMake 0013950]: FindBoost.cmake declares Boost_LIBRARY_DIRS as FILEPATH
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13950 == Reported By:Michael Riss Assigned To: == Project:CMake Issue ID: 13950 Category: Modules Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2013-02-25 07:48 EST Last Modified: 2013-02-25 07:48 EST == Summary:FindBoost.cmake declares Boost_LIBRARY_DIRS as FILEPATH Description: FindBoost.cmake declares the variable Boost_LIBRARY_DIRS as FILEPATH, thereby instructing cmake-gui to search for a file instead of a directory. = the file requester function of cmake-gui cannot be used to choose the Boost_LIBRARY_DIRS directory Suggestion: Change the type of the variable Boost_LIBRARY_DIRS in FindBoost.cmake from FILEPATH to PATH. Caution: The variable is declared in two locations in FindBoost.cmake, so two lines need to be edited. Steps to Reproduce: - use find_package( Boost ) in a CMakeLists.txt file - configure the project with cmake-gui - try to change the Boost_LIBRARY_DIRS variable using the FileRequester button = it's not possible to choose a directory, as the FileRequester wants to choose a file Additional Information: Workaround: it's still possible to set the directory path manually in cmake-gui with the line edit field. PS: I did the suggested changes and now I can select the directory also with the file requester. == Issue History Date ModifiedUsername FieldChange == 2013-02-25 07:48 Michael Riss 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
Re: [cmake-developers] INTERFACE_INCLUDE_DIRECTORIES on STATIC libs
On 02/23/2013 07:35 AM, Stephen Kelly wrote: As TARGET_DEFINED is not used in cmake now, I was considering removing it. If we remove it we'll have more freedom in the future to define it again if it is needed, or to define a similar expression with semantics we need. Currently the expression doesn't serve any need. Any objection to removing it? No. Please remove it for now. 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
Re: [cmake-developers] Should CMAKE_LINK_DEPENDS_NO_SHARED be on by default?
On 02/24/2013 10:29 AM, Stephen Kelly wrote: CMAKE_LINK_DEPENDS_NO_SHARED was introduced in this cycle, but off by default. It seems useful enough to be on by default. For reference, it was introduced in this thread: http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/43246/focus=44469 Is there any reason not to enable it by default? It is a change in default behavior. The current behavior was introduced a long time ago after some very subtle breakage occurred due to not re-linking dependents. However, the current behavior also makes everyone pay a cost in the common case to support the potentially rare cases where not re-linking is wrong. Unfortunately I do not remember enough detail about the original case to argue about whether it could be common (IIRC it had something to do with moving a .cxx from one shared library to another without changing any headers). If the option were to be on by default then instead there should be the reverse option off by default with a name like: CMAKE_LINK_DEPENDS_SHARED_LIBRARIES Otherwise we will ask every target to carry around a property setting just to get default behavior. -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] [CMake 0013951]: InstallRequiredSystemLibraries.cmake can not find x64 in redist folder.
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=13951
==
Reported By:ITF-EDV Fröschl GmbH
Assigned To:
==
Project:CMake
Issue ID: 13951
Category: CMake
Reproducibility:always
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2013-02-25 09:41 EST
Last Modified: 2013-02-25 09:41 EST
==
Summary:InstallRequiredSystemLibraries.cmake can not find
x64 in redist folder.
Description:
InstallRequiredSystemLibraries.cmake is checking
43: if(MSVC_VERSION GREATER 1599)
# VS 10 and later:
set(CMAKE_MSVC_ARCH x64)
message(STATUS MSVC_VERSION : ${MSVC_VERSION}) # Simple print out!
...
But the simple message(STATUS MSVC_VERSION : ${MSVC_VERSION}) print shows:
-- MSVC_VERSION : 2008. The variable content is not 1599!
Changing 1599 to 2008 would work for both, win32 (x86) or win64 (amd64) and
the system related *.dlls will be copied as expected!
Steps to Reproduce:
1. Include this lines in your Master CMakeLists.txt:
set(CMAKE_INSTALL_SYSTEM_RUNTIME_LIBS_SKIP TRUE)
include(InstallRequiredSystemLibraries)
install(PROGRAMS ${CMAKE_INSTALL_SYSTEM_RUNTIME_LIBS} DESTINATION bin COMPONENT
thirdparty)
2. Create solution with %ProgramFiles%\CMake 2.8\bin\cmake %OUR_SRC_ROOT% -G
Visual Studio 9 2008 Win64
Additional Information:
In our case we execute %ProgramFiles%\CMake 2.8\bin\cmake %OUR_SRC_ROOT% -G
Visual Studio 9 2008 Win64 from within a batch file.
-- Create the intermediate folder
F:\projects\itfedv\itfedv\batch\script\windows\..\..\..\..\intermediate\vs9\win64
-- Change into
F:\projects\itfedv\itfedv\batch\script\windows\..\..\..\..\intermediate\vs9\win64
...
-- Creating VisualStudio 9 (2008) Win64
-- The C compiler identification is MSVC 15.0.30729.1
-- The CXX compiler identification is MSVC 15.0.30729.1
-- Check for working C compiler using: Visual Studio 9 2008 Win64
-- Check for working C compiler using: Visual Studio 9 2008 Win64 -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler using: Visual Studio 9 2008 Win64
-- Check for working CXX compiler using: Visual Studio 9 2008 Win64 -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Looking for sys/types.h
-- Looking for sys/types.h - found
-- Looking for stdint.h
-- Looking for stdint.h - not found
-- Looking for stddef.h
-- Looking for stddef.h - found
-- Check size of void*
-- Check size of void* - done
...
CMake Warning at C:/Programme/CMake
2.8/share/cmake-2.8/Modules/InstallRequiredSystemLibraries.cmake:345 (message):
system runtime library file does not exist:
'MSVC90_REDIST_DIR-NOTFOUND/x64/Microsoft.VC90.CRT/Microsoft.VC90.CRT.manifest'
Call Stack (most recent call first):
cmake/MyNSIS.cmake:9 (include)
CMakeLists.txt:157 (include)
CMake Warning at C:/Programme/CMake
2.8/share/cmake-2.8/Modules/InstallRequiredSystemLibraries.cmake:345 (message):
system runtime library file does not exist:
'MSVC90_REDIST_DIR-NOTFOUND/x64/Microsoft.VC90.CRT/msvcm90.dll'
Call Stack (most recent call first):
cmake/MyNSIS.cmake:9 (include)
CMakeLists.txt:157 (include)
CMake Warning at C:/Programme/CMake
2.8/share/cmake-2.8/Modules/InstallRequiredSystemLibraries.cmake:345 (message):
system runtime library file does not exist:
'MSVC90_REDIST_DIR-NOTFOUND/x64/Microsoft.VC90.CRT/msvcp90.dll'
Call Stack (most recent call first):
cmake/MyNSIS.cmake:9 (include)
CMakeLists.txt:157 (include)
CMake Warning at C:/Programme/CMake
2.8/share/cmake-2.8/Modules/InstallRequiredSystemLibraries.cmake:345 (message):
system runtime library file does not exist:
'MSVC90_REDIST_DIR-NOTFOUND/x64/Microsoft.VC90.CRT/msvcr90.dll'
Call Stack (most recent call first):
cmake/MyNSIS.cmake:9 (include)
CMakeLists.txt:157 (include)
==
Issue History
Date ModifiedUsername FieldChange
==
2013-02-25 09:41 ITF-EDV Fröschl GmbHNew 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
Re: [cmake-developers] Should CMAKE_LINK_DEPENDS_NO_SHARED be on by default?
Brad King wrote: If the option were to be on by default then instead there should be the reverse option off by default with a name like: CMAKE_LINK_DEPENDS_SHARED_LIBRARIES I implemented that but one of the dashboards already fails: http://open.cdash.org/testDetails.php?test=178646760build=2827189 I don't know if that's just because of dirty-building, or because I extended the test, or because my logical change has a bug. 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] Should CMAKE_LINK_DEPENDS_NO_SHARED be on by default?
On 02/25/2013 11:46 AM, Stephen Kelly wrote: Brad King wrote: If the option were to be on by default then instead there should be the reverse option off by default with a name like: CMAKE_LINK_DEPENDS_SHARED_LIBRARIES I implemented that but one of the dashboards already fails: http://open.cdash.org/testDetails.php?test=178646760build=2827189 I don't know if that's just because of dirty-building, or because I extended the test, or because my logical change has a bug. It is a real failure. The problem is that on Windows the dependency goes through the import library (.lib), not the dll. The import library does not get updated when the .dll is rebuilt because the set of dllexport-ed symbols does not change. Therefore the _relink executable does not really need to relink. -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] Should CMAKE_LINK_DEPENDS_NO_SHARED be on by default?
On 02/25/2013 01:29 PM, Matthew Woehlke wrote: On 2013-02-24 10:29, Stephen Kelly wrote: CMAKE_LINK_DEPENDS_NO_SHARED was introduced in this cycle, but off by default. It seems useful enough to be on by default. Is there any reason not to enable it by default? What is the use case for this? I'm having a hard time imagining a case where it buys you anything. What would cause a .so to change often that you would *not* want to re-link? The case here is that when a .so re-links its *dependents* do not need to be re-linked too. Since the .so is not statically linked into the dependents they should not need to be linked again. The dynamic loader will simply see the updated .so at runtime. Refer back to the thread I linked earlier: http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/43246/focus=44469 -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] Should CMAKE_LINK_DEPENDS_NO_SHARED be on by default?
On Monday 25 February 2013, Brad King wrote: On 02/24/2013 10:29 AM, Stephen Kelly wrote: CMAKE_LINK_DEPENDS_NO_SHARED was introduced in this cycle, but off by default. It seems useful enough to be on by default. For reference, it was introduced in this thread: http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/43246/focus =44469 Is there any reason not to enable it by default? It is a change in default behavior. Maybe with a policy ? 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Should CMAKE_LINK_DEPENDS_NO_SHARED be on by default?
On 02/25/2013 02:18 PM, Alexander Neundorf wrote: It is a change in default behavior. Maybe with a policy ? How would it trigger? We can't warn on every target that links to a shared library. We're not changing any existing interfaces. The behavior only affects the dependencies placed in the build system. It won't affect one-shot builds, only developer workflow. The dependencies we're removing are a common source of complaints, and should not be necessary in normal situations. I am on the fence about the behavior change. The solution I added before, CMAKE_LINK_DEPENDS_NO_SHARED, has no change but allows developers to optimize extra linking out of their workflow by adding the setting themselves. -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] Should CMAKE_LINK_DEPENDS_NO_SHARED be on by default?
On Monday 25 February 2013, Brad King wrote: On 02/25/2013 02:18 PM, Alexander Neundorf wrote: It is a change in default behavior. Maybe with a policy ? How would it trigger? We can't warn on every target that links to a shared library. We're not changing any existing interfaces. if the requested version is higher, simply default to the new behaviour, otherwise to the old. This would be a bit different than the other policies. 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Should CMAKE_LINK_DEPENDS_NO_SHARED be on by default?
On 2013-02-25 14:00, Brad King wrote: On 02/25/2013 01:29 PM, Matthew Woehlke wrote: On 2013-02-24 10:29, Stephen Kelly wrote: CMAKE_LINK_DEPENDS_NO_SHARED was introduced in this cycle, but off by default. It seems useful enough to be on by default. Is there any reason not to enable it by default? What is the use case for this? I'm having a hard time imagining a case where it buys you anything. What would cause a .so to change often that you would *not* want to re-link? The case here is that when a .so re-links its *dependents* do not need to be re-linked too. Since the .so is not statically linked into the dependents they should not need to be linked again. The dynamic loader will simply see the updated .so at runtime. Refer back to the thread I linked earlier: http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/43246/focus=44469 I guess I'm still not seeing it without rereading the entire thread. Anyway, thanks for the quick explanation. I guess my personal opinion is that I can think of enough theoretical ways where a relink might be needed, and haven't encountered a project where the relink cost is sufficiently high, to feel that I would personally want to not relink. If CMake could somehow compare the public API that was previously linked, versus the new flavor thereof, I would probably be more willing to trust such an optimization. (One could also argue that this would be a better job for the build tool.) -- Matthew -- 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] Should CMAKE_LINK_DEPENDS_NO_SHARED be on by default?
On 02/25/2013 02:56 PM, Matthew Woehlke wrote: I guess my personal opinion is that I can think of enough theoretical ways where a relink might be needed, and haven't encountered a project where the relink cost is sufficiently high, to feel that I would personally want to not relink. You've just explained the reason CMake has works the way it does now ;) However, there have been complaints from people with projects that have hundreds of targets depending on a few shared libraries. A change to one of the core libraries takes a long time to re-link everything unnecessarily. The question is whether we should make everyone pay the cost to relink until they discover that a new CMake allows them to disable it, or make everyone take the risk of not relinking until they discover they need to set an option to play it safe. Can you elaborate on some of the theoretical cases where relinking will be needed but no header files have changed? It would be useful to have them available for discussion. -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] RE: Should CMAKE_LINK_DEPENDS_NO_SHARED be on by default?
Can you elaborate on some of the theoretical cases where relinking will be needed but no header files have changed? It would be useful to have them available for discussion. I can think of one, but it’s probably not that common: A header file declares a function prototype, but there is no implementation of it. When it’s discovered, when somebody finally tries to add an implementation, you only have the change the C++ file to add it. Of course, for the caller that discovers this, it had never linked successfully in the first place, and would relink after that rebuild anyhow... But for other callers that had never discovered it, though, a relink may be necessary in case the ordinals of some of the *other* functions in the dll changed due to the addition of one in the middle. Uncommon, but possible.-- 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] Should CMAKE_LINK_DEPENDS_NO_SHARED be on by default?
On 2013-02-25 15:02, Brad King wrote: Can you elaborate on some of the theoretical cases where relinking will be needed but no header files have changed? It would be useful to have them available for discussion. The possibility that first came to mind is where the API depends on compiler flags or similar preprocessor-ish bits, especially if these are not well guarded with something like a configured config.h to change when these change (and ensure that users get the same imports as what was built). For example, turning PIC on/off, changing the language support level, etc. might cause the API to change in a way that is not reflected in the headers (especially language support level, since most projects don't check for that... although conversely one can also hope that wouldn't cause an API break...). A slightly contrived example would be if you are relying on other than the CMake default-defined symbol to detect when your own library is being built, and forget to define it (or accidentally undefine it), such that all of the sudden there is a large change in your export set. Another example is running a system upgrade across a mass rebuild, such that system libraries are suddenly linked with a different compiler version than before. Depending on what else has changed, and how the system package manager works, I could see that this *might* not cause the time stamps on the header files to change. I wasn't thinking of it, but the example by dlrdave is also a good one, and in my experience not all that wildly unusual... only applies to lazy-resolving platforms, however (i.e. not Windows). To some extent, I suppose it comes down to how one weighs correctness versus speed. For most projects, the speed hit is probably small, so I'd be inclined to favor correctness, and recommend large projects that know that the cost for them is unusually high to override the choice. -- Matthew -- 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] Should CMAKE_LINK_DEPENDS_NO_SHARED be on by default?
Brad King wrote: On 02/25/2013 03:09 PM, dlrd...@aol.com wrote: Can you elaborate on some of the theoretical cases where relinking will be needed but no header files have changed? It would be useful to have them available for discussion. I can think of one, but it’s probably not that common: A header file declares a function prototype, but there is no implementation of it. When it’s discovered, when somebody finally tries to add an implementation, you only have the change the C++ file to add it. Of course, for the caller that discovers this, it had never linked successfully in the first place, and would relink after that rebuild anyhow... But for other callers that had never discovered it, though, a relink may be necessary in case the ordinals of some of the *other* functions in the dll changed due to the addition of one in the middle. Uncommon, but possible. Actually for DLL platforms the dependency goes on the import library, and some toolchains may not touch the import library if it has not changed. Perhaps we should not make this option affect DLL platforms. Some investigation into Windows toolchain behavior may be needed. As the DLL platforms (and Mac for a reason I don't see http://open.cdash.org/testDetails.php?test=176688935build=2827249) are failing, I've reverted the patches for now so as to not turn the dashboard all red tomorrow. 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] Should CMAKE_LINK_DEPENDS_NO_SHARED be on by default?
On 2/25/2013 5:18 PM, Matthew Woehlke wrote: The possibility that first came to mind is where the API depends on compiler flags or similar preprocessor-ish bits, especially if these are not well guarded with something like a configured config.h to change when these change (and ensure that users get the same imports as what was built). For example, turning PIC on/off, changing the language support level, etc. might cause the API to change in a way that is not reflected in the headers (especially language support level, since most projects don't check for that... although conversely one can also hope that wouldn't cause an API break...). A slightly contrived example would be if you are relying on other than the CMake default-defined symbol to detect when your own library is being built, and forget to define it (or accidentally undefine it), such that all of the sudden there is a large change in your export set. Another example is running a system upgrade across a mass rebuild, such that system libraries are suddenly linked with a different compiler version than before. Depending on what else has changed, and how the system package manager works, I could see that this *might* not cause the time stamps on the header files to change. I wasn't thinking of it, but the example by dlrdave is also a good one, and in my experience not all that wildly unusual... only applies to lazy-resolving platforms, however (i.e. not Windows). To some extent, I suppose it comes down to how one weighs correctness versus speed. For most projects, the speed hit is probably small, so I'd be inclined to favor correctness, and recommend large projects that know that the cost for them is unusually high to override the choice. These are all good examples. Of course since CMake already does the safe thing people would not have hit these. Steve, I think we should just leave CMAKE_LINK_DEPENDS_NO_SHARED as it is. If you want that behavior by default in KDE then set it in a high-level project's package configuration file. -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] [CMake 0013952]: CodeBlocks - NMake Makefiles generates broken xml if spaces in path
The following issue has been SUBMITTED. == http://cmake.org/Bug/view.php?id=13952 == Reported By:Timo R. Assigned To: == Project:CMake Issue ID: 13952 Category: CMake Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 2013-02-25 21:59 EST Last Modified: 2013-02-25 21:59 EST == Summary:CodeBlocks - NMake Makefiles generates broken xml if spaces in path Description: If there are spaces in the project path, the resulting .cbp project files contains lines like this: Build command=nmake /NOLOGO /f quot;C:\Users\BtbN\Documents\Visual Studio 2012\Projects\myproject\build\Makefilequot; VERBOSE=1 all / Seems like something feels the need to quote the path, but the quotes then break the xml and make it impossible to open the file in CodeBlocks or QtCreator. Steps to Reproduce: Place cmake based project somewhere in a path with Spaces on Windows. Generate using CodeBlocks - NMake Makefiles. Look at resulting .cbp file. Additional Information: No idea if other CodeBlocks generators are also affected, i can only test the nmake one on Windows. On linux, generating CodeBlocks - Unix Makefiles with spaces in path seems to work fine. == Issue History Date ModifiedUsername FieldChange == 2013-02-25 21:59 Timo R.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
[cmake-developers] [CMake 0013953]: Visual Studio Express 2008 not found
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=13953
==
Reported By:mseise
Assigned To:
==
Project:CMake
Issue ID: 13953
Category: CMake
Reproducibility:always
Severity: major
Priority: low
Status: new
==
Date Submitted: 2013-02-26 02:47 EST
Last Modified: 2013-02-26 02:47 EST
==
Summary:Visual Studio Express 2008 not found
Description:
My Visual Studio Express 2008 environment is not found, thus the correct
toolchain is not set up properly.
The problem is in CMakeVS9FindMake.cmake
The lines
set( _CMAKE_MAKE_PROGRAM_NAMES devenv)
if(NOT CMAKE_CROSSCOMPILING)
set( _CMAKE_MAKE_PROGRAM_NAMES ${_CMAKE_MAKE_PROGRAM_NAMES} VCExpress)
endif()
create the search String devenvVCExpress which is not found - for me the
simple workaround
set( _CMAKE_MAKE_PROGRAM_NAMES devenv)
if(NOT CMAKE_CROSSCOMPILING)
set( _CMAKE_MAKE_PROGRAM_NAMESVCExpress)
endif()
solved the issue.
Steps to Reproduce:
Just use any cmake setup...
Additional Information:
I have VS 2010 Professional and VC Express 2008 with 64 bit setup installed (for
building python 2.7 bindings of ITK)
==
Issue History
Date ModifiedUsername FieldChange
==
2013-02-26 02:47 mseise 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
Re: [CMake] Patch utility is installed, but my ExternalProject build step fails to execute it
Am Sonntag, 24. Februar 2013 um 19:58:53, schrieb David Brown
cypher...@gmail.com
I'm trying to patch and build a Makefile-based project using the
ExternalProject module. My patch command looks like this:
PATCH_COMMAND patch -p1 -t -N
${CMAKE_CURRENT_SOURCE_DIR}/IntelDFP.patch
When building, however, I get this:
[ 10%] Performing patch step for 'IntelDFP'
/bin/sh: 1: patch -p1 -t -N
/home/david/Projects/db/IntelDFP.patch: not found
I'm certain that the patch utility is installed and that the patch
file path is correct. If I run that command myself, it works fine. So
why does the CMake-generated Makefile fail to execute it?
How should cmake know, that you do not mean a command with blanks in his path?
Try
PATCH_COMMAND patch -p1 -t -N
${CMAKE_CURRENT_SOURCE_DIR}/IntelDFP.patch
or
PATCH_COMMAND patch -p1 -t -N
${CMAKE_CURRENT_SOURCE_DIR}/IntelDFP.patch
Kornel
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] Patch utility is installed, but my ExternalProject build step fails to execute it
David Brown wrote:
I'm trying to patch and build a Makefile-based project using the
ExternalProject module. My patch command looks like this:
PATCH_COMMAND patch -p1 -t -N
${CMAKE_CURRENT_SOURCE_DIR}/IntelDFP.patch
When building, however, I get this:
[ 10%] Performing patch step for 'IntelDFP'
/bin/sh: 1: patch -p1 -t -N
/home/david/Projects/db/IntelDFP.patch: not found
I'm certain that the patch utility is installed and that the patch
file path is correct. If I run that command myself, it works fine. So
why does the CMake-generated Makefile fail to execute it?
If it is GNU patch I suggest you use -i instead of piping, this has the chance
to work without a shell being available.
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
[CMake] Resolving static lib dependency at executable link time
Hello everyone, This is certainly a known issue but I coulnd't find anything related to this needs on internet : I got : an executable EX, a static library B and a static library C with cross dependencies : libB depends on libC and libC depends on libB. EX depends on libB If I write : TARGET_LINK_LIBRARIES(libB libC) TARGET_LINK_LIBRARIES(libC libB) TARGET_LINK_LIBRARIES(EX libB) Code compiles and everything is fine. But then I would like to compile with two different flavor of libC : libC1 and libC2 both available with one make. I want to do : TARGET_LINK_LIBRARIES(libB ???) TARGET_LINK_LIBRARIES(libC1 libB) TARGET_LINK_LIBRARIES(libC2 libB) TARGET_LINK_LIBRARIES(EX1 libB libC1) TARGET_LINK_LIBRARIES(EX2 libB libC2) Problem is that if I don't set the right TARGET_LINK_LIBRARIES for libB I got unresolved dependencies at EX1/2 link time for symbol resolved in libCXXX. Having a library libB1 and libB2 is not an option. Any idea anyone ? Thanks a lot Pierre -- 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] Resolving static lib dependency at executable link time
libB depends on libC and libC depends on libB. How is that even possible? You compile B and it fails because there's no C yet. You compile C and it fails because there's no B yet. -- 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] Resolving static lib dependency at executable link time
Well it is indeed possible and it works... Note that static libraries 's object files are built with unresolved symbols. Final resolution is performed when building executable Therefore libB can compile without libC and conversely ... Anyone else ? On Mon, Feb 25, 2013 at 12:23 PM, Ansis Māliņš ansis.mal...@gmail.comwrote: libB depends on libC and libC depends on libB. How is that even possible? You compile B and it fails because there's no C yet. You compile C and it fails because there's no B yet. -- 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] Resolving static lib dependency at executable link time
Hello Pierre, my knowledge concerning the linking process is rather limited, but wouldn't that mean you don't need to inter-link the libraries at all, when the symbols are resolved at link-time with the executable? add_executable(ex1 libB libC1 libC2) should suffice then. Best regards, Andreas Am 25.02.2013 um 13:47 schrieb Pierre Mallard: Well it is indeed possible and it works... Note that static libraries 's object files are built with unresolved symbols. Final resolution is performed when building executable Therefore libB can compile without libC and conversely ... Anyone else ? On Mon, Feb 25, 2013 at 12:23 PM, Ansis Māliņš ansis.mal...@gmail.com wrote: libB depends on libC and libC depends on libB. How is that even possible? You compile B and it fails because there's no C yet. You compile C and it fails because there's no B yet. -- 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 smime.p7s Description: S/MIME cryptographic signature -- 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] Resolving static lib dependency at executable link time
I think you shouldn't make B depend on anything, and just make sure that you list all the libs you need at executable link time. Sent from my iPhone On Feb 25, 2013, at 7:47, Pierre Mallard mallard.pie...@gmail.com wrote: Well it is indeed possible and it works... Note that static libraries 's object files are built with unresolved symbols. Final resolution is performed when building executable Therefore libB can compile without libC and conversely ... Anyone else ? On Mon, Feb 25, 2013 at 12:23 PM, Ansis Māliņš ansis.mal...@gmail.com wrote: libB depends on libC and libC depends on libB. How is that even possible? You compile B and it fails because there's no C yet. You compile C and it fails because there's no B yet. -- 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] Resolving static lib dependency at executable link time
Hello Pierre, self reply as a correction, sorry: what I meant was that only linking the executables TARGET_LINK_LIBRARIES(EX1 libB libC1) TARGET_LINK_LIBRARIES(EX2 libB libC2) should suffice. Andreas Am 25.02.2013 um 14:14 schrieb Andreas Stahl: Hello Pierre, my knowledge concerning the linking process is rather limited, but wouldn't that mean you don't need to inter-link the libraries at all, when the symbols are resolved at link-time with the executable? add_executable(ex1 libB libC1 libC2) should suffice then. Best regards, Andreas Am 25.02.2013 um 13:47 schrieb Pierre Mallard: Well it is indeed possible and it works... Note that static libraries 's object files are built with unresolved symbols. Final resolution is performed when building executable Therefore libB can compile without libC and conversely ... Anyone else ? On Mon, Feb 25, 2013 at 12:23 PM, Ansis Māliņš ansis.mal...@gmail.com wrote: libB depends on libC and libC depends on libB. How is that even possible? You compile B and it fails because there's no C yet. You compile C and it fails because there's no B yet. -- 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 smime.p7s Description: S/MIME cryptographic signature -- 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] Resolving static lib dependency at executable link time
Hi everyone, Reading answer from leif and andreas, leads me to advance a bit. To my opinion writing target_link_libraries(exe1 libB libC) would certainly works (but I m not able to test it at the moment). But my problem should be explain the more tricky way : libB depends on libC function implementation but is a dependency of libD : I got Exe depends upon libD which use libB which use libC. libC uses function defined in libB. If I try Leif and Andreas idea : TARGET_LINK_LIBRARIES(Exe1 libD libC1) This line leads to output this gcc link line (schematically) : gcc -o exe1 libD libC1 libB Dependency of libD appears after all other executable direct dependencies This does not work since libB depends on libC. The right gcc line would be : gcc -o exe1 libD libC1 libB libC1 libB I know this repetition of libB libC1 looks a bit stupid but it does not work else ... These last line of gcc is what is done when setting all dependency. (TARGET_LINK_LIBRARIES(libB libC1) and TARGET_LINK_LIBRARIES(libC1 libB) but again the whole solution would require to build twice libB (and therefore libD and etc etc) to build with two different flavor of libC (libC1 and libC2). Thks for your help ... Pierre On Mon, Feb 25, 2013 at 2:14 PM, Andreas Stahl andreas.st...@tu-dresden.dewrote: Hello Pierre, my knowledge concerning the linking process is rather limited, but wouldn't that mean you don't need to inter-link the libraries at all, when the symbols are resolved at link-time with the executable? add_executable(ex1 libB libC1 libC2) should suffice then. Best regards, Andreas Am 25.02.2013 um 13:47 schrieb Pierre Mallard: Well it is indeed possible and it works... Note that static libraries 's object files are built with unresolved symbols. Final resolution is performed when building executable Therefore libB can compile without libC and conversely ... Anyone else ? On Mon, Feb 25, 2013 at 12:23 PM, Ansis Māliņš ansis.mal...@gmail.com wrote: libB depends on libC and libC depends on libB. How is that even possible? You compile B and it fails because there's no C yet. You compile C and it fails because there's no B yet. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Resolving static lib dependency at executable link time
I see. I would not try to express this complexity to cmake. Is there a way you can separate the alternate functionality out of C so that it doesn't cause the dependency graph to fragment this way? Usually circular dependencies mean you need to refactor something anyway. If you can make the dep graph more like this it could work: EX1: D C B C B X1 EX2: D C B C B X2 (Where C1 was split into C and X1, and C2 was split into C and X2) Sent from my iPhone On Feb 25, 2013, at 8:38, Pierre Mallard mallard.pie...@gmail.com wrote: Hi everyone, Reading answer from leif and andreas, leads me to advance a bit. To my opinion writing target_link_libraries(exe1 libB libC) would certainly works (but I m not able to test it at the moment). But my problem should be explain the more tricky way : libB depends on libC function implementation but is a dependency of libD : I got Exe depends upon libD which use libB which use libC. libC uses function defined in libB. If I try Leif and Andreas idea : TARGET_LINK_LIBRARIES(Exe1 libD libC1) This line leads to output this gcc link line (schematically) : gcc -o exe1 libD libC1 libB Dependency of libD appears after all other executable direct dependencies This does not work since libB depends on libC. The right gcc line would be : gcc -o exe1 libD libC1 libB libC1 libB I know this repetition of libB libC1 looks a bit stupid but it does not work else ... These last line of gcc is what is done when setting all dependency. (TARGET_LINK_LIBRARIES(libB libC1) and TARGET_LINK_LIBRARIES(libC1 libB) but again the whole solution would require to build twice libB (and therefore libD and etc etc) to build with two different flavor of libC (libC1 and libC2). Thks for your help ... Pierre On Mon, Feb 25, 2013 at 2:14 PM, Andreas Stahl andreas.st...@tu-dresden.de wrote: Hello Pierre, my knowledge concerning the linking process is rather limited, but wouldn't that mean you don't need to inter-link the libraries at all, when the symbols are resolved at link-time with the executable? add_executable(ex1 libB libC1 libC2) should suffice then. Best regards, Andreas Am 25.02.2013 um 13:47 schrieb Pierre Mallard: Well it is indeed possible and it works... Note that static libraries 's object files are built with unresolved symbols. Final resolution is performed when building executable Therefore libB can compile without libC and conversely ... Anyone else ? On Mon, Feb 25, 2013 at 12:23 PM, Ansis Māliņš ansis.mal...@gmail.com wrote: libB depends on libC and libC depends on libB. How is that even possible? You compile B and it fails because there's no C yet. You compile C and it fails because there's no B yet. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake -- 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] Resolving static lib dependency at executable link time
Surely I can refactor code to avoid cross-dependencies... But the problem is more on the definition of the target link line at executable level than on cross dependency. Indeed even if C does not depends on B, or in your example X, writing TARGET_LINK_LIBRARIES(EX1 libD libX1) would always leads to have libB written after libX1 in gcc command line. However I finally understand why order of library is a problem in gcc. It is because unneeded symbol at time gcc find library in command line are discarded. Therefore when libC comes before libB, all libC symbols used by libB are removed because they are not needed by preceding libraries, and when gcc reach libB there is not the symbol libB needs. Solution is to force gcc to keep all symbols of libC : TARGET_LINK_LIBRARIES(exe1 libD -Wl,-whole-archive libC1 -Wl,-no-whole-archive) And know we are able to remove TARGET_LINK_LIBRARIES(libB libC1) and TARGET_LINK_LIBRARIES(libC libB). My problem is solve ! Thanks for your help, Pierre On Mon, Feb 25, 2013 at 2:44 PM, Leif Walsh leif.wa...@gmail.com wrote: I see. I would not try to express this complexity to cmake. Is there a way you can separate the alternate functionality out of C so that it doesn't cause the dependency graph to fragment this way? Usually circular dependencies mean you need to refactor something anyway. If you can make the dep graph more like this it could work: EX1: D C B C B X1 EX2: D C B C B X2 (Where C1 was split into C and X1, and C2 was split into C and X2) Sent from my iPhone On Feb 25, 2013, at 8:38, Pierre Mallard mallard.pie...@gmail.com wrote: Hi everyone, Reading answer from leif and andreas, leads me to advance a bit. To my opinion writing target_link_libraries(exe1 libB libC) would certainly works (but I m not able to test it at the moment). But my problem should be explain the more tricky way : libB depends on libC function implementation but is a dependency of libD : I got Exe depends upon libD which use libB which use libC. libC uses function defined in libB. If I try Leif and Andreas idea : TARGET_LINK_LIBRARIES(Exe1 libD libC1) This line leads to output this gcc link line (schematically) : gcc -o exe1 libD libC1 libB Dependency of libD appears after all other executable direct dependencies This does not work since libB depends on libC. The right gcc line would be : gcc -o exe1 libD libC1 libB libC1 libB I know this repetition of libB libC1 looks a bit stupid but it does not work else ... These last line of gcc is what is done when setting all dependency. (TARGET_LINK_LIBRARIES(libB libC1) and TARGET_LINK_LIBRARIES(libC1 libB) but again the whole solution would require to build twice libB (and therefore libD and etc etc) to build with two different flavor of libC (libC1 and libC2). Thks for your help ... Pierre On Mon, Feb 25, 2013 at 2:14 PM, Andreas Stahl andreas.st...@tu-dresden.de wrote: Hello Pierre, my knowledge concerning the linking process is rather limited, but wouldn't that mean you don't need to inter-link the libraries at all, when the symbols are resolved at link-time with the executable? add_executable(ex1 libB libC1 libC2) should suffice then. Best regards, Andreas Am 25.02.2013 um 13:47 schrieb Pierre Mallard: Well it is indeed possible and it works... Note that static libraries 's object files are built with unresolved symbols. Final resolution is performed when building executable Therefore libB can compile without libC and conversely ... Anyone else ? On Mon, Feb 25, 2013 at 12:23 PM, Ansis Māliņš ansis.mal...@gmail.com wrote: libB depends on libC and libC depends on libB. How is that even possible? You compile B and it fails because there's no C yet. You compile C and it fails because there's no B yet. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake -- 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:
Re: [CMake] CMAKE_SYSTEM_PROCESSOR says x86 on Win64 - Patch
Martin Koller wrote:
On Saturday 23 February 2013 14:58:11 Rolf Eike Beer wrote:
Martin Koller wrote:
On Friday 22 February 2013 12:23:23 Koller, Martin wrote:
I propose the attached patch for CMakeDetermineSystem.cmake
Can someone add this to the mentioned mantis bug entry or shall I
create a
new one ?
Revised patch which ignores the case of amd64 so that AMD64 works as
well
No, this is wrong. As you can read in the blog post you refer to there is
also IA64, and Windows on ARM could be near, too. So for both of those
platform we now would have x86 reported.
My code would look like this:
if ($ENV{PROCESSOR_ARCHITEW6432})
set(CMAKE_HOST_SYSTEM_PROCESSOR $ENV{PROCESSOR_ARCHITEW6432})
else()
set(CMAKE_HOST_SYSTEM_PROCESSOR $ENV{PROCESSOR_ARCHITECTURE})
endif()
This will also keep the casing to avoid confusion, just keep the values
the OS gives you as long as they are consistent in themself.
Great, even better.
What to do so this solution will make its way into the next official cmake
version ?
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=add8d22acc9417cb144a0b497f4f5ef330bfc680
Please wait a day or 2 and then download a snapshot and test if it behaves
properly.
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] Toolchain file: Texas Instrument C6000 Code Generation Tools
Shall I force the compiler? This is all I can find on the CMake Cross Compiling wiki: If your compiler is not able to build a simple program by default without special flags or files (e.g. linker scripts or memory layout files), the toolchain file as shown above doesn't work. Then you have to *force* the compiler: It would be nice to have a bit more thorough documentation. This is not yet clear to me if it applies against my scenario or I can avoid forcing. Anyone knowing something about this? On Sun, Feb 24, 2013 at 10:28 PM, Laszlo Papp lp...@kde.org wrote: Here you can find the toolchain file I created: https://projects.kde.org/projects/playground/mobile/wiki-reader/repository/revisions/master/entry/frontends/blackberry/cmake/Toolchain-C6X.cmake I think the issue boils down to this: root /home/lpapp/Projects/qt/skeleton/build # /opt/ti/C6000CGT7.4.2/bin/cl6x --abi=eabi --run_linker ../main.c Linking ../main.c, line 1: error: cannot find file int ../main.c, line 1: error: cannot find file main ../main.c, line 1: error: expecting filename, option, MEMORY, or SECTIONS instead of ( ../main.c, line 4: error: expecting filename, option, MEMORY, or SECTIONS instead of } fatal error: no input files Compilation failure root /home/lpapp/Projects/qt/skeleton/build # /opt/ti/C6000CGT7.4.2/bin/cl6x --abi=eabi ../main.c --run_linker Linking warning: automatic library build: using library /opt/ti/C6000CGT7.4.2/lib/rts6200_elf.lib for the first time, so it must be built. This may take a few minutes. Do you have any ideas how to solve this issue? It seems to me that, I would need to pass the source files before the linker option. Laszlo -- 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] How to set CTest Update Options correctly
Hello, i've set CTEST_UPDATE_OPTIONS as followed: set(CTEST_UPDATE_OPTIONS --tags) I set this, because I need newely created and/or modified tags. When I set this option then I get the error: git.cmd fetch --tags Update command failed Is there an other way of doing so? Thanks in advance Best Regards -- 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] Please critique my hello world CMakeLists.txt and Config.cmake
On Sunday 24 February 2013, Chris Stankevitz wrote:
On Sun, Feb 24, 2013 at 12:37 PM, Alexander Neundorf
a.neundorf-w...@gmx.net wrote:
github links:
https://github.com/chrisstankevitz/hello
https://github.com/chrisstankevitz/hello-client
Maybe we'll start with the old way and get to the new way.
Alex,
Thank you again. I updated the projects per your teaching. The only
place I had to guess was here:
INSTALL(
FILES
${CMAKE_CURRENT_BINARY_DIR}/helloConfig.cmake
DESTINATION
${hello_DIRNAME_lib}
)
With respect to this INSTALL directive, I have three questions:
1. Is it needed? [Apparently the answer is yes]
Yes, this installs the Config.cmake file to a place where it will be found by
find_package().
If you would only install(EXPORT ... FILE helloConfig.cmake) , i.e. name the
exported target file Config.cmake, then you wouldn't have a place where you
can set the include directory variables or other information.
2. Is ${CMAKE_CURRENT_BINARY_DIR}/helloConfig.cmake the appropriate
way for me to reference this file? I got this from kdelibs.git.
Yes. configure_file() creates the output files in CMAKE_CURRENT_BINARY_DIR if
you don't tell it to put it somewhere else.
3. Is ${hello_DIRNAME_lib} (aka
/usr/local/lib/hello-1.1/helloConfig.cmake) the correct place to
install helloConfig.cmake? kdelibs.git puts it somewhere else
(${CMAKECONFIG_INSTALL_DIR} which I guessed corresponds to the weird
location /usr/local/hello/).
See the documentation for find_package(), for the locations where it searches
Config.cmake files.
lib/hello-1.1/helloConfig.cmake sounds good, this should be the
prefix/(lib/arch|lib|share)/name*/ case from the docs.
kdelibs puts it into lib/cmake/name/
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
Re: [CMake] How to set CTest Update Options correctly
Hello again,
CTEST_UPDATE_COMMAND is set to ${GIT_EXECUTABLE}.
I also tried to extend the CTEST_CHECKOUT_COMMAND variable, but here I get also
an error.
Please, could someone help?
Thanks in advance
Am 25.02.2013 um 18:15 schrieb NoRulez noru...@me.com:
Hello,
i've set CTEST_UPDATE_OPTIONS as followed:
set(CTEST_UPDATE_OPTIONS --tags)
I set this, because I need newely created and/or modified tags.
When I set this option then I get the error:
git.cmd fetch --tags Update command failed
Is there an other way of doing so?
Thanks in advance
Best Regards
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
[Cmake-commits] CMake branch, next, updated. v2.8.10.2-2323-g20e424b
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 20e424b3acdb0fea04e54720da33e3e5f6031816 (commit)
via cbf07569ed0a1e64b7131ba989c2cc16f1e3c16f (commit)
via 21a342c8b16df2cc9ea34ef494ba8ffd7f3a450a (commit)
via 47b8d322a4d9598706948553dfbf9daebe80dcef (commit)
via 2e39d21c87786d7b714dd0f88ec4386fce8ac0b1 (commit)
via 2de047669fd35cc293a29745990f26084a9b608a (commit)
via 976cdf5488ad53ca5500f83f39e8594e0e440fdd (commit)
from 5cbeeef9ccb4d6bc9a46b8a559c4f4eaa9c64958 (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=20e424b3acdb0fea04e54720da33e3e5f6031816
commit 20e424b3acdb0fea04e54720da33e3e5f6031816
Merge: 5cbeeef cbf0756
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Mon Feb 25 10:00:33 2013 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Mon Feb 25 10:00:33 2013 -0500
Merge topic 'remove-TARGET_DEFINED-genex' into next
cbf0756 Revert Add the TARGET_DEFINED generator expression
21a342c Remove use of TARGET_DEFINED from the target_link_libraries test.
47b8d32 Remove use of TARGET_DEFINED from the ExportImport test.
2e39d21 Remove use of TARGET_DEFINED from target_include_directories test.
2de0476 CMake Nightly Date Stamp
976cdf5 CMake Nightly Date Stamp
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=cbf07569ed0a1e64b7131ba989c2cc16f1e3c16f
commit cbf07569ed0a1e64b7131ba989c2cc16f1e3c16f
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Sat Feb 23 13:30:38 2013 +0100
Commit: Stephen Kelly steve...@gmail.com
CommitDate: Mon Feb 25 15:35:11 2013 +0100
Revert Add the TARGET_DEFINED generator expression
This reverts commit 2bee6f5ba5b3f33817cc00e056a7df60d05c9399.
This expression is not used, and has a semantic which is not completely
optimal (namely considering utility targets to be targets, though
usually we are interested in linkable targets).
Remove it so that we have more freedom to define better expressions in
the future.
Conflicts:
Source/cmGeneratorExpressionEvaluator.cxx
Tests/CMakeCommands/target_compile_definitions/CMakeLists.txt
Tests/CMakeCommands/target_compile_definitions/consumer.cpp
diff --git a/Source/cmDocumentGeneratorExpressions.h
b/Source/cmDocumentGeneratorExpressions.h
index 8b80a8a..76a60c3 100644
--- a/Source/cmDocumentGeneratorExpressions.h
+++ b/Source/cmDocumentGeneratorExpressions.h
@@ -37,7 +37,6 @@
target in the same buildsystem. Expands to the empty string \
otherwise.\n\
$TARGET_FILE:tgt= main file (.exe, .so.1.2, .a)\n \
-$TARGET_DEFINED:tgt = '1' if tgt is a target, else '0'\n\
$TARGET_LINKER_FILE:tgt = file used to link (.a, .lib, .so)\n \
$TARGET_SONAME_FILE:tgt = file with soname (.so.3)\n\
where \tgt\ is the name of a target. \
diff --git a/Source/cmGeneratorExpressionEvaluator.cxx
b/Source/cmGeneratorExpressionEvaluator.cxx
index cd6a40b..b5fe8ba 100644
--- a/Source/cmGeneratorExpressionEvaluator.cxx
+++ b/Source/cmGeneratorExpressionEvaluator.cxx
@@ -291,22 +291,6 @@ static const struct ConfigurationTestNode : public
cmGeneratorExpressionNode
} configurationTestNode;
-static const struct TargetDefinedNode : public cmGeneratorExpressionNode
-{
- TargetDefinedNode() {}
-
- virtual int NumExpectedParameters() const { return 1; }
-
- std::string Evaluate(const std::vectorstd::string parameters,
- cmGeneratorExpressionContext *context,
- const GeneratorExpressionContent *,
- cmGeneratorExpressionDAGChecker *) const
- {
-return context-Makefile-FindTargetToUse(parameters.front().c_str())
- ? 1 : 0;
- }
-} targetDefinedNode;
-
//
static const char* targetPropertyTransitiveWhitelist[] = {
INTERFACE_INCLUDE_DIRECTORIES
@@ -942,8 +926,6 @@ cmGeneratorExpressionNode* GetNode(const std::string
identifier)
return buildInterfaceNode;
else if (identifier == INSTALL_INTERFACE)
return installInterfaceNode;
- else if (identifier == TARGET_DEFINED)
-return targetDefinedNode;
else if (identifier == INSTALL_PREFIX)
return installPrefixNode;
return 0;
diff --git a/Tests/CMakeCommands/target_compile_definitions/CMakeLists.txt
b/Tests/CMakeCommands/target_compile_definitions/CMakeLists.txt
index 8a4437b..6d0e646 100644
---
[Cmake-commits] CMake branch, next, updated. v2.8.10.2-2326-g17bfe72
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 17bfe720a97c51ad1e6cc1268c5ef6e1b57a71e2 (commit)
via add8d22acc9417cb144a0b497f4f5ef330bfc680 (commit)
via e597ba29288db609d0c3c797848fa7649851b1ee (commit)
from 20e424b3acdb0fea04e54720da33e3e5f6031816 (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=17bfe720a97c51ad1e6cc1268c5ef6e1b57a71e2
commit 17bfe720a97c51ad1e6cc1268c5ef6e1b57a71e2
Merge: 20e424b add8d22
Author: Rolf Eike Beer e...@sf-mail.de
AuthorDate: Mon Feb 25 10:16:34 2013 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Mon Feb 25 10:16:34 2013 -0500
Merge topic 'Win-HOST_SYSTEM_PROCESSOR' into next
add8d22 properly detect processor architecture on Windows
e597ba2 CMake Nightly Date Stamp
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=add8d22acc9417cb144a0b497f4f5ef330bfc680
commit add8d22acc9417cb144a0b497f4f5ef330bfc680
Author: Rolf Eike Beer e...@sf-mail.de
AuthorDate: Mon Feb 25 16:14:36 2013 +0100
Commit: Rolf Eike Beer e...@sf-mail.de
CommitDate: Mon Feb 25 16:14:36 2013 +0100
properly detect processor architecture on Windows
CMake is usually run as a 32 bit process even on 64 bit Windows, so the
PROCESSOR_ARCHITECTURE environment variable would always return x86. This
post
gives a description on how to do it properly:
http://blogs.msdn.com/b/david.wang/archive/2006/03/26/howto-detect-process-bitness.aspx
diff --git a/Modules/CMakeDetermineSystem.cmake
b/Modules/CMakeDetermineSystem.cmake
index c7f9c32..20c1541 100644
--- a/Modules/CMakeDetermineSystem.cmake
+++ b/Modules/CMakeDetermineSystem.cmake
@@ -73,7 +73,11 @@ if(CMAKE_HOST_UNIX)
else()
if(CMAKE_HOST_WIN32)
set (CMAKE_HOST_SYSTEM_NAME Windows)
-set (CMAKE_HOST_SYSTEM_PROCESSOR $ENV{PROCESSOR_ARCHITECTURE})
+if (ENV{PROCESSOR_ARCHITEW6432})
+ set (CMAKE_HOST_SYSTEM_PROCESSOR $ENV{PROCESSOR_ARCHITEW6432})
+else()
+ set (CMAKE_HOST_SYSTEM_PROCESSOR $ENV{PROCESSOR_ARCHITECTURE})
+endif()
endif()
endif()
---
Summary of changes:
Modules/CMakeDetermineSystem.cmake |6 +-
Source/CMakeVersion.cmake |2 +-
2 files changed, 6 insertions(+), 2 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.10.2-2329-g64ca954
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 64ca9549f1c8d0a357c99bcb3867298f52abc25c (commit) via 6e954854c1afeefcf8621f213dda55e66cea42d1 (commit) via 02aa1e4be3c45a22f27394d0dadc12667ce1430d (commit) from 17bfe720a97c51ad1e6cc1268c5ef6e1b57a71e2 (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=64ca9549f1c8d0a357c99bcb3867298f52abc25c commit 64ca9549f1c8d0a357c99bcb3867298f52abc25c Merge: 17bfe72 6e95485 Author: Stephen Kelly steve...@gmail.com AuthorDate: Mon Feb 25 11:09:40 2013 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Mon Feb 25 11:09:40 2013 -0500 Merge topic 'add-CMAKE_LINK_DEPENDS_SHARED_LIBRARIES-variable' into next 6e95485 Don't relink shared libraries by default if dependencies files change. 02aa1e4 Cover both cases of shared lib depends in the BuildDepends test. http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6e954854c1afeefcf8621f213dda55e66cea42d1 commit 6e954854c1afeefcf8621f213dda55e66cea42d1 Author: Stephen Kelly steve...@gmail.com AuthorDate: Mon Feb 25 16:59:53 2013 +0100 Commit: Stephen Kelly steve...@gmail.com CommitDate: Mon Feb 25 17:05:39 2013 +0100 Don't relink shared libraries by default if dependencies files change. This replaces the LINK_DEPENDS_NO_SHARED target property and associated variable introduced in commit ed976313 (Optionally skip link dependencies on shared library files, 2012-10-26) with LINK_DEPENDS_SHARED_LIBRARIES which is the logical opposite. diff --git a/Source/cmComputeLinkInformation.cxx b/Source/cmComputeLinkInformation.cxx index 84714f3..28c7b09 100644 --- a/Source/cmComputeLinkInformation.cxx +++ b/Source/cmComputeLinkInformation.cxx @@ -281,7 +281,7 @@ cmComputeLinkInformation // Check whether we should skip dependencies on shared library files. this-LinkDependsNoShared = -this-Target-GetPropertyAsBool(LINK_DEPENDS_NO_SHARED); +!this-Target-GetPropertyAsBool(LINK_DEPENDS_SHARED_LIBRARIES); // On platforms without import libraries there may be a special flag // to use when creating a plugin (module) that obtains symbols from diff --git a/Source/cmDocumentVariables.cxx b/Source/cmDocumentVariables.cxx index 204bd9a..5fe1f28 100644 --- a/Source/cmDocumentVariables.cxx +++ b/Source/cmDocumentVariables.cxx @@ -1260,9 +1260,9 @@ void cmDocumentVariables::DefineVariables(cmake* cm) Variables that Control the Build); cm-DefineProperty -(CMAKE_LINK_DEPENDS_NO_SHARED, cmProperty::VARIABLE, +(CMAKE_LINK_DEPENDS_SHARED_LIBRARIES, cmProperty::VARIABLE, Whether to skip link dependencies on shared library files., - This variable initializes the LINK_DEPENDS_NO_SHARED + This variable initializes the LINK_DEPENDS_SHARED_LIBRARIES property on targets when they are created. See that target property for additional information., false, diff --git a/Source/cmTarget.cxx b/Source/cmTarget.cxx index 003f3d8..c92004c 100644 --- a/Source/cmTarget.cxx +++ b/Source/cmTarget.cxx @@ -706,19 +706,19 @@ void cmTarget::DefineProperties(cmake *cm) custom Makefile link rules.); cm-DefineProperty -(LINK_DEPENDS_NO_SHARED, cmProperty::TARGET, - Do not depend on linked shared library files., - Set this property to true to tell CMake generators not to add +(LINK_DEPENDS_SHARED_LIBRARIES, cmProperty::TARGET, + Depend on linked shared library files., + Set this property to true to tell CMake generators to add file-level dependencies on the shared library files linked by this target. - Modification to the shared libraries will not be sufficient to + Modification to the shared libraries will then be sufficient to re-link this target. Logical target-level dependencies will not be affected so the linked shared libraries will still be brought up to date before this target is built. \n This property is initialized by the value of the variable - CMAKE_LINK_DEPENDS_NO_SHARED if it is set when a target is + CMAKE_LINK_DEPENDS_SHARED_LIBRARIES if it is set when a target is created.); cm-DefineProperty @@ -1451,7 +1451,7 @@ void cmTarget::SetMakefile(cmMakefile* mf) this-SetPropertyDefault(OSX_ARCHITECTURES, 0); this-SetPropertyDefault(AUTOMOC, 0); this-SetPropertyDefault(AUTOMOC_MOC_OPTIONS, 0); - this-SetPropertyDefault(LINK_DEPENDS_NO_SHARED, 0); + this-SetPropertyDefault(LINK_DEPENDS_SHARED_LIBRARIES, 0); this-SetPropertyDefault(LINK_INTERFACE_LIBRARIES, 0);
[Cmake-commits] CMake branch, master, updated. v2.8.10.2-749-g3044443
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 303b405c16253eb1de9019e0a2556b20d0cf (commit) via 0ebf332199084fbc0bab789c9a66252094588f1e (commit) from e597ba29288db609d0c3c797848fa7649851b1ee (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=303b405c16253eb1de9019e0a2556b20d0cf commit 303b405c16253eb1de9019e0a2556b20d0cf Merge: e597ba2 0ebf332 Author: Brad King brad.k...@kitware.com AuthorDate: Mon Feb 25 13:11:19 2013 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Mon Feb 25 13:11:19 2013 -0500 Merge topic 'fix-GEH-docs' 0ebf332 Fix GenerateExportHeader documentation #13936 --- Summary of changes: Modules/GenerateExportHeader.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, master, updated. v2.8.10.2-751-g20d0b37
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 20d0b37f4a0d8c08c4bf31440d8e1bc14cdd86b2 (commit) via 1e0891e28ac8d595a7bdab6dc2ac5c3d76061233 (commit) from 303b405c16253eb1de9019e0a2556b20d0cf (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=20d0b37f4a0d8c08c4bf31440d8e1bc14cdd86b2 commit 20d0b37f4a0d8c08c4bf31440d8e1bc14cdd86b2 Merge: 303 1e0891e Author: Brad King brad.k...@kitware.com AuthorDate: Mon Feb 25 13:11:29 2013 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Mon Feb 25 13:11:29 2013 -0500 Merge topic 'generate-export-header-warnings' 1e0891e Removed GenerateExportHeader warnings about old compilers --- Summary of changes: Modules/GenerateExportHeader.cmake |4 1 files changed, 0 insertions(+), 4 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.10.2-753-g05529c7
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 05529c7109de9b0849a5304e63586bf9989e5fcc (commit) via f497dbce93096eb6f0edec982e5f16f9c56520b7 (commit) from 20d0b37f4a0d8c08c4bf31440d8e1bc14cdd86b2 (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=05529c7109de9b0849a5304e63586bf9989e5fcc commit 05529c7109de9b0849a5304e63586bf9989e5fcc Merge: 20d0b37 f497dbc Author: Brad King brad.k...@kitware.com AuthorDate: Mon Feb 25 13:11:34 2013 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Mon Feb 25 13:11:34 2013 -0500 Merge topic 'cmLocalGenerator_RemoveVirtuals' f497dbc cmLocalGenerator: remove virtual where not used --- Summary of changes: Source/cmLocalGenerator.h | 10 +- 1 files changed, 5 insertions(+), 5 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.10.2-755-ge674af9
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 e674af906ac5b18883c1a180434286b1e519de4d (commit) via 11d0c662069e3fd74cb908f714274eeb05f1a14d (commit) from 05529c7109de9b0849a5304e63586bf9989e5fcc (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=e674af906ac5b18883c1a180434286b1e519de4d commit e674af906ac5b18883c1a180434286b1e519de4d Merge: 05529c7 11d0c66 Author: Brad King brad.k...@kitware.com AuthorDate: Mon Feb 25 13:11:44 2013 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Mon Feb 25 13:11:44 2013 -0500 Merge topic 'ExportFileGenerator_GenerateNicerErrorCheckingCode' 11d0c66 export files: rewrite the code for checking required targets --- Summary of changes: Source/cmExportFileGenerator.cxx | 43 ++--- 1 files changed, 30 insertions(+), 13 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.10.2-759-g05e1b3c
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 05e1b3c17d45320410ef8c7e080a33766ca63c2a (commit)
via 55f0148d7b2b5815add052d00b9835dd9c16feae (commit)
via d45eb35350abc72887784802f1e093ad1c4ff5b2 (commit)
via ef8b2fd101e0aa10f82a140822509e303a2b1bc6 (commit)
from e674af906ac5b18883c1a180434286b1e519de4d (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=05e1b3c17d45320410ef8c7e080a33766ca63c2a
commit 05e1b3c17d45320410ef8c7e080a33766ca63c2a
Merge: e674af9 55f0148
Author: Brad King brad.k...@kitware.com
AuthorDate: Mon Feb 25 13:11:51 2013 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Mon Feb 25 13:11:51 2013 -0500
Merge topic 'ExternalData-spaces'
55f0148 ExternalData: Test content link with a space in its name
d45eb35 Tests: Generalize decision for 'make' tool supporting spaces
ef8b2fd Tests: Replace exec_program with execute_process
---
Summary of changes:
Tests/CMakeLists.txt | 44 +++
Tests/Module/ExternalData/CMakeLists.txt |5 ++
.../{Data.dat.md5 = Data Space.dat.md5} |0
Tests/Module/ExternalData/Data1Check.cmake |6 +++
4 files changed, 36 insertions(+), 19 deletions(-)
copy Tests/Module/ExternalData/{Data.dat.md5 = Data Space.dat.md5} (100%)
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.10.2-761-g6e567ca
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 6e567cabea8df6f8fc8c401f4b9bfe2997c4399e (commit) via 79568f95ab920158fdcb857c9b99592ad5300a4e (commit) from 05e1b3c17d45320410ef8c7e080a33766ca63c2a (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=6e567cabea8df6f8fc8c401f4b9bfe2997c4399e commit 6e567cabea8df6f8fc8c401f4b9bfe2997c4399e Merge: 05e1b3c 79568f9 Author: Brad King brad.k...@kitware.com AuthorDate: Mon Feb 25 13:11:55 2013 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Mon Feb 25 13:11:55 2013 -0500 Merge topic 'fix-automoc-linker-language' 79568f9 automoc: Add source file to target early to set the linker language --- Summary of changes: Source/cmGlobalGenerator.cxx | 10 +- Source/cmQtAutomoc.cxx | 27 --- Source/cmQtAutomoc.h |1 + Tests/QtAutomoc/CMakeLists.txt |6 ++ Tests/QtAutomoc/empty.cpp |1 + Tests/QtAutomoc/empty.h|9 + 6 files changed, 42 insertions(+), 12 deletions(-) create mode 100644 Tests/QtAutomoc/empty.cpp create mode 100644 Tests/QtAutomoc/empty.h 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.10.2-765-gb887bca
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 b887bca6ee3651857be663fe1f2e2f2c1ed1ac1e (commit) via 236133e79e2d047810eeba90915e38d9861e2a22 (commit) via 1c0597c25bf69a9c73e3d4f6ab68d16b5e56a271 (commit) via f2ab17d4db86af5695f70b5c49f388319e510472 (commit) from 6e567cabea8df6f8fc8c401f4b9bfe2997c4399e (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=b887bca6ee3651857be663fe1f2e2f2c1ed1ac1e commit b887bca6ee3651857be663fe1f2e2f2c1ed1ac1e Merge: 6e567ca 236133e Author: Brad King brad.k...@kitware.com AuthorDate: Mon Feb 25 13:12:02 2013 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Mon Feb 25 13:12:02 2013 -0500 Merge topic 'try_compile-targets' 236133e Handle targets in the LINK_LIBRARIES of try_compile. 1c0597c Add a new Export generator for IMPORTED targets. f2ab17d Keep track of all targets seen while evaluating a genex. --- Summary of changes: Modules/CheckCSourceCompiles.cmake |7 +- Modules/CheckCSourceRuns.cmake |7 +- Modules/CheckCXXSourceCompiles.cmake |7 +- Modules/CheckCXXSourceRuns.cmake |7 +- Modules/CheckFortranFunctionExists.cmake |7 +- Modules/CheckFunctionExists.cmake |7 +- Modules/CheckLibraryExists.cmake |7 +- Modules/CheckPrototypeDefinition.cmake |7 +- Modules/CheckSymbolExists.cmake|7 +- Modules/CheckTypeSize.cmake|5 +- Modules/CheckVariableExists.cmake |7 +- Source/CMakeLists.txt |2 + Source/cmCoreTryCompile.cxx| 108 +-- Source/cmExportFileGenerator.cxx |3 + Source/cmExportTryCompileFileGenerator.cxx | 114 Source/cmExportTryCompileFileGenerator.h | 55 ++ Source/cmGeneratorExpression.cxx |3 +- Source/cmGeneratorExpression.h |8 +- Source/cmGeneratorExpressionEvaluator.cxx |4 +- Source/cmGeneratorExpressionEvaluator.h|3 +- Source/cmTryCompileCommand.h |8 ++- Tests/ExportImport/Import/CMakeLists.txt |2 + .../ExportImport/Import/try_compile/CMakeLists.txt | 21 bootstrap |1 + 24 files changed, 338 insertions(+), 69 deletions(-) create mode 100644 Source/cmExportTryCompileFileGenerator.cxx create mode 100644 Source/cmExportTryCompileFileGenerator.h create mode 100644 Tests/ExportImport/Import/try_compile/CMakeLists.txt 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.10.2-769-g9d43941
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 9d4394148a5180c46aee249564de44609fbe2594 (commit)
via f17711c546304a5e62a06796e0124c64284bfb9a (commit)
via c1f5780e2d25015ba22dd0a7c8d43c925a62a7f6 (commit)
via 7bb1abe56a05ccc50ff2c56e2df60f305af17ca4 (commit)
from b887bca6ee3651857be663fe1f2e2f2c1ed1ac1e (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=9d4394148a5180c46aee249564de44609fbe2594
commit 9d4394148a5180c46aee249564de44609fbe2594
Merge: b887bca f17711c
Author: Brad King brad.k...@kitware.com
AuthorDate: Mon Feb 25 13:12:05 2013 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Mon Feb 25 13:12:05 2013 -0500
Merge topic 'FPHSA_FOUND_VAR_OPTION'
f17711c FPHSA: Convert FOUND_VAR failure test to RunCMake
c1f5780 FPHSA: improve documentation
7bb1abe FPHSA: Add FOUND_VAR option to specify _FOUND variable name
---
Summary of changes:
Modules/FindPackageHandleStandardArgs.cmake| 67 +---
Tests/FindPackageTest/CMakeLists.txt | 10 +++
Tests/FindPackageTest/FindSomePackage.cmake|6 ++
Tests/FindPackageTest/FindUpperCasePackage.cmake |6 ++
Tests/RunCMake/CMakeLists.txt |1 +
.../BadFoundVar-result.txt}|0
Tests/RunCMake/FPHSA/BadFoundVar-stderr.txt|7 ++
Tests/RunCMake/FPHSA/BadFoundVar.cmake |3 +
Tests/RunCMake/{CMP0004 = FPHSA}/CMakeLists.txt |0
Tests/RunCMake/FPHSA/FindBadFoundVar.cmake |6 ++
Tests/RunCMake/FPHSA/RunCMakeTest.cmake|3 +
11 files changed, 86 insertions(+), 23 deletions(-)
create mode 100644 Tests/FindPackageTest/FindSomePackage.cmake
create mode 100644 Tests/FindPackageTest/FindUpperCasePackage.cmake
copy Tests/RunCMake/{CMP0004/CMP0004-NEW-result.txt =
FPHSA/BadFoundVar-result.txt} (100%)
create mode 100644 Tests/RunCMake/FPHSA/BadFoundVar-stderr.txt
create mode 100644 Tests/RunCMake/FPHSA/BadFoundVar.cmake
copy Tests/RunCMake/{CMP0004 = FPHSA}/CMakeLists.txt (100%)
create mode 100644 Tests/RunCMake/FPHSA/FindBadFoundVar.cmake
create mode 100644 Tests/RunCMake/FPHSA/RunCMakeTest.cmake
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.10.2-771-g990c440
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 990c440ddd599d0bf4cad2cb7ac1688a42dca6d9 (commit) via 9f941816348493522f8ddf60e633c1e82d9002cb (commit) from 9d4394148a5180c46aee249564de44609fbe2594 (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=990c440ddd599d0bf4cad2cb7ac1688a42dca6d9 commit 990c440ddd599d0bf4cad2cb7ac1688a42dca6d9 Merge: 9d43941 9f94181 Author: Brad King brad.k...@kitware.com AuthorDate: Mon Feb 25 13:12:09 2013 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Mon Feb 25 13:12:09 2013 -0500 Merge topic 'ide-compiler-vars-Fortran' 9f94181 VS: Restore CMAKE_GENERATOR_FC variable --- Summary of changes: Source/cmGlobalVisualStudio7Generator.cxx |1 + 1 files changed, 1 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, master, updated. v2.8.10.2-778-g57072c1
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 57072c12d2e9302cefa66c96e55a595de085a161 (commit) via 8dfdf1c734af19a1e49efa4568e5e1f8fc7cb2f2 (commit) via 98a672528d7e6c192fc75abb10161121c8b28073 (commit) via 7e707444be6f7344888102ce4f88db48a31cab63 (commit) via d1a2729b1af86a0a3abfb21df18ed85bcfaa59c6 (commit) via e72eaadc42be80ef8273addfc19a6dd13b5feb90 (commit) via ec2c67bcf3aada9b601d5dca52b31a4fb6104240 (commit) from 990c440ddd599d0bf4cad2cb7ac1688a42dca6d9 (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=57072c12d2e9302cefa66c96e55a595de085a161 commit 57072c12d2e9302cefa66c96e55a595de085a161 Merge: 990c440 8dfdf1c Author: Brad King brad.k...@kitware.com AuthorDate: Mon Feb 25 13:12:12 2013 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Mon Feb 25 13:12:12 2013 -0500 Merge topic 'interface-property-external-read' 8dfdf1c Fix the tests for evaluating includes and defines. 98a6725 Fix constness of accessors. 7e70744 Expand includes and defines transitively in 'external' genexes. d1a2729 Fix DAG checker finding cycling dependencies. e72eaad Workaround broken code where a target has itself in its link iface. ec2c67b Strip stray semicolons when evaluating generator expressions. --- Summary of changes: Source/cmGeneratorExpression.cxx|7 +- Source/cmGeneratorExpression.h |1 + Source/cmGeneratorExpressionDAGChecker.cxx | 10 ++-- Source/cmGeneratorExpressionDAGChecker.h|4 +- Source/cmGeneratorExpressionEvaluator.cxx | 97 +-- Tests/GeneratorExpression/CMakeLists.txt| 31 - Tests/GeneratorExpression/check-part2.cmake |8 ++ Tests/GeneratorExpression/empty.cpp |2 + 8 files changed, 113 insertions(+), 47 deletions(-) create mode 100644 Tests/GeneratorExpression/empty.cpp 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.10.2-780-gb74c35f
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 b74c35f57ef686c424d6dfbbc40c60cb05e6245b (commit) via 42ebb1886f7500c2f7a34fee99e2e9fa749f5a93 (commit) from 57072c12d2e9302cefa66c96e55a595de085a161 (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=b74c35f57ef686c424d6dfbbc40c60cb05e6245b commit b74c35f57ef686c424d6dfbbc40c60cb05e6245b Merge: 57072c1 42ebb18 Author: Brad King brad.k...@kitware.com AuthorDate: Mon Feb 25 13:12:16 2013 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Mon Feb 25 13:12:16 2013 -0500 Merge topic 'memoize-link-iface-includes-defines' 42ebb18 Memoize includes and defines from interface libraries. --- Summary of changes: Source/cmTarget.cxx | 132 ++- 1 files changed, 88 insertions(+), 44 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.10.2-2341-g8e2e365
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 8e2e36507dd324a252c27f77825be5dda2bbc528 (commit) via b74c35f57ef686c424d6dfbbc40c60cb05e6245b (commit) via 57072c12d2e9302cefa66c96e55a595de085a161 (commit) via 990c440ddd599d0bf4cad2cb7ac1688a42dca6d9 (commit) via 9d4394148a5180c46aee249564de44609fbe2594 (commit) via b887bca6ee3651857be663fe1f2e2f2c1ed1ac1e (commit) via 6e567cabea8df6f8fc8c401f4b9bfe2997c4399e (commit) via 05e1b3c17d45320410ef8c7e080a33766ca63c2a (commit) via e674af906ac5b18883c1a180434286b1e519de4d (commit) via 05529c7109de9b0849a5304e63586bf9989e5fcc (commit) via 20d0b37f4a0d8c08c4bf31440d8e1bc14cdd86b2 (commit) via 303b405c16253eb1de9019e0a2556b20d0cf (commit) from 64ca9549f1c8d0a357c99bcb3867298f52abc25c (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=8e2e36507dd324a252c27f77825be5dda2bbc528 commit 8e2e36507dd324a252c27f77825be5dda2bbc528 Merge: 64ca954 b74c35f Author: Brad King brad.k...@kitware.com AuthorDate: Mon Feb 25 13:13:05 2013 -0500 Commit: Brad King brad.k...@kitware.com CommitDate: Mon Feb 25 13:13:05 2013 -0500 Merge branch 'master' into next --- 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
