[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
[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: 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
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
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=176688935&build=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 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?
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. -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 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
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:35 PM, Alexander Neundorf wrote: > 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. So unset == OLD (internally WARN == OLD)? If no warning will ever appear we do not need a policy at all. We can simply define the behavior. With either old or new default behavior though we still need an explicit option as a property. Perhaps we should say that if (CMAKE_)LINK_DEPENDS_SHARED_LIBRARIES is set to true or false then it is honored. If not then the current minimum required version of CMake determines the value. -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 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/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 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 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? -- 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 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=178646760&build=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?
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=178646760&build=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
[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
Fo
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
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
[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
