[cmake-developers] [CMake 0013691]: FindGettext.cmake does not set GETTEXT_FOUND in PARENT_SCOPE
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=13691
==
Reported By:Herbert Thielen
Assigned To:
==
Project:CMake
Issue ID: 13691
Category: Modules
Reproducibility:always
Severity: major
Priority: normal
Status: new
==
Date Submitted: 2012-11-16 15:21 EST
Last Modified: 2012-11-16 15:21 EST
==
Summary:FindGettext.cmake does not set GETTEXT_FOUND in
PARENT_SCOPE
Description:
When using "find_package(Gettext)", the variable GETTEXT_FOUND is not set even
if the gettext tools are installed and can be found.
Steps to Reproduce:
Use a CMakeLists.txt with e.g.
= snip =
find_package(Gettext)
if (GETTEXT_FOUND)
message (WARNING "All is fine, gettext found.")
else (GETTEXT_FOUND)
message (WARNING "Did not find gettext.")
endif (GETTEXT_FOUND)
= snap =
and run 'cmake --trace path/to/project/dir'. The FindGettext.cmake modules tells
you when msgmerge etc. are found, but even if the tools are found, the output of
the lines above will be "Did not find gettext" because GETTEXT_FOUND is not set
in the scope of CMakeLists.txt.
Probably this is not related to Windows, but I didn't try this version on other
platforms.
Additional Information:
The following patch helped:
$ diff -u FindGettext.cmake~ FindGettext.cmake
--- FindGettext.cmake~ 2012-11-06 20:45:28.0 +0100
+++ FindGettext.cmake 2012-11-16 17:57:47.139133300 +0100
@@ -210,4 +210,4 @@
endfunction()
-set(GETTEXT_FOUND ${Gettext_FOUND})
+set(GETTEXT_FOUND ${Gettext_FOUND} PARENT_SCOPE)
==
Issue History
Date ModifiedUsername FieldChange
==
2012-11-16 15:21 Herbert ThielenNew 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 0013694]: CMAKE_OSX_SYSROOT isn't quoted, breaking builds when the SDK path contains a space
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13694 == Reported By:Jevin Sweval Assigned To: == Project:CMake Issue ID: 13694 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2012-11-16 19:03 EST Last Modified: 2012-11-16 19:03 EST == Summary:CMAKE_OSX_SYSROOT isn't quoted, breaking builds when the SDK path contains a space Description: CMAKE_OSX_SYSROOT is eventually consumed by cmLocalGenerator::AddArchitectureFlags which will generate something like '-isysroot $SYSROOT' I keep multiple versions of Xcode around in /Applications/Xcode $version.app/ so the sysroot path will contain a space. The fix (for my case) is to wrap the sysroot path in quotes like so: '-isysroot "$SYSROOT"' I can't imagine that this would break anything, and can only help. I have applied a patch here https://github.com/jevinskie/cmake/commits/master Steps to Reproduce: 1) Rename your Xcode.app folder such that it contains a space. 2) Try to build something 3) The build fails because the sysroot path was not properly quoted. == Issue History Date ModifiedUsername FieldChange == 2012-11-16 19:03 Jevin Sweval 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 0013699]: Errors are not cleared when rebuilding a CMake-generated Eclipse CDT project
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=13699
==
Reported By:vitaut
Assigned To:
==
Project:CMake
Issue ID: 13699
Category: CMake
Reproducibility:always
Severity: major
Priority: normal
Status: new
==
Date Submitted: 2012-11-17 18:42 EST
Last Modified: 2012-11-17 18:42 EST
==
Summary:Errors are not cleared when rebuilding a
CMake-generated Eclipse CDT project
Description:
Some errors from previous builds are not cleared when rebuilding a
CMake-generated Eclipse CDT project. Most of the errors are cleared but the
following three persist in the Problems view:
make[1]: *** [CMakeFiles/test.dir/all] Error 2 C/C++
Problem
make: *** [all] Error 2 C/C++ Problem
make[2]: *** [CMakeFiles/test.dir/test.cc.o] Error 1
C/C++ Problem
These errors persist even if the project builds successfully which can be
checked by looking at the Console output.
I am using Eclipse CDT version 8.1.0.
Steps to Reproduce:
1. Create a simple C/C++ CMake project with a syntax error in the source code,
for example,
CMakeFiles.txt:
cmake_minimum_required(VERSION 2.6)
project(TEST)
add_executable(test test.cc)
test.cc:
int main() {
return 0 // missing semicolon
}
2. Generate Eclipse CDT project:
cmake -G "Eclipse CDT4 - Unix Makefiles"
3. Open the project in Eclipse and build it. The Problems view will contain the
following errors:
make[1]: *** [CMakeFiles/test.dir/all] Error 2 C/C++
Problem
make: *** [all] Error 2 C/C++ Problem
make[2]: *** [CMakeFiles/test.dir/test.cc.o] Error 1
C/C++ Problem
expected ‘;’ before ‘}’ token test.cc /TEST@test line 3 C/C++ Problem
4. Fix the error (add a semicolon after 0 in the example above), save the file
and build the project again. The Problems view will contain the following
errors:
make[1]: *** [CMakeFiles/test.dir/all] Error 2 C/C++
Problem
make: *** [all] Error 2 C/C++ Problem
make[2]: *** [CMakeFiles/test.dir/test.cc.o] Error 1
C/C++ Problem
Additional Information:
Changing the error parser from "CDT GNU Make Error Parser 6.0 (Deprecated)" to
"CDT GNU Make Error Parser 7.0" solves the problem but only until the project
file is generated again. The blog post http://www.jazzbee.com/blog/?p=76
suggests changing "org.eclipse.cdt.core.MakeErrorParser" to
"org.eclipse.cdt.core.GmakeErrorParser" in cmExtraEclipseCDT4Generator.cxx.
==
Issue History
Date ModifiedUsername FieldChange
==
2012-11-17 18:42 vitaut 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 0013700]: CPack fails from fakeroot
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13700 == Reported By:Konstantin Cherenkov Assigned To: == Project:CMake Issue ID: 13700 Category: CPack Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2012-11-18 07:25 EST Last Modified: 2012-11-18 07:25 EST == Summary:CPack fails from fakeroot Description: CPackDeb fails if deb files are created from fakeroot CPack: Create package CPack Error: Problem running tar command: /usr/bin/fakeroot "/usr/bin/cmake" -E tar cfz data.tar.gz ./usr Please check [...]/build/_CPack_Packages/Linux/DEB/Deb.log for errors CPack Error: Problem compressing the directory Deb.log contains this message: fakeroot: nested operation not yet supported Steps to Reproduce: fakeroot mkdir build cd build cmake .. cpack == Issue History Date ModifiedUsername FieldChange == 2012-11-18 07:25 Konstantin CherenkovNew 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 0013702]: CMake crashes when reconfiguring build
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13702 == Reported By:Nick Hutchinson Assigned To: == Project:CMake Issue ID: 13702 Category: CMake Reproducibility:always Severity: crash Priority: normal Status: new == Date Submitted: 2012-11-19 18:07 NZDT Last Modified: 2012-11-19 18:07 NZDT == Summary:CMake crashes when reconfiguring build Description: Attached is a reduced test case that reliably crashes CMake. Steps to Reproduce: 1. Execute the following commands: ~ mkdir build && cd build cmake ../path/to/source/folder -DCMAKE_C_COMPILER=cc -DFOOBAR=0 ~ CMake should abort the configure with the message: "CMake Error at CMakeLists.txt:8 (message): FOOBAR was not set" 2. Execute the following command: cmake ../path/to/source/folder -DCMAKE_C_COMPILER=cc -DFOOBAR=1 Expected behaviour: CMake reconfigures the project. Actual behaviour: CMake displays the following message, then crashes: ~~ -- Configuring done You have changed variables that require your cache to be deleted. Configure will be re-run and you may have to reset some variables. The following variables have changed: CMAKE_C_COMPILER= cc CMake Error at CMakeLists.txt:3 (add_library): add_library cannot create imported target "testlib" because another target with the same name already exists. [1]20462 segmentation fault (core dumped) cmake ../ -DCMAKE_C_COMPILER=cc -DFOOBAR=1 Additional Information: Core dump is included in the attachment. == Issue History Date ModifiedUsername FieldChange == 2012-11-19 18:07 Nick HutchinsonNew Issue 2012-11-19 18:07 Nick HutchinsonFile Added: CMake Crash.zip == -- 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 0013703]: Paths with | character create invalid Makefiles
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=13703
==
Reported By:Johannes Wienke
Assigned To:
==
Project:CMake
Issue ID: 13703
Category: CMake
Reproducibility:always
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2012-11-19 05:20 EST
Last Modified: 2012-11-19 05:20 EST
==
Summary:Paths with | character create invalid Makefiles
Description:
If you are using CMake to generate Makefiles on Linux, the | is a valid
character in path names. However, generated Makefiles (e.g.
CMakeFiles/*/{depend,build,*}.make) contain invalid rules in these cases:
foo: bar|baz
The | needs to be escaped in this case using a backslash.
==
Issue History
Date ModifiedUsername FieldChange
==
2012-11-19 05:20 Johannes WienkeNew 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 0013704]: Module libmongo-client FindLibMongoClient.cmake
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13704 == Reported By:Pander Musubi Assigned To: == Project:CMake Issue ID: 13704 Category: Modules Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2012-11-19 09:59 EST Last Modified: 2012-11-19 09:59 EST == Summary:Module libmongo-client FindLibMongoClient.cmake Description: Please offer a module for the C library https://github.com/algernon/libmongo-client named FindLibMongoClient.cmake Steps to Reproduce: For POSIX environments, the following applies $ pkg-config --cflags --libs libmongo-client -I/usr/local/include/mongo-client -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -L/usr/local/lib -lmongo-client Additional Information: The following packages are relevant for Ubuntu: $ apt-cache search libmongo-client libmongo-client-dev - Development files for the alternate C driver for MongoDB libmongo-client-doc - Documentation for the alternate C driver for MongoDB libmongo-client0 - Alternate C driver for the MongoDB document-oriented datastore libmongo-client0-dbg - Alternate C driver for MongoDB (debugging symbols) == Issue History Date ModifiedUsername FieldChange == 2012-11-19 09:59 Pander Musubi 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 0013718]: CMake picks up ansidecl.h during configure
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13718 == Reported By:Amit Kulkarni Assigned To: == Project:CMake Issue ID: 13718 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2012-11-20 09:15 EST Last Modified: 2012-11-20 09:15 EST == Summary:CMake picks up ansidecl.h during configure Description: > Looks like opencv picks up ansidecl.h during configure and later > tries to use it. However, since there is no explicit dependency, > the file can go away anytime and if it does, the build fails. > > (ansidecl.h is around if devel/gdb happens to be installed.) Refer to http://marc.info/?l=openbsd-ports&m=135336077026128&w=2 A casual google search turns up http://git.yoctoproject.org/cgit.cgi/poky/plain/meta/recipes-core/libxml/libxml2/ansidecl.patch http://www.paraview.org/pipermail/paraview/2008-March/007473.html Can this issue be fixed please, instead of various patches to be made to remove ansidecl.h in many other projects? Thanks == Issue History Date ModifiedUsername FieldChange == 2012-11-20 09:15 Amit Kulkarni 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 0013048]: CMake 2.8.7 Nightly fails to link correctly in XCode 4.3
The following issue is now in status NEW (again)
==
http://public.kitware.com/Bug/view.php?id=13048
==
Reported By:Karthik Kumar Viswanathan
Assigned To:
==
Project:CMake
Issue ID: 13048
Category: CMake
Reproducibility:always
Severity: block
Priority: immediate
Status: new
==
Date Submitted: 2012-03-17 09:16 EDT
Last Modified: 2012-11-21 15:45 EST
==
Summary:CMake 2.8.7 Nightly fails to link correctly in XCode
4.3
Description:
Hi,
I generated the CMake Xcode 4.3 project...
Karthiks-MacBook-Air:allegro5engine karthik$ cmake -version
cmake version 2.8.7.20120313-ga2183
I am creating a library, then linking to it.
I use:
add_library(engine ${EngineFiles})
and it emits to Build/ Src/Debug-iphone/engine.a
When I link, I use:
target_link_libraries(main engine ${AllLibraries} ${ExtraLibraries}
${CMAKE_EXTRA_LINKER_FLAGS})
but it tries to link against:
Build/ Src/Debug/engine.a
This CMake used to work perfectly in Xcode 4.2 It's breaking with 4.3.1.
==
Relationships ID Summary
--
related to 0012621 Compatibility with Xcode 4.3
related to 0012640 set(CMAKE_XCODE_EFFECTIVE_PLATFORMS "-i...
related to 0013100 0013048 CMake 2.8.7 Nightly fails to l...
==
--
(0028924) Karthik Kumar Viswanathan (reporter) - 2012-03-24 01:26
http://public.kitware.com/Bug/view.php?id=13048#c28924
--
Debug-iphonesimulator...
Has there been any updates on this issue yet?
--
(0029067) David Cole (manager) - 2012-04-03 12:09
http://public.kitware.com/Bug/view.php?id=13048#c29067
--
Are you setting the CMake variable "CMAKE_XCODE_EFFECTIVE_PLATFORMS"?
See also http://public.kitware.com/Bug/view.php?id=12640
And the example usage of it in the iOSNavApp test in the CMake source tree:
http://public.kitware.com/gitweb?p=cmake.git;a=blob;f=Tests/iOSNavApp/CMakeLists.txt;h=12c3ada35799563a13f567b074d7d3eb936191df;hb=9ad3fa7e853d933e70af0a75d711ffa1d926b507
--
(0031673) David Cole (manager) - 2012-11-21 15:44
http://public.kitware.com/Bug/view.php?id=13048#c31673
--
Un-assigning bugs that are not on the active roadmap, which no developers are
actively working on for the CMake 2.8.11 release.
If one gets put back on the roadmap, re-assign it appropriately at that time.
--
(0031674) David Cole (manager) - 2012-11-21 15:45
http://public.kitware.com/Bug/view.php?id=13048#c31674
--
Re-setting status back to "new" for bugs that are "assigned" but not assigned to
a specific developer. When/if these bugs go back on the roadmap for a specific
version, assignment to an appropriate developer should take place then...
Issue History
Date ModifiedUsername FieldChange
==
2012-03-17 09:16 Karthik Kumar ViswanathanNew Issue
2012-03-17 09:24 Karthik Kumar ViswanathanNote Added: 0028924
2012-03-19 08:37 Brad King Relationship added related to 0012621
2012-03-19 08:53 Brad King Assigned To => David Cole
2012-03-19 08:53 Brad King Status new => assigned
2012-03-24 01:26 Karthik Kumar ViswanathanNote Edited: 0028924
2012-04-03 12:03 David Cole Relationship added related to 0013100
2012-04-03 12:09 David Cole Note Added: 0029067
2012-04-03 12:10 David Cole Relationship added related to 0012640
2012-11-21 15:44 David Cole Note Added: 0031673
2012-11-21 15:45 David Cole Assigned To David Cole =>
2012-11-21 15:45 David Cole Note Added: 0031
[cmake-developers] [CMake 0013727]: MSBuild 4.0 builds two configs iff inside subfolder and started from commandline
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13727 == Reported By:dmytro_ovdiienko Assigned To: == Project:CMake Issue ID: 13727 Category: CMake Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 2012-11-22 02:15 EST Last Modified: 2012-11-22 02:15 EST == Summary:MSBuild 4.0 builds two configs iff inside subfolder and started from commandline Description: I believe it is MSBuild issue so I've reported this issue to Microsoft. Could you please check additionally my report on your side. https://connect.microsoft.com/VisualStudio/feedback/details/771885/msbuild-4-0-builds-two-configs-iff-inside-subfolder-and-started-from-commandline#details Thanks. == Issue History Date ModifiedUsername FieldChange == 2012-11-22 02:15 dmytro_ovdiienkoNew 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 0013728]: Ninja file generated by CMake is invalid
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13728 == Reported By:JussiP Assigned To: == Project:CMake Issue ID: 13728 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2012-11-23 04:13 EST Last Modified: 2012-11-23 04:13 EST == Summary:Ninja file generated by CMake is invalid Description: When generating a Ninja build system for Scribus, the resulting build.ninja is invalid. The following error is printed when running Ninja: ninja: error: build.ninja:6397: bad $-escape (literal $ must be written as $$) FLAGS = $(CMAKE_CXX_FLAGS) -fPIC -O2 -Wall -fPIC -Iscribus/third_party... ^ near here Steps to Reproduce: Check out Scribus from git: git clone git://git.scribus.net/scribus.git Run CMake with the ninja backend. Run Ninja. Additional Information: The error is caused by the parentheses surrounding the word CMAKE_CXX_FLAGS. Manually editing the Ninja file and removing the parentheses in all locations they appear fixes the issue and running Ninja will work correctly. == Issue History Date ModifiedUsername FieldChange == 2012-11-23 04:13 JussiP 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 0013730]: Shortcut for generator names
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13730 == Reported By:Michael Broutin Assigned To: == Project:CMake Issue ID: 13730 Category: CMake Reproducibility:always Severity: feature Priority: normal Status: new == Date Submitted: 2012-11-23 14:25 EST Last Modified: 2012-11-23 14:25 EST == Summary:Shortcut for generator names Description: Hi, Whenever I want to call cmake from command line, it's a bit hard to remember the generator name exactly, with the right case. Would it be possible to add an alias for it? For example, "Visual Studio 8 2005" <-> MSVC8 "Eclipse CDT4 - MinGW Makefiles" <-> Eclipse_mingw ... == Issue History Date ModifiedUsername FieldChange == 2012-11-23 14:25 Michael BroutinNew 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 0013732]: wxWidgets finder may not find compiled WXRC.
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=13732
==
Reported By:Vladislav Turbanov
Assigned To:
==
Project:CMake
Issue ID: 13732
Category: Modules
Reproducibility:always
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2012-11-23 18:08 EST
Last Modified: 2012-11-23 18:08 EST
==
Summary:wxWidgets finder may not find compiled WXRC.
Description:
wxWidgets finder (FindwxWidgets.cmake) may not find compiled WXRC program if it
is located somewhere else than "${wxWidgets_ROOT_DIR}/utils/wxrc/vc_msw" (eg.
"${wxWidgets_ROOT_DIR}/utils/wxrc/vc_mswud").
This can be fixed with the following code replacement at line 843:
# Resource file compiler.
find_program(wxWidgets_wxrc_EXECUTABLE wxrc
PATHS ${wxWidgets_ROOT_DIR}/utils/wxrc/vc_msw
${wxWidgets_ROOT_DIR}/utils/wxrc/vc_msw*
)
Thank you.
==
Issue History
Date ModifiedUsername FieldChange
==
2012-11-23 18:08 Vladislav TurbanovNew 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 0013738]: FindBullet.cmake outdated
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13738 == Reported By:Alan Witkowski Assigned To: == Project:CMake Issue ID: 13738 Category: Modules Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2012-11-24 13:47 EST Last Modified: 2012-11-24 13:47 EST == Summary:FindBullet.cmake outdated Description: Bullet for windows has changed since FindBullet.cmake was created. Attached is the patch that adds a better lib path. I've also submitted a patch to Bullet to help try to standardize the library output path for windows. == Issue History Date ModifiedUsername FieldChange == 2012-11-24 13:47 Alan Witkowski New Issue 2012-11-24 13:47 Alan Witkowski File Added: bullet.patch == -- 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 0013742]: find_path() ought to pick up architecture-specific headers on multiarch systems
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=13742
==
Reported By:Nick Hutchinson
Assigned To:
==
Project:CMake
Issue ID: 13742
Category: CMake
Reproducibility:always
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2012-11-27 09:33 NZDT
Last Modified: 2012-11-27 09:33 NZDT
==
Summary:find_path() ought to pick up architecture-specific
headers on multiarch systems
Description:
On my Ubuntu 12.10 box, headers for libffi are located at
/usr/include/i386-linux-gnu/. This means that a simple find_path(FFI_INCLUDE_DIR
NAMES ffi.h) won't find the header, as /usr/include/i386-linux-gnu/ is not
searched by default. It ought to be; when compiling with either GCC or Clang,
this directory is in the default #include search list.
Steps to Reproduce:
1. On a multiarch system, e.g. Ubuntu, attempt to use find_path() to find an
architecture-specific header.
Expected behaviour:
It "just works": CMake searches the appropriate include directory, without
requiring the user to add any supplementary search paths, suffixes, and so on.
This seems to be the behaviour with find_library(), for example.
Actual behaviour:
CMake fails to find the header.
Additional Information:
I'm not sure how robust this is, but I'm currently working around this issue by
using the following:
find_file(FFI_INCLUDE_DIR NAMES ffi.h PATH_SUFFIXES
${CMAKE_LIBRARY_ARCHITECTURE})
==
Issue History
Date ModifiedUsername FieldChange
==
2012-11-27 09:33 Nick HutchinsonNew 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 0013743]: Ninja does not work with CTest launchers
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13743 == Reported By:Mathias Gaunard Assigned To: == Project:CMake Issue ID: 13743 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2012-11-26 19:00 EST Last Modified: 2012-11-26 19:00 EST == Summary:Ninja does not work with CTest launchers Description: When using CMake with CTEST_USE_LAUNCHERS, the RULE_LAUNCHER_COMPILE property is set to a special command used for better integration with the CTest system. While it works correctly with Ninja on most platforms (you'll need to change a if generator is make to is generator is make or ninja in CTest.cmake), it doesn't work with Visual Studio because of the cldeps stuff. Indeed, what Ninja generates is the following: "C:/Program Files (x86)/CMake 2.8/bin/cmcldeps.exe" CXX $in "$DEP_FILE" $out "Note: including file: " "C:/Program Files (x86)/Microsoft Visual Studio 10.0/VC/bin/cl.exe" "C:/Program Files (x86)/CMake 2.8/bin/ctest.exe" --launch --target-name project --build-dir C:\Users\mgaunard\build\project\src --output $out --source $in --language CXX -- C:\PROGRA~2\MICROS~2.0\VC\bin\cl.exe /nologo $FLAGS $DEFINES /TP /Fo$out /Fd$TARGET_PDB -c $in This is obviously incorrect, it should be "C:/Program Files (x86)/CMake 2.8/bin/ctest.exe" --launch --target-name project --build-dir C:\Users\mgaunard\build\project\src --output $out --source $in --language CXX -- "C:/Program Files (x86)/CMake 2.8/bin/cmcldeps.exe" CXX $in "$DEP_FILE" $out "Note: including file: " "C:/Program Files (x86)/Microsoft Visual Studio 10.0/VC/bin/cl.exe" C:\PROGRA~2\MICROS~2.0\VC\bin\cl.exe /nologo $FLAGS $DEFINES /TP /Fo$out /Fd$TARGET_PDB -c $in == Issue History Date ModifiedUsername FieldChange == 2012-11-26 19:00 Mathias GaunardNew 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 0013745]: CHECK_C_COMPILER_FLAG doesn't work with -march=xlr option with a MIPS gcc cross compiler
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=13745 == Reported By:Mahendra Ladhe Assigned To: == Project:CMake Issue ID: 13745 Category: CMake Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 2012-11-27 04:25 EST Last Modified: 2012-11-27 04:25 EST == Summary:CHECK_C_COMPILER_FLAG doesn't work with -march=xlr option with a MIPS gcc cross compiler Description: I 've a CMakeLists.txt file as below. CHECK_C_COMPILER_FLAG (-march=xlr FLAG_xlr) CHECK_C_COMPILER_FLAG (-march=xlp FLAG_xlp) I'm using a gcc MIPS cross compiler. Using this cross compiler I'm able to compile a simple C program using both -march=xlr and -march=xlp compiler options. The size of a.out differs with these two options (just to show that -march option is acted upon by the compiler) When I invoke cmake on above CMakeLists.txt file, I get the following. -- Performing Test FLAG_xlr -- Performing Test FLAG_xlr - Failed -- Performing Test FLAG_xlp -- Performing Test FLAG_xlp - Success It says Test FLAG_xlr failed, but it shouldn't fail since the cross compiler does support -march=xlr option. Steps to Reproduce: As described above. I cannot provide the gcc cross compiler used since it's not publicly available. == Issue History Date ModifiedUsername FieldChange == 2012-11-27 04:25 Mahendra Ladhe 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 0013746]: FindOpenGL module reports OpenGL_FOUND even when no OPENGL_INCLUDE_DIR is set
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13746 == Reported By:hades Assigned To: == Project:CMake Issue ID: 13746 Category: Modules Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2012-11-27 06:32 EST Last Modified: 2012-11-27 06:32 EST == Summary:FindOpenGL module reports OpenGL_FOUND even when no OPENGL_INCLUDE_DIR is set Description: When cmake can find a libGL.so, but no gl.h, it still sets OPENGL_FOUND to TRUE, despite that OPENGL_INCLUDE_DIR is set to NOTFOUND and therefore completely unusable. I believe line 153 should be changed from: FIND_PACKAGE_HANDLE_STANDARD_ARGS(OpenGL DEFAULT_MSG OPENGL_gl_LIBRARY) to: FIND_PACKAGE_HANDLE_STANDARD_ARGS(OpenGL DEFAULT_MSG OPENGL_gl_LIBRARY OPENGL_INCLUDE_DIR) == Issue History Date ModifiedUsername FieldChange == 2012-11-27 06:32 hades 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 0013747]: export(PACKAGE) prioritizes build-tree over install-tree
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=13747
==
Reported By:Stephen Kelly
Assigned To:
==
Project:CMake
Issue ID: 13747
Category: CMake
Reproducibility:have not tried
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2012-11-27 09:19 EST
Last Modified: 2012-11-27 09:19 EST
==
Summary:export(PACKAGE) prioritizes build-tree over
install-tree
Description:
The package BoostAny depends on BoostCore. Both packages create a Config file in
the build tree and install one in the install tree. There is a export(PACKAGE)
call for each of them.
If I set CMAKE_PREFIX_PATH to the install location of BoostAny, I can use
find_package(BoostAny) and it will find it in the install location.
However, as BoostAnyConfig.cmake has a find_package(BoostCore) inside it, the
BoostCore package is found in the build-tree instead of the install tree. As the
BoostAny and BoostCore packages are both installed and beside each other in the
filesystem, this is an unintuitive result.
The find_package documentation does not state the order of prefixes searched for
packages. It seems to me that the export(PACKAGE) prefixes should be a fallback
after trying in the CMAKE_PREFIX_PATH, but I don't know if that can be changed
now.
It would be possible to use find_package( ... PATHS ${CMAKE_CURRENT_LIST_DIR} )
in BoostAnyConfig.cmake, but that would require that all Boost packages be
installed to the same prefix. It may be that they want to be able to install
different libraries to different prefixes (I don't know, but I think CMake
should allow it).
==
Issue History
Date ModifiedUsername FieldChange
==
2012-11-27 09:19 Stephen Kelly 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 0013749]: Cannot target Windows 8 RT from CMake without workarounds.
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=13749
==
Reported By:jujjyl
Assigned To:
==
Project:CMake
Issue ID: 13749
Category: CMake
Reproducibility:always
Severity: block
Priority: normal
Status: new
==
Date Submitted: 2012-11-27 18:49 EST
Last Modified: 2012-11-27 18:49 EST
==
Summary:Cannot target Windows 8 RT from CMake without
workarounds.
Description:
I tried to make CMake generate .vcxproj files that would build into Windows 8 RT
application bundles. Not ARM, just on standard Win 8 RT, e.g. for Win 8 Store.
I use the -G "Visual Studio 11" generator.
The only support I found for this is to do
set_target_properties(project_name PROPERTIES VS_WINRT_EXTENSIONS TRUE)
add_definitions(-ZW)
(this was from
http://stackoverflow.com/questions/13228829/is-it-possible-to-create-winrt-project-with-cmake
, I do not need the xaml files, so only steps 1 & 2 applied for me)
These step were not enough. This is what I found missing:
1. The .vcxproj should have an element
"true" for the VC project
that is to be deployed into an Win8 RT app. This is missing in the generated
.vcxproj.
As a workaround, I use a sed script to add that line in an extra batch script
that is run after cmake finished. The line reads:
sed -r -i "s##
true#g"
ProjectFileGeneratedByCMake.vcxproj
2. When targeting Win8 RT, it is required that the project contains an app
manifest ('Package.appxmanifest'), and a required set of logo images 'Logo.png',
'SmallLogo.png', 'SplashScreen.png' and 'StoreLogo.png'. Also (not 100% sure if
is required for development) there is a signing key file.
I added these files manually to my source code folder. They need to be added
into the VC project, so that VC bundles the image files to the build, and knows
which manifest file to read. I tried to do this with the same way I add .cpp and
.h files:
file(GLOB sourceFiles *.cpp)
set(sourceFiles ${sourceFiles} ${Win8RTBuildRoot}/Assets/SmallLogo.png)
set(sourceFiles ${sourceFiles} ${Win8RTBuildRoot}/Assets/StoreLogo.png)
set(sourceFiles ${sourceFiles} ${Win8RTBuildRoot}/Assets/SplashScreen.png)
set(sourceFiles ${sourceFiles} ${Win8RTBuildRoot}/Assets/Logo.png)
set(sourceFiles ${sourceFiles}
${Win8RTBuildRoot}/gfxapi_application_TemporaryKey.pfx)
set(sourceFiles ${sourceFiles} ${Win8RTBuildRoot}/Package.appxmanifest)
add_executable(projectName WIN32 ${sourceFiles})
This works in the sense that the files appear in the project. But they are
defined wrong in .vcxproj, and VC gets confused and will say the files are
missing even though they are there. The .vcxproj file will read
If the files are added manually, they will instead read
As a workaround, I added two sed scripts that replace 'None' with 'Image' for
.png files and with 'AppxManifest' for .appxmanifest files. Perhaps I did not
know of the proper way to add these to VC project, or the support is missing?
Perhaps CMake should always add image files as Image and .appxmanifest files as
AppxManifest, as there is probably no reason to have None for these. (what other
types might there be for which VC adds some other element than None, but cmake
does not?)
These workaround sed scripts read:
sed -r -i "s/None Include=\"(.*)\.png\"/Image Include=\"\1\.png\"/g"
ProjectFileGeneratedByCMake.vcxproj
sed -r -i "s/None Include=\"(.*)\.appxmanifest\"/AppxManifest
Include=\"\1\.appxmanifest\"/g" ProjectFileGeneratedByCMake.vcxproj
With these three sed workarounds, the solution and project files can now be
'Deploy'ed as Win8 RT apps and run in Metro UI.
Additional Information:
Suggestions:
1. Add a new magic string WIN8RT to be recognized by add_executable, like
add_executable(projectName WIN8RT ${sourceFiles})
This would be used instead of the magic string 'WIN32' to signal that the
executable is to be a Win8 RT app.
When WIN8RT is specified, either
a) omitting a .appxmanifest file from ${sourceFiles} is cmake generation error,
or
b) if custom .appxmanifest is omitted, a default one is automatically generated
and used.
This is because when building as a win8 app, the build will fail if there is no
manifest. Also, the build will fail if the required logo images are not present,
so their addition should somehow be enforced as well.
2. Don't add image and appxmanifest items with the XML element to the
vcxproj, but add them with and .
If I did not find something and there is already an abstraction/mechanism to
[cmake-developers] [CMake 0013750]: Binaries for Win64
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13750 == Reported By:David Doria Assigned To: == Project:CMake Issue ID: 13750 Category: Documentation Reproducibility:N/A Severity: minor Priority: normal Status: new == Date Submitted: 2012-11-27 21:08 EST Last Modified: 2012-11-27 21:08 EST == Summary:Binaries for Win64 Description: I see on this page: http://www.cmake.org/cmake/resources/software.html that there are binaries for Win32 (cmake-2.8.10.1-win32-x86.exe). However, it does not mention that the same executable works for Win64 (which it seems to). Perhaps a note should be added to avoid confusion. Or simply name the executable cmake-2.8.10.1-win.exe and make the description Win 32/64 to be explicit. == Issue History Date ModifiedUsername FieldChange == 2012-11-27 21:08 David DoriaNew 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 0013754]: Ninja: Framework paths are not correctly added to g++ commandline args.
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=13754
==
Reported By:Edward Rudd
Assigned To:
==
Project:CMake
Issue ID: 13754
Category: CMake
Reproducibility:always
Severity: block
Priority: normal
Status: new
==
Date Submitted: 2012-11-28 23:31 WAST
Last Modified: 2012-11-28 23:31 WAST
==
Summary:Ninja: Framework paths are not correctly added to
g++ commandline args.
Description:
I have a project that uses a custom framework path to find OS X frameworks.
When using the ninja generator the -F/path/to/framework/path is not added to the
GCC command line causing compiles to fail.
Steps to Reproduce:
FIND_LIBRARY(SDL2_LIBRARY SDL2
PATHS SDL2/lib/osx)
MARK_AS_ADVANCED(SDL2_LIBRARY)
ADD_LIBRARY(Lib STATIC
${SOURCE}
)
TARGET_LINK_LIBRARIES(Lib ${SDL2_LIBRARY} )
Additional Information:
This is the C++ command called when using the unix makefile generator (paths
changed to protect the innocent)
/usr/bin/c++ -D_DEV -g -arch i386 -isysroot /Developer/SDKs/MacOSX10.6.sdk
-I/path/to/source/src/..-F/path/to/source/SDL2/lib/osx -o
CMakeFiles/Lib.dir/SDL2Threading.cpp.o -c /path/to/source/src/SDL2Threading.cpp
This is that ninja called
/usr/bin/c++ -D_DEV -g
-arch i386 -isysroot /Developer/SDKs/MacOSX10.6.sdk
-I/path/to/source/src/..
-MMD -MT Lib/CMakeFiles/Lib.dir/SDL2Threading.cpp.o
-MF "Lib/CMakeFiles/Lib.dir/SDL2Threading.cpp.o.d"
-o Lib/CMakeFiles/Lib.dir/SDL2Threading.cpp.o
-c /path/to/source/src/SDL2Threading.cpp
==
Issue History
Date ModifiedUsername FieldChange
==
2012-11-28 23:31 Edward RuddNew 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 0013755]: find_package_handle_standard_args(XX DEFAULT_MSG XX_FOUND) always succeeds
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=13755 == Reported By:Nick Hutchinson Assigned To: == Project:CMake Issue ID: 13755 Category: Modules Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2012-11-29 11:20 NZDT Last Modified: 2012-11-29 11:20 NZDT == Summary:find_package_handle_standard_args(XX DEFAULT_MSG XX_FOUND) always succeeds Description: The following CMakeList.txt file always succeeds with "--Found XX: TRUE". It ought not to; XX_FOUND has not been declared anywhere. I would expect find_package_handle_standard_args() to report that XX could not be found, and to set XX_FOUND to false. cmake_minimum_required(VERSION 2.8.8) include (FindPackageHandleStandardArgs) find_package_handle_standard_args(XX DEFAULT_MSG XX_FOUND) == Issue History Date ModifiedUsername FieldChange == 2012-11-29 11:20 Nick HutchinsonNew 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 0013756]: Infinite loop when reconfiguring with different CMAKE_C_COMPILER
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=13756 == Reported By:Nick Hutchinson Assigned To: == Project:CMake Issue ID: 13756 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2012-11-29 11:29 NZDT Last Modified: 2012-11-29 11:29 NZDT == Summary:Infinite loop when reconfiguring with different CMAKE_C_COMPILER Description: It's possible to get CMake stuck in a seemingly infinite loop when reconfiguring a project. Steps to Reproduce: 1. Create the following trivial CMakeList.txt: cmake_minimum_required(VERSION 2.8.8) 2. `cd` to the directory containing this file, and execute `cmake .` 3. Execute `cmake . -DCMAKE_C_COMPILER=cc` Expected Behaviour: CMake reconfigures the project with the specified compiler. Actual Behaviour: CMake prints the following to stdout in an infinite loop: -- Configuring done You have changed variables that require your cache to be deleted. Configure will be re-run and you may have to reset some variables. The following variables have changed: CMAKE_C_COMPILER= cc == Issue History Date ModifiedUsername FieldChange == 2012-11-29 11:29 Nick HutchinsonNew 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 0013757]: display whether or not ccmake is in edit mode
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13757 == Reported By:Andy Bauer Assigned To: == Project:CMake Issue ID: 13757 Category: CCMake Reproducibility:N/A Severity: feature Priority: low Status: new == Date Submitted: 2012-11-29 13:51 EST Last Modified: 2012-11-29 13:51 EST == Summary:display whether or not ccmake is in edit mode Description: When using ccmake it would be nice when editing string inputs to show whether or not the user is in edit mode or not. In the bottom right it shows "CMake Version 2.8.10.2" when not in edit mode and that disappears when in edit mode but that requires the user to remember that to figure out what mode he/she is in. == Issue History Date ModifiedUsername FieldChange == 2012-11-29 13:51 Andy Bauer 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 0013760]: file(STRINGS): very questionable (sufficiently certainly buggy?) behaviour for square brackets
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=13760
==
Reported By:Andreas Mohr
Assigned To:
==
Project:CMake
Issue ID: 13760
Category: CMake
Reproducibility:always
Severity: major
Priority: normal
Status: new
==
Date Submitted: 2012-11-29 16:13 EST
Last Modified: 2012-11-29 16:13 EST
==
Summary:file(STRINGS): very questionable (sufficiently
certainly buggy?) behaviour for square brackets
Description:
I just tried parsing a section that resembles an IDL file part (the format spec
of which has sections enclosed in '[',']').
I was rather very astonished about the result of file(STRINGS) on this
(after already having spent a sizeable chunk of the day about various other
file(STRINGS) specifics, to add insult to injury).
Why in h*ll would file(STRINGS) take such specific care about the format of the
text file?
Don't tell me that it's because of (quoting docs) "Intel Hex and Motorola
S-record files", which could possibly happen to have certain '['-enclosed
sections. That would be a sad result for an otherwise (in the case of
non-Intel/Motorola files) supposedly(?) sufficiently generic file(STRINGS)
functionality.
Needless to say having any []-enclosed yet originally *multi-line* content
end up delivered as a *single* line within foreach() processing is very
problematic when contrasted against my expectations.
If it actually is correct handling (for certain aspects of "correct") and
there's no quite standard CMake mechanism explanation for this that I managed to
miss, then docs should definitely be corrected to mention this possibly
'['-specific handling.
Any ideas or comments about this?
Severity major since it's data corrupting (e.g. going line-by-line over a regex
with start-of-line/end-of-line constraints - ^$ - *will* cause headache or
worse).
Thank you!
Steps to Reproduce:
cmake_minimum_required(VERSION 2.8)
project(file_strings_bug_test NONE)
macro(write_file _file _content)
file(WRITE "${CMAKE_CURRENT_BINARY_DIR}/${_file}" "${_content}")
endmacro(write_file _file _content)
macro(read_file _file)
file(STRINGS "${CMAKE_CURRENT_BINARY_DIR}/${_file}" _content_list)
foreach(line_ ${_content_list})
message("line ${_file}: ${line_}")
endforeach(line_ ${_content_list})
endmacro(read_file _file)
set("content_ok" "Hello
World
My Worrying
Test")
set(content_ko "[${content_ok}]")
set(content_ko2 "Hi
There
[${content_ok}] ")
write_file(file_ok "${content_ok}")
write_file(file_ko "${content_ko}")
write_file(file_ko2 "${content_ko2}")
read_file(file_ok)
read_file(file_ko)
read_file(file_ko2)
Additional Information:
$ cmake ..
line file_ok: Hello
line file_ok: World
line file_ok: My Worrying
line file_ok: Test
line file_ko: [Hello;World;My Worrying;Test]
line file_ko2: Hi
line file_ko2: There
line file_ko2: [Hello;World;My Worrying;Test]
-- Configuring done
-- Generating done
-- Build files have been written to:
/home/andi/prg/cmake_tests/file_strings_bug_test/build
==
Issue History
Date ModifiedUsername FieldChange
==
2012-11-29 16:13 Andreas Mohr 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 0013761]: Add QUIET option to install() command
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=13761 == Reported By:Stefan Eilemann Assigned To: == Project:CMake Issue ID: 13761 Category: CMake Reproducibility:always Severity: feature Priority: normal Status: new == Date Submitted: 2012-11-30 05:12 EST Last Modified: 2012-11-30 05:12 EST == Summary:Add QUIET option to install() command Description: Installing large directories, e.g., the output of a doxygen run, prints one line per file resulting in too much noise in the build output. Add an option to the install() command to not print anything upon make install. == Issue History Date ModifiedUsername FieldChange == 2012-11-30 05:12 Stefan EilemannNew 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 0013762]: Automoc still fails to handle Q_INTERFACES
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=13762 == Reported By:Michael Palimaka Assigned To: == Project:CMake Issue ID: 13762 Category: CMake Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 2012-11-30 08:50 EST Last Modified: 2012-11-30 08:50 EST == Summary:Automoc still fails to handle Q_INTERFACES Description: Automoc is still failing in 2.8.10.2, but this time with phonon-vlc master. It still works fine in 2.8.9 AUTOMOC: error: process for /var/tmp/portage/media-libs/phonon-vlc-/work/phonon-vlc-_build/src/moc_audiodataoutput.cpp failed: /var/tmp/portage/media-libs/phonon-vlc-/work/phonon-backend-vlc-/src/audio/audiodataoutput.h:62: Error: Undefined interface Steps to Reproduce: Clone and build git://anongit.kde.org/phonon-vlc.git == Issue History Date ModifiedUsername FieldChange == 2012-11-30 08:50 Michael PalimakaNew 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 0013763]: Visual Studio target property FOLDER does not work if professional and express edition are installed in parallel
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13763 == Reported By:Christian Oberholzer Assigned To: == Project:CMake Issue ID: 13763 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2012-11-30 11:55 EST Last Modified: 2012-11-30 11:55 EST == Summary:Visual Studio target property FOLDER does not work if professional and express edition are installed in parallel Description: I describe the Problem from the very beginning. I wanted to start development for the new Windows 8 App Store style apps (including tablets and also Windows Phone). To do so I installed Visual Studio 2012 Professional on my Win8 machine. Then I selected a Windows Phone 8 Project which installed a second instance of Visual Studio on my machine called "Microsoft Visual Studio Express 2012 for Windows Phone". However now the set_property(TARGET xyz PROPERTY FOLDER "xyz/xyz") does not work anymore. I had time so I downloaded the source and searched for the issue. I discovered that with Express Editions the FOLDER feature is turned off (I assume because Express does not Support it?). However CMake only checks if an Express Edition is installed but *not* if the user wants to use the pro or the express Edition. I modified the source on my machine to always sets "this->ExpressEdition" to false for the appropriate installer and now it works for me. However I do understand that this is not the correct solution. If anyone is able to point me into the correct direction I might have the time to fix this (in case its not easier for an established dev to make a quick fix). Thanks, Christian == Issue History Date ModifiedUsername FieldChange == 2012-11-30 11:55 Christian OberholzerNew 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 0013764]: is_file_executable() from GetPrerequisites.cmake erroneously returns 0 for DLL on windows
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=13764
==
Reported By:Csaba Keszegh
Assigned To:
==
Project:CMake
Issue ID: 13764
Category: CMake
Reproducibility:always
Severity: trivial
Priority: normal
Status: new
==
Date Submitted: 2012-11-30 14:13 EST
Last Modified: 2012-11-30 14:13 EST
==
Summary:is_file_executable() from GetPrerequisites.cmake
erroneously returns 0 for DLL on windows
Description:
On Windows is_file_executable() checks the extension to determine whether the
file is executable. DLL should also be considered as executable, so fixup_bundle
would work.
Steps to Reproduce:
> cmake -P is_dll_executable.cmake
c:/windows/system32/kernel32.dll: 0
> type is_dll_executable.cmake
include(BundleUtilities)
set(f0 "c:/windows/system32/kernel32.dll")
is_file_executable(f0 is_dll_executable)
message("${f0}: ${is_dll_executable}")
expected output would be:
c:/windows/system32/kernel32.dll: 1
==
Issue History
Date ModifiedUsername FieldChange
==
2012-11-30 14:13 Csaba Keszegh New Issue
2012-11-30 14:13 Csaba Keszegh File Added: GetPrerequisites.cmake.diff
==
--
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 0013765]: Failed to link against framework in /Library/Framework when CMAKE_OS_* variables are set
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13765 == Reported By:Jean-Christophe Fillion-Robin Assigned To: == Project:CMake Issue ID: 13765 Category: CMake Reproducibility:always Severity: major Priority: high Status: new == Date Submitted: 2012-11-30 22:02 WAST Last Modified: 2012-11-30 22:02 WAST == Summary:Failed to link against framework in /Library/Framework when CMAKE_OS_* variables are set Description: Failed to link against framework in /Library/Framework when CMAKE_OS_* variables are set The problem occurs when using: - CMake 2.8.10.2 - mac OSX 10.8 - XCode Version 4.5.2 (4G2008a) - g++ --version i686-apple-darwin11-llvm-g++-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00) After installing qt 4.7.4: ftp://ftp.qt.nokia.com/qt/source/qt-mac-opensource-4.7.4.dmg This small project allows to reproduce the problem. $ git clone git://github.com/jcfr/CMakeWithQtFramework.git $ mkdir CMakeWithQtFramework-build $ cd CMakeWithQtFramework-build $ cmake ../ […] $ make VERBOSE=1 […] Linking CXX executable foo "/Volumes/Dashboards/Support/CMake 2.8-10.app/Contents/bin/cmake" -E cmake_link_script CMakeFiles/foo.dir/link.txt --verbose=1 /usr/bin/c++-arch x86_64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk -mmacosx-version-min=10.8 -Wl,-search_paths_first -Wl,-headerpad_max_install_names CMakeFiles/foo.dir/main.cpp.o -o foo -framework QtWebKit -framework QtXmlPatterns -framework QtGui -framework QtNetwork -framework QtCore ld: framework not found QtWebKit clang: error: linker command failed with exit code 1 (use -v to see invocation) make[2]: *** [foo] Error 1 make[1]: *** [CMakeFiles/foo.dir/all] Error 2 make: *** [all] Error 2 By manually adding -F /Library/Frameworks to the build line, it succeed. /usr/bin/c++-arch x86_64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk -mmacosx-version-min=10.8 -Wl,-search_paths_first -Wl,-headerpad_max_install_names CMakeFiles/foo.dir/main.cpp.o -o foo -framework QtWebKit -framework QtXmlPatterns -framework QtGui -framework QtNetwork -framework QtCore -F /Library/Frameworks/ I would assume that CMake should automatically add the "-F /Library/Frameworks/" == Issue History Date ModifiedUsername FieldChange == 2012-11-30 22:02 Jean-Christophe Fillion-RobinNew 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 0013767]: Unix Makefiles + MSVC = cannot link
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=13767
==
Reported By:Pau Garcia i Quiles
Assigned To:
==
Project:CMake
Issue ID: 13767
Category: (No Category)
Reproducibility:always
Severity: major
Priority: normal
Status: new
==
Date Submitted: 2012-11-30 20:29 EST
Last Modified: 2012-11-30 20:29 EST
==
Summary:Unix Makefiles + MSVC = cannot link
Description:
A heated discussion on adopting CMake or not arised a few weeks ago in the
mingw-w64 project:
http://thread.gmane.org/gmane.comp.gnu.mingw.w64.general/6338
Most of the issues pointed there are not real issues but lack of knowledge
and/or the usual complaints ("I need CMake in order to compile a project that
uses CMake").
Today Jonathan Yong did show one real issue: trying to use Unix Makefiles with
MSVC.
Steps to Reproduce:
This is what I have noticed:
* From the CMake GUI, even if you say "I will specify compilers" and select
cl.exe for both C and C++, CMake will not find the resource compiler (rc.exe,
apparently CMake is not looking in the Windows SDK folder), the linker
(link.exe, apparently it's not looking for it where cl.exe is) and make.exe
(CMake should look for Cygwin's and MinGW's, although it's going to be mostly a
wild-guess)
* Even if specifying everything from the command line, linkage will not work
because the library search directories have not been specified in either
CMAKE_C_FLAGS, CMAKE_CXX_FLAGS or CMAKE_LINKER_FLAGS. What's missing is
something like "/link /LIBPATH:C:\Program Files (x86)\Microsoft Visual Studio
10.0\VC\lib /LIBPATH:C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\Lib"
(remove the "/link" for CMAKE_LINKER_FLAGS).
Yes, I know, Unix Makefiles on Windows with MSVC!? :-)
Additional Information:
Sample huge command line that fails:
cmake -G "Unix Makefiles" -DCMAKE_C_COMPILER="C:/Program Files (x86)/Microsoft
Visual Studio 10.0/VC/bin/cl.exe" -DCMAKE_CXX_COMPILER="C:/Program Files
(x86)/Microsoft Visual Studio 10.0/VC/bin/cl.exe"
-DCMAKE_RC_COMPILER="C:/Program Files (x86)/Microsoft
SDKs/Windows/v7.1A/Bin/RC.Exe" -DCMAKE_LINKER="C:/Program Files (x86)/Microsoft
Visual Studio 10.0/VC/bin/link.exe"
-DCMAKE_MAKE_PROGRAM="C:/mingw32/bin/mingw32-make.exe" ../xdelta3
See attache file error.txt for the full output
==
Issue History
Date ModifiedUsername FieldChange
==
2012-11-30 20:29 Pau Garcia i QuilesNew Issue
2012-11-30 20:29 Pau Garcia i QuilesFile Added: error.txt
==
--
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 0013768]: set_target_properties For Library Target Has No Effect On Windows
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13768 == Reported By:Janne Rönkkö Assigned To: == Project:CMake Issue ID: 13768 Category: CMake Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 2012-12-01 04:22 EST Last Modified: 2012-12-01 04:22 EST == Summary:set_target_properties For Library Target Has No Effect On Windows Description: set_target_properties does not have any effect on Windows. See example from the attached file. The example puts the created library into libs directory on Linux. Steps to Reproduce: Under MSYS 1. tar xf example.tar 2. mkdir build 3. cd build 4. cmake .. -G 'MSYS Makefiles' 5. make Under CMD 1. # extract example.tar 2. mkdir buid 3. cd build 4. cmake .. -G "NMake Makefiles" 5. nmake The library is created in the current directory while the set_target_properties sets the LIBRARY_OUTPUT_PATH to libs Additional Information: Tested with NMake Makefiles, MSYS Makefiles and Ninja generators. == Issue History Date ModifiedUsername FieldChange == 2012-12-01 04:22 Janne Rönkkö New Issue 2012-12-01 04:22 Janne Rönkkö File Added: example.tar == -- 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 0013769]: FindSDL.cmake libraries in wrong order
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=13769
==
Reported By:R Cullen
Assigned To:
==
Project:CMake
Issue ID: 13769
Category: Modules
Reproducibility:always
Severity: major
Priority: normal
Status: new
==
Date Submitted: 2012-12-02 03:53 EST
Last Modified: 2012-12-02 03:53 EST
==
Summary:FindSDL.cmake libraries in wrong order
Description:
The FindSDL.cmake file does not order the SDL libraries correctly. "-lSDLmain"
must be added to the g++ arguments before "-lSDL", not doing this results in
linking errors like those below :
c:/mingw/bin/../lib/gcc/mingw32/4.6.2/../../../../mingw32/lib\libSDLmain.a(SDL_win32_main.o):
In function `redirect_output':
/Users/slouken/release/SDL/SDL-1.2.15/./src/main/win32/SDL_win32_main.c:219:
undefined reference to `SDL_strlcpy'
/Users/slouken/release/SDL/SDL-1.2.15/./src/main/win32/SDL_win32_main.c:220:
undefined reference to `SDL_strlcat'
...
Steps to Reproduce:
Install MinGW
Compile SDL using MinGW
Compile attached program using :
cmake -Wdev -DSDL_BUILDING_LIBRARY=FALSE -G"MSYS Makefiles" .. && make VERBOSE=1
Additional Information:
Here are the sources if you dont trust the .zip
test.cpp
#include "SDL.h"
#define SCREEN_WIDTH 320
#define SCREEN_HEIGHT 240
#define SCREEN_DEPTH 8
int main(int argc, char *argv[]) {
SDL_Surface *screen;
Uint8 *p;
int x = 10;
int y = 20;
SDL_Init(SDL_INIT_VIDEO);
screen = SDL_SetVideoMode(SCREEN_WIDTH, SCREEN_HEIGHT, SCREEN_DEPTH,
SDL_SWSURFACE);
p = (Uint8 *)screen->pixels + y * screen->pitch + x *
screen->format->BytesPerPixel;
*p=0xf0;
SDL_Flip(screen);
while(1);
}
CMakeLists.txt
cmake_minimum_required(VERSION 2.6)
project(MyProject)
set(EXECUTABLE_NAME "sdl_bug")
#SET THIS TO YOUR MING INSTALATION
if( WIN32 )
set(CMAKE_PREFIX_PATH "c:/MinGW/")
endif()
add_executable(${EXECUTABLE_NAME} test.cpp)
find_package(SDL REQUIRED)
if(SDL_FOUND)
include_directories(${SDL_INCLUDE_DIR})
target_link_libraries(${EXECUTABLE_NAME} ${SDL_LIBRARY})
endif()
==
Issue History
Date ModifiedUsername FieldChange
==
2012-12-02 03:53 R Cullen New Issue
2012-12-02 03:53 R Cullen File Added: sources.zip
==
--
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 0013770]: Visual Studio Express 2012 Solution Folders
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=13770
==
Reported By:Paris
Assigned To:
==
Project:CMake
Issue ID: 13770
Category: CMake
Reproducibility:always
Severity: feature
Priority: normal
Status: new
==
Date Submitted: 2012-12-02 06:59 EST
Last Modified: 2012-12-02 06:59 EST
==
Summary:Visual Studio Express 2012 Solution Folders
Description:
Solution folders are now supported in Visual Studio Express 2012.
They are only displayed, cannot be modified, but yet they are supported.
Would be good to allow generating them by Cmake then...
Generation is blocked in CMake source code for Express versions since Visual
Studio 10.
In additional info is the patch to enable back support for Solution Folders by
CMake in Visual Studio Express 2012.
Additional Information:
Source/cmGlobalVisualStudio10Generator.h | 2 +-
Source/cmGlobalVisualStudio11Generator.cxx | 7 +++
Source/cmGlobalVisualStudio11Generator.h | 1 +
3 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/Source/cmGlobalVisualStudio10Generator.h
b/Source/cmGlobalVisualStudio10Generator.h
index b377a20..1f27682 100644
--- a/Source/cmGlobalVisualStudio10Generator.h
+++ b/Source/cmGlobalVisualStudio10Generator.h
@@ -82,7 +82,7 @@ protected:
std::string PlatformToolset;
bool ExpressEdition;
- bool UseFolderProperty();
+ virtual bool UseFolderProperty();
private:
class Factory;
diff --git a/Source/cmGlobalVisualStudio11Generator.cxx
b/Source/cmGlobalVisualStudio11Generator.cxx
index ba30e18..eac1b8d 100644
--- a/Source/cmGlobalVisualStudio11Generator.cxx
+++ b/Source/cmGlobalVisualStudio11Generator.cxx
@@ -93,3 +93,10 @@ cmLocalGenerator
*cmGlobalVisualStudio11Generator::CreateLocalGenerator()
lg->SetGlobalGenerator(this);
return lg;
}
+
+
+//
+bool cmGlobalVisualStudio11Generator::UseFolderProperty()
+{
+ return cmGlobalGenerator::UseFolderProperty();
+}
diff --git a/Source/cmGlobalVisualStudio11Generator.h
b/Source/cmGlobalVisualStudio11Generator.h
index 8898c5d..99cc5a0 100644
--- a/Source/cmGlobalVisualStudio11Generator.h
+++ b/Source/cmGlobalVisualStudio11Generator.h
@@ -33,6 +33,7 @@ public:
virtual std::string GetUserMacrosDirectory() { return ""; }
protected:
virtual const char* GetIDEVersion() { return "11.0"; }
+ virtual bool UseFolderProperty();
private:
class Factory;
};
==
Issue History
Date ModifiedUsername FieldChange
==
2012-12-02 06:59 Paris 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 0013771]: Use CMAKE_CURRENT_LIST_DIR instead of CMAKE_ROOT in FindSWIG module.
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13771 == Reported By:hsor001 Assigned To: == Project:CMake Issue ID: 13771 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2012-12-03 02:16 EST Last Modified: 2012-12-03 02:16 EST == Summary:Use CMAKE_CURRENT_LIST_DIR instead of CMAKE_ROOT in FindSWIG module. Description: The FindSWIG.cmake module uses CMAKE_ROOT/Moudles to set the path of the UseSWIG.cmake file, it would be better to have this set to CMAKE_CUURENT_LIST_DIR. == Issue History Date ModifiedUsername FieldChange == 2012-12-03 02:16 hsor001New 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 0013772]: UseSWIG.cmake does not handle relative paths with parent directories
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13772 == Reported By:hsor001 Assigned To: == Project:CMake Issue ID: 13772 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2012-12-03 02:27 EST Last Modified: 2012-12-03 02:27 EST == Summary:UseSWIG.cmake does not handle relative paths with parent directories Description: When using swig with relative paths that contain parent directories the generated location of the cxx file is not set properly. Steps to Reproduce: Use swig to wrap a python module where the interface file is in a sibling directory to the CMakeLists.txt file: set(interface_src ../interfaces/lib.i) Try configuring and building this swig module with a build directory anywhere other than a sibling directory. == Issue History Date ModifiedUsername FieldChange == 2012-12-03 02:27 hsor001New 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 0013774]: Support v110_xp target with MSVC 2012 Update 1
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13774 == Reported By:Filip Konvicka (LOGIS) Assigned To: == Project:CMake Issue ID: 13774 Category: CMake Reproducibility:always Severity: block Priority: urgent Status: new == Date Submitted: 2012-12-04 10:51 EST Last Modified: 2012-12-04 10:51 EST == Summary:Support v110_xp target with MSVC 2012 Update 1 Description: Microsoft has released an important update to MSVC (MSVC 2012 Update 1) that allows us to build applications that target Windows 2003 and Windows XP. This requires that a new non-default toolset is used for the build: v110_xp (the default is called v110). There is no way I know of in CMake to do this properly, as the generator is fixed on v110. This is blocking us from using MSVC 2012 with CMake. Perhaps adding a clone of the current generator with a different name and a different target toolset is sufficient...? Additional Information: Interesting links on the subject: http://blogs.msdn.com/b/chuckw/archive/2012/11/26/visual-studio-2012-update-1.aspx http://blogs.msdn.com/b/vcblog/archive/2012/10/08/10357555.aspx == Issue History Date ModifiedUsername FieldChange == 2012-12-04 10:51 Filip Konvicka (LOGIS)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 0013778]: CPackRPM: Add support for Packager tag
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=13778
==
Reported By:David Imhoff
Assigned To:
==
Project:CMake
Issue ID: 13778
Category: CMake
Reproducibility:always
Severity: feature
Priority: normal
Status: new
==
Date Submitted: 2012-12-06 09:23 EST
Last Modified: 2012-12-06 09:23 EST
==
Summary:CPackRPM: Add support for Packager tag
Description:
RPM allows setting a Packager tag that contains the contact information of the
packager, see
http://www.rpm.org/max-rpm/s1-rpm-inside-tags.html#S3-RPM-INSIDE-PACKAGER-TAG .
Currently it is not possible to specify this tag when packaging with CPack.
Attached patch adds support for setting the packager tag on RPM's using one of
the following defines (in specified order):
- CPACK_RPM_{component}_PACKAGE_PACKAGER
- CPACK_RPM_PACKAGE_PACKAGER
- CPACK_PACKAGE_CONTACT
==
Issue History
Date ModifiedUsername FieldChange
==
2012-12-06 09:23 David Imhoff New Issue
2012-12-06 09:23 David Imhoff File Added: cpackrpm_packager.patch
==
--
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 0013251]: cmake -E tar fails to extract some files correctly
The following issue is now in status NEW (again) == http://www.cmake.org/Bug/view.php?id=13251 == Reported By:sigma Assigned To: == Project:CMake Issue ID: 13251 Category: CMake Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 2012-05-27 07:37 EDT Last Modified: 2012-12-07 11:12 EST == Summary:cmake -E tar fails to extract some files correctly Description: On certain tar.gz files cmake fails to extract them properly. I suspect this has to do with tar.gz files that have unix symlinks and are extracted on windows. One such file can be obtained from: http://openssl.org/source/openssl-1.0.1c.tar.gz When I try: cmake -E tar xf openssl-1.0.1c.tar.gz it fails on some files: CMake Error: Problem with archive_write_header(): Can't create '\' CMake Error: Current file:openssl-1.0.1c/apps/md4.c CMake Error: Problem with archive_write_header(): Can't create '\' CMake Error: Current file:openssl-1.0.1c/include/openssl/aes.h CMake Error: Problem with archive_write_header(): Can't create '\' CMake Error: Current file:openssl-1.0.1c/include/openssl/asn1.h CMake Error: Problem with archive_write_header(): Can't create '\' CMake Error: Current file:openssl-1.0.1c/include/openssl/asn1_mac.h CMake Error: Problem with archive_write_header(): Can't create '\' CMake Error: Current file:openssl-1.0.1c/include/openssl/asn1t.h CMake Error: Problem with archive_write_header(): Can't create '\' CMake Error: Current file:openssl-1.0.1c/include/openssl/bio.h CMake Error: Problem with archive_write_header(): Can't create '\' Using other extraction tools, e.g. cygwin or 7zip, this works without any problems. == Relationships ID Summary -- related to 0011176 "cmake -E tar" encodes long paths such ... related to 0010162 CPack Cannot create binary zip archive ... parent of 0011766 CPack using native TAR with adjustable ... == -- (0029571) Eric NOULARD (developer) - 2012-05-27 07:56 http://www.cmake.org/Bug/view.php?id=13251#c29571 -- I can extract this archive with CMake 2.8.8 on Linux (Debian Squeeze) without trouble... -- (0029572) Eric NOULARD (developer) - 2012-05-27 07:58 http://www.cmake.org/Bug/view.php?id=13251#c29572 -- You are right those files are symlinks. How do other tools like 7-zip handles those symlink on Windows? Do they create plain files which are a copy of the symlink target? Do they handle symlink in some way? -- (0029573) sigma (reporter) - 2012-05-27 10:48 http://www.cmake.org/Bug/view.php?id=13251#c29573 -- I created a test tar.gz with various file types to see what happens. Compress it on a linux box with tar (GNU tar) 1.26: tar -cpvzf cmake-tar-test.tar.gz cmake-tar-test/ The archive contains: cmake-tar-test/: total 12 drwxr-xr-x 2 root root 4096 May 27 16:44 bin drwxr-xr-x 2 root root 4096 May 27 17:23 links drwxr-xr-x 2 root root 4096 May 27 16:44 src cmake-tar-test/bin: total 100 -rwxr--r-- 1 root root 99328 May 27 16:43 main.exe cmake-tar-test/links: total 0 lrwxrwxrwx 1 root root 6 May 27 16:46 dir-link -> ../src lrwxrwxrwx 1 root root 15 May 27 16:45 main.cpp -> ../src/main.cpp lrwxrwxrwx 1 root root 15 May 27 16:45 main.exe -> ../bin/main.exe lrwxrwxrwx 1 root root 13 May 27 16:45 main.h -> ../src/main.h cmake-tar-test/src: total 8 -rwxr--r-- 1 root root 127 May 27 16:42 main.cpp -rwxr--r-- 1 root root 19 May 27 16:42 main.h So there is a mixture of symlinks to various filetypes and directories. main.exe was compiled on win7 and is a valid executable. I moved the files back to the Win7 machine to see how the different programs (7-zip, cygwin, cmake) behave. cmake log is here: cmake -E tar xvfz cmake-tar-test.tar.gz x cmake-tar-test/ x cmake-tar-test/links/
[cmake-developers] [CMake 0013780]: Continuous ctest does not work if executed in individual steps
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13780 == Reported By:Frank U. May Assigned To: == Project:CMake Issue ID: 13780 Category: CTest Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2012-12-07 17:27 EST Last Modified: 2012-12-07 17:27 EST == Summary:Continuous ctest does not work if executed in individual steps Description: When running CTest continuous in individual steps every step following ContinuousUpdate is skipped. Basically it is a nice feature that continuous tests don't run, if there are no updates. However, it seems the current implementation breaks running continuous tests in individual steps. ContinuousUpdate works fine and reports the update. All following steps just report the site and the build name and do nothing else. Steps to Reproduce: 1.) Set up a CTest environment updating from a repository (I am using Git). 2.) From workspace A push an update to the repository. 3.) From workspace B run: ctest -C Release -D ContinuousStart ctest -C Release -D ContinuousUpdate ctest -C Release -D ContinuousConfigure ctest -C Release -D ContinuousBuild ctest -C Release -D ContinuousSubmit 4.) Note that "ContinuousUpdate" properly reports the update, while the following steps do nothing but report site and build name. 5.) Same issue, if you try: ctest -C Release --track Continuous -D Experimental[ALL_STEPS] 6.) Same issue if you try: ctest -C Release --track "Continuous Master" -D Continuous[ALL_STEPS] 7.) Same issue if you try: ctest -C Release --track "Continuous Master" -D Experimental[ALL_STEPS] 8.) Workaround: it works, if you try: ctest -C Release --track "Commit Master" -D Experimental[ALL_STEPS] Additional Information: As I am running continuous tests from my Git repository hook, the latter is a feasible workaround. But it is not nice at all; I would highly appreciate, if this could be fixed. Or if someone could point out, where I am showing off to be a dumb user. ;) To me it seems that the information that there was indeed an update from the repository gets lost between ContinuousUpdate and the following steps. == Issue History Date ModifiedUsername FieldChange == 2012-12-07 17:27 Frank U. May 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 0013784]: [OSX] Copy directories as easily as files into the application bundle
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=13784
==
Reported By:valentin
Assigned To:
==
Project:CMake
Issue ID: 13784
Category: CMake
Reproducibility:have not tried
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2012-12-10 21:04 EST
Last Modified: 2012-12-10 21:04 EST
==
Summary:[OSX] Copy directories as easily as files into the
application bundle
Description:
First of all, I apologize for my English :)
I'm here to submit a feature request about the Copy File Phase into the
application CFBundle.
Currently, Cmake doc tells us to handle this phase with the
set_source_files_properties() command, instead of any other, like the install()
command that Xcode didn't properly transcribe.
But if I go on this way, and use the default Makefile generator, copying
directories juste create an empty file as use Xcode generator works fine.
Copying directory (with target or source properties) can be useful to copy a
framework or an external resource.
I suggest just add something like the second line
std::string copyCommand = "$(CMAKE_COMMAND) -E copy";
copyCommand += cmSystemTools::FileIsDirectory(input) ? "_directory " : " ";
in the cmMakefileTargetGenerator::WriteMacOSXContentRules function
I understand this more a hack than a conceptual solution, but since the design
of this "Copy phase" was initially developed for a file-by-file copy, this is
the easier and harmless workaround I see.
The ideal solution would be to port the MACOSX_PACKAGE_LOCATION property on the
set_target_properties() command
I apologize if this request was already made or wrote.
Steps to Reproduce:
Copy a directory with set_property(SOURCE ${DIR} PROPERTY
MACOSX_PACKAGE_LOCATION Resources)
and use the Makefile generator.
==
Issue History
Date ModifiedUsername FieldChange
==
2012-12-10 21:04 valentin 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 0013785]: INSTALL command does not support a QUIET/SILENT option
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13785 == Reported By:Emmanuel Blot Assigned To: == Project:CMake Issue ID: 13785 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2012-12-12 10:41 CET Last Modified: 2012-12-12 10:41 CET == Summary:INSTALL command does not support a QUIET/SILENT option Description: It would be very nice if there was a way to force the INSTALL() command not to print what it is doing: -- Installing: /Users/eblot/Source/... -- Up-to-date: /Users/eblot/Sources/... ... Rationale: When performing build+install in one step, install verbosity is so long that important information, such as build warnings, are scrolled out from the terminal viewport and may remain unnoticed. I understand that people are likely to want INSTALL() to be verbose, but a simple option such as INSTALL(... QUIET ...) would be nice when these traces are not wanted. == Issue History Date ModifiedUsername FieldChange == 2012-12-12 10:41 Emmanuel Blot 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 0013786]: function() set(PARENT_SCOPE) buggy: very surprising warn-uninitialized inconsistency for (non-)empty values
The following issue has been SUBMITTED.
==
http://www.itk.org/Bug/view.php?id=13786
==
Reported By:Andreas Mohr
Assigned To:
==
Project:CMake
Issue ID: 13786
Category: CMake
Reproducibility:always
Severity: major
Priority: high
Status: new
==
Date Submitted: 2012-12-12 05:01 EST
Last Modified: 2012-12-12 05:01 EST
==
Summary:function() set(PARENT_SCOPE) buggy: very surprising
warn-uninitialized inconsistency for (non-)empty values
Description:
I tried to get all my code free of issues,
thus I enabled --warn-uninitialized.
I was very surprised to find that initialization state of a function result
(PARENT_SCOPE) variable is being very negatively influenced by the value of the
passed variable being empty vs. non-empty,
as can be gathered from the sample below warning about result_empty yet properly
*not* warning about result_non_empty.
This should emphatically _not_ be the case - a result variable should *always*
get properly initialized (instantiated) in outer scope, no frn' matter which
value it may happen to get assigned.
And it's not a "this variable already exists in outer scope" vs. "does not exist
--> problem" issue: when assigning non-empty values the outer-scope variable
*does* get created, yet not for empty ones --> BUG.
Note that pre-initializing the result var to "" prior to invoking the function
does successfully silence the initialization warning.
And note that doing this initialization with a non-empty value and subsequently
calling the function *does* let the function reset the variable to empty - IOW
the variable *does* get assigned by the function in *this* case - just not if it
didn't exist previously!
Happening on both Win7 2.8.10.2 and RHEL5 2.8.8.
Severity major and prio high since it's a foundation-shattering inconsistency ;)
Given this bug it's impossible to get one's code warning-free (when making use
of clean result-use-only variable getter functions which happen to return empty
values in certain conditions).
A mere "not succeeding in getting the code warning-free" is a rather benign
concern - some actively disrupting bug scenarios due to this issue might be
conceivable, too.
Thanks!
Steps to Reproduce:
cmake_minimum_required(VERSION 2.8)
function(getter _result)
set(result_ "${desired_result}")
set(${_result} "${result_}" PARENT_SCOPE)
endfunction(getter _result)
#set(result_empty "bye, cruel world") # < toggle this!
set(desired_result "")
getter(result_empty)
set(desired_result "non-empty")
getter(result_non_empty)
message("result_empty ${result_empty}, result_non_empty ${result_non_empty}.")
Additional Information:
$ cmake --warn-uninitialized .
Warn about uninitialized values.
CMake Warning (dev) at
/home/amoh/privat/cmake_tests/bug_function_result_uninitialized_warning/CMakeLists.txt:14:
uninitialized variable 'result_empty'
This warning is for project developers. Use -Wno-dev to suppress it.
result_empty , result_non_empty non-empty.
-- Configuring done
-- Generating done
==
Issue History
Date ModifiedUsername FieldChange
==
2012-12-12 05:01 Andreas Mohr 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 0013787]: Wrong default value of CPACK_PACKAGE_INSTALL_REGISTRY_KEY
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=13787
==
Reported By:Jesus Malo Poyatos
Assigned To:
==
Project:CMake
Issue ID: 13787
Category: CPack
Reproducibility:always
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2012-12-12 06:54 EST
Last Modified: 2012-12-12 06:54 EST
==
Summary:Wrong default value of
CPACK_PACKAGE_INSTALL_REGISTRY_KEY
Description:
As far as I could found, the default value of CPACK_PACKAGE_INSTALL_REGISTRY_KEY
should be "${CPACK_PACKAGE_NAME} ${CPACK_PACKAGE_VERSION}" (see
http://www.cmake.org/pipermail/cmake/2010-September/039663.html), however if you
look at CPack.cmake, you will find the following (line 381):
cpack_set_if_not_set(CPACK_PACKAGE_INSTALL_REGISTRY_KEY
"${CPACK_PACKAGE_INSTALL_DIRECTORY}")
Is it intentionally?
BTW, the documentation of CPACK_PACKAGE_INSTALL_REGISTRY_KEY is incomplete (no
default value explained) at
http://www.cmake.org/cmake/help/v2.8.10/cpack.html#variable:CPACK_PACKAGE_INSTALL_REGISTRY_KEY
==
Issue History
Date ModifiedUsername FieldChange
==
2012-12-12 06:54 Jesus Malo PoyatosNew 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 0013788]: Hide Automoc Targets in Visual Studio projects
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13788 == Reported By:Shaun Williams Assigned To: == Project:CMake Issue ID: 13788 Category: CMake Reproducibility:always Severity: feature Priority: normal Status: new == Date Submitted: 2012-12-12 15:07 EST Last Modified: 2012-12-12 15:07 EST == Summary:Hide Automoc Targets in Visual Studio projects Description: This is a feature request to hide the _automoc projects in a folder in Visual Studio: http://public.kitware.com/pipermail/cmake-developers/2012-June/004402.html It is also related to issue 0013688. The included patch adds in a new global property: $ cmake --help-property AUTOMOC_FOLDER cmake version 2.8.10.20121212 AUTOMOC_FOLDER Name of FOLDER for *_automoc targets that are added automatically by CMake. If not set, CMake uses the FOLDER property of the parent target as a default value for this property. See also the documentation for the FOLDER target property and the AUTOMOC target property. Steps to Reproduce: SET_PROPERTY(GLOBAL PROPERTY USE_FOLDERS ON) SET_PROPERTY(GLOBAL PROPERTY AUTOMOC_FOLDER automoc) == Issue History Date ModifiedUsername FieldChange == 2012-12-12 15:07 Shaun Williams New Issue 2012-12-12 15:07 Shaun Williams File Added: automoc_folder.patch == -- 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 0013789]: WIX additional support for Product Icon, UI Dialog and UI Banner
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=13789 == Reported By:Eric LaFranchi Assigned To: == Project:CMake Issue ID: 13789 Category: CMake Reproducibility:always Severity: feature Priority: high Status: new == Date Submitted: 2012-12-12 19:03 EST Last Modified: 2012-12-12 19:03 EST == Summary:WIX additional support for Product Icon, UI Dialog and UI Banner Description: CMake 2.8.11 work in progress branch. The WIX support works fine, no issues. I want to propose a straight forward addition for the 2.8.11 release. 1. Offer the option to set the application icon that appears in "Uninstall or change a program" (add/remove programs). 2. Offer the option to set the UI Banner and UI Dialog images. Steps to Reproduce: Latest source. Windows XP or later 32/64 bit system. Create a WIX package and then examine the "Uninstall or change a program" (add/remove programs) and notice the default WIX icon. The installer uses WIX default images for initial UI dialog and the UI banner. Additional Information: I did not update the tests; set the variables is optional and someone will need to manually run the installer to see if they work correctly. New CMake variables: CPACK_WIX_PRODUCT_ICON CPACK_WIX_UI_BANNER CPACK_WIX_UI_DIALOG Documentation: CPACK_WIX_PRODUCT_ICON -- icon used to the left of the application entry in add/remove programs. CPACK_WIX_UI_BANNER -- 493 by 58 pixels, this bitmap will appear at the top of all but the first page of the installer. CPACK_WIX_UI_DIALOG -- 493 by 312 pixels, this bitmap will appear on the first page of the installer. Two files are updated: cmCPackWIXGenerator.cxx and WIX.template.in. Diffs attached. == Issue History Date ModifiedUsername FieldChange == 2012-12-12 19:03 Eric LaFranchi New Issue 2012-12-12 19:03 Eric LaFranchi File Added: CMake-WIX-Feature-Request.diff == -- 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 0013790]: regex replace does not allow anchored empty matches
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=13790
==
Reported By:mwoehlke
Assigned To:
==
Project:CMake
Issue ID: 13790
Category: CMake
Reproducibility:always
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2012-12-13 13:48 EST
Last Modified: 2012-12-13 13:48 EST
==
Summary:regex replace does not allow anchored empty matches
Description:
string(REGEX REPLACE) fails with error 'string sub-command REGEX, mode REPLACE
regex matched an empty string.' when the regular expression is
anchored. Since the position of the match is non-ambiguous when an anchor is
present, the replace should succeed, even if the substring being replaced is
empty. (Other tools, e.g. sed, are able to do this.)
Steps to Reproduce:
set(FOO foo)
string(REGEX REPLACE "$" "_suffix" BAR "${FOO}")
(Expected result: BAR contains "foo_suffix")
Additional Information:
The above example is contrived for the sake of simplification. An actual use
case might be replacing an existing prefix/suffix that matches a regular
expression and may or may not be present.
==
Issue History
Date ModifiedUsername FieldChange
==
2012-12-13 13:48 mwoehlke 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 0013791]: CMake does not support generating projects for Windows Phone 8.
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=13791 == Reported By:jujjyl Assigned To: == Project:CMake Issue ID: 13791 Category: CMake Reproducibility:always Severity: feature Priority: normal Status: new == Date Submitted: 2012-12-13 15:55 EST Last Modified: 2012-12-13 15:55 EST == Summary:CMake does not support generating projects for Windows Phone 8. Description: I have not found an option to generate solution/project files for "Visual Studio 2012 Express for Windows Phone 8". The project files to target Windows Phone 8 differ somewhat of those from Windows Desktop 8 and Windows RT 8. I assume that since Windows RT 8 option doesn't yet exist, Windows Phone 8 targeting does not exist either? Marking down this issue to discuss required additions towards supporting this. Additional Information: I went through and compared .vcxproj files for Windows Phone 8 and Windows RT 8. The project file generated for "Visual Studio 11" requires at least the following modifications to allow Windows Phone 8 deployment: - Must add elements project name? en-US 11.0 true Project_Name_$(Configuration)_$(Platform).xap true to the section of the generated .vcxproj file. - Must replace v110 with v110_wp80 - Must remove default-added linking to the following libraries: kernel32.lib;user32.lib;gdi32.lib;winspool.lib;shell32.lib;ole32.lib;oleaut32.lib;uuid.lib;comdlg32.lib;advapi32.lib; - Must add a line before the section in the .vcxproj file. - Must add a reference to assembly 'Platform.winmd' to the compiler options. The command line for this is "/FU Platform.winmd" Note that the true element that exists for Win8RT project files is not present for Win8 Phone project files. I hope this list is useful for someone that might be capable in implementing support for this in cmake. A good way to compare is to open VS2012 and create a new project from the native C++ Direct3D application template, which exists for both VS2012 Express for Windows 8 and V2012 Express for Windows Phone 8. Comparing the .vcxproj files gives a good diff of the changes. == Issue History Date ModifiedUsername FieldChange == 2012-12-13 15:55 jujjyl 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 0013792]: REGEX REPLACE fails if () capture is empty
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=13792
==
Reported By:mwoehlke
Assigned To:
==
Project:CMake
Issue ID: 13792
Category: CMake
Reproducibility:always
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2012-12-13 16:26 EST
Last Modified: 2012-12-13 16:26 EST
==
Summary:REGEX REPLACE fails if () capture is empty
Description:
string(REGEX REPLACE) fails for certain patterns with 'matched an empty string'
error if a capture grood is empty, even if the full match is non-empty.
Steps to Reproduce:
set(input foo)
string(REGEX REPLACE "^([^.]*)(\\..*)?$" "\\1" output ${input})
Additional Information:
CMake is correctly matching the regular expression (as can be seen by examining
the captures), and the overall pattern (which is the old text to be replaced) is
non-empty, so there should be no problem. (Even more interestingly, while the
above pattern triggers the problem, other patterns which one might expect to
tickle the same glitch do not.)
==
Issue History
Date ModifiedUsername FieldChange
==
2012-12-13 16:26 mwoehlke 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 0013794]: find_package(PythonLibs) finds different version of Python headers and libraries
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=13794
==
Reported By:Tobias Pfaff
Assigned To:
==
Project:CMake
Issue ID: 13794
Category: CMake
Reproducibility:always
Severity: major
Priority: high
Status: new
==
Date Submitted: 2012-12-13 19:47 EST
Last Modified: 2012-12-13 19:47 EST
==
Summary:find_package(PythonLibs) finds different version of
Python headers and libraries
Description:
PythonLibs returns inconsistent versions for lib and include dir:
PYTHON_INCLUDE_DIR = /usr/include/python2.7
PYTHON_LIBRARIES = /usr/lib/python3.2/config/libpython3.2.so
resulting in linker errors.
The latter is probably the culprit, see cmake output:
Found PythonLibs: /usr/lib/python3.2/config/libpython3.2.so (found version
"2.7.3")
The 2.7 version is in /usr/lib/python2.7/config/libpython2.7.so
This problem is probably specific to Ubuntu 12.10. It ships with 3.2 libraries
on default, but no headers (unless you install python3-dev). It applies to both
cmake version 2.8.9 (which comes with the distribution) and the newest 2.8.10.2.
I have not found a workaround yet -- apart from directly specifying the
directories, which is not an option as I am distributing my code, and it should
run on all client configurations.
Python_ADDITIONAL_VERSIONS e.g. do not help.
Steps to Reproduce:
find_package(PythonLibs REQUIRED)
message(${PYTHON_INCLUDE_DIRS})
message(${PYTHON_LIBRARIES})
on Ubuntu 12.10, with package python-dev installed (but python3-dev NOT
installed)
==
Issue History
Date ModifiedUsername FieldChange
==
2012-12-13 19:47 Tobias Pfaff 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 0013795]: FortranCInterface mangling detection fails for PathScale (pathf95)
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13795 == Reported By:tobias Assigned To: == Project:CMake Issue ID: 13795 Category: CMake Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 2012-12-14 07:05 EST Last Modified: 2012-12-14 07:05 EST == Summary:FortranCInterface mangling detection fails for PathScale (pathf95) Description: In PathScale, the following code: module modname contains subroutine subname() end subroutine subname end module modname produces the following symbols: 0001 T modname_ T SUBNAME.in.MODNAME The current code at "# Construct mangling macro definitions." at Modules/FortranCInterface/Detect.cmake doesn't handle neither the ".in." part - nor the reversed order of procedure name and module name. == Issue History Date ModifiedUsername FieldChange == 2012-12-14 07:05 tobias 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 0013796]: Regression: Toolchain file including CMakeDetermineSystem no longer works
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13796 == Reported By:raspy Assigned To: == Project:CMake Issue ID: 13796 Category: CMake Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 2012-12-14 08:55 EST Last Modified: 2012-12-14 08:55 EST == Summary:Regression: Toolchain file including CMakeDetermineSystem no longer works Description: In CMake 2.8.10 there was a change introduced: http://cmake.org/gitweb?p=cmake.git;a=commit;h=7195aca54f40778f41894c9e62649afe09e71d6c. As a part of this change location of CMakeSystem.cmake generated file was changed (http://cmake.org/gitweb?p=cmake.git;a=blobdiff;f=Modules/CMakeDetermineSystem.cmake;h=cd33447560e12ac473d57ec5ad7784f7c5a1f861;hp=22c5016146bba896b8bbcb76458d420bd74c81b9;hb=7195aca54f40778f41894c9e62649afe09e71d6c;hpb=ec22a9b5217c2110db9af1791a61a7552144f028) When the project is configured, it runs CMakeDetermineSystem which creates CMakeSystem.cmake. We use CMAKE_TOOLCHAIN_FILE which is included by CMakeDetermineSystem and its path is also written in CMakeSystem.cmake. Then the compiler is tested; it is done by creating temporary CMake subproject to try to compile a sample file. Issue is: in that subproject CMAKE_TOOLCHAIN_FILE is not set, but it includes CMakeSystem.cmake. Our toolchain file includes CMakeDetermineSystem which in turn overwrites CMakeSystem.cmake WITHOUT toolchain file location. Therefore, when CMake is run next time it does not include toolchain file and compiler's include location is not known. The issue was not previously observed because CMakeSystem.cmake created by temporary TryCompile subproject was created in temporary subproject's directory. Now it is the same location for main project and subprojects and is being overwritten. Steps to Reproduce: Use the following CMakeLists.txt: SET(CMAKE_TOOLCHAIN_FILE toolchain.cmake) PROJECT(test C CXX ASM) ADD_LIBRARY(test foo.c) toolchain.cmake: INCLUDE_DIRECTORIES(include_dir) IF(NOT CMAKE_HOST_SYSTEM_NAME) INCLUDE(CMakeDetermineSystem) ENDIF(NOT CMAKE_HOST_SYSTEM_NAME) 1. Run CMake 2.8.10.2. Check CMakeFiles/2.8.10.2/CMakeSystem.cmake does not contain line including toolchain file. 2. Run make VERBOSE=1. Note that -Iinclude_dir is provided (because it was cached from CMakeDetermineSystem). 3. Run CMake 2.8.10.2 again. Note that compiler settings are read from cache and CMakeDetermineSystem is not called, but rather generated CMakeSystem.cmake is included. As it lacks toolchain file include, toolchain file is not included and INCLUDE_DIRECTORIES command is missing. 4. Run make VERBOSE=1 again. Note that -Iinclude_dir is now missing from compilation line. Additional Information: This particular change http://cmake.org/gitweb?p=cmake.git;a=blobdiff;f=Modules/CMakeDetermineSystem.cmake;h=cd33447560e12ac473d57ec5ad7784f7c5a1f861;hp=22c5016146bba896b8bbcb76458d420bd74c81b9;hb=7195aca54f40778f41894c9e62649afe09e71d6c;hpb=ec22a9b5217c2110db9af1791a61a7552144f028 introduced regression. CMake up to 2.8.9 works with such toolchain file correctly (because CMakeSystem.cmake is generated in CMakeFiles/ and CMakeFiles/CMakeTmp/CMakeFiles separately). After the change they both use the same file location and the file gets overwritten once compiler tests are run. I would suggest to export CMAKE_TOOLCHAIN_FILE for test subprojects, so that at least CMakeDetermineSystem generates the same CMakeSystem.cmake file. == Issue History Date ModifiedUsername FieldChange == 2012-12-14 08:55 raspy 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 0013797]: get_property(... TARGET project PROPERTY LOCATION returns incorrect value
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=13797
==
Reported By:Richard Bateman
Assigned To:
==
Project:CMake
Issue ID: 13797
Category: CMake
Reproducibility:always
Severity: major
Priority: high
Status: new
==
Date Submitted: 2012-12-14 13:48 EST
Last Modified: 2012-12-14 13:48 EST
==
Summary:get_property(... TARGET project PROPERTY LOCATION
returns incorrect value
Description:
Starting with cmake 2.8.10 when I use:
get_property(LIBDIR TARGET ${PROJNAME} PROPERTY LOCATION)
I now get /path/to/libGCPlugin.so.plugin/Contents/MacOS/libGCPlugin.so
I should get /path/to/GCPlugin.plugin/Contents/MacOS/GCPLugin
I don't know what changed;
Steps to Reproduce:
There is a test in the cmake source that should be able to reproduce it; if it's
not a simple thing to see what happened I can help track it down.
Basically create a library:
add_library(somePlugin MODULE ${SOURCES})
set_target_properties(somePlugin PROPERTIES
OUTPUT_NAME somePlugin
BUNDLE 1
BUNDLE_EXTENSION plugin
XCODE_ATTRIBUTE_WRAPPER_EXTENSION plugin #sets the extension to .plugin
XCODE_ATTRIBUTE_MACH_O_TYPE mh_bundle
XCODE_ATTRIBUTE_INFOPLIST_FILE
${CMAKE_CURRENT_BINARY_DIR}/bundle/Info.plist
MACOSX_BUNDLE_INFO_PLIST ${CMAKE_CURRENT_BINARY_DIR}/bundle/Info.plist)
Then do:
get_property(LIBDIR TARGET somePlugin PROPERTY LOCATION)
message("Lib dir: ${LIBDIR}")
Additional Information:
This is really easy to reproduce with a firebreath plugin; I can upload a test
project that you could play with with firebreath if you wanted to try it that
way. I am also willing to help if you can give me an idea where to look. I am
willing to help if it is needed.
==
Issue History
Date ModifiedUsername FieldChange
==
2012-12-14 13:48 Richard BatemanNew 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 0013798]: CMake Fails to build makefiles
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13798 == Reported By:CharlesH Assigned To: == Project:CMake Issue ID: 13798 Category: CMake Reproducibility:always Severity: major Priority: urgent Status: new == Date Submitted: 2012-12-16 00:24 EST Last Modified: 2012-12-16 00:24 EST == Summary:CMake Fails to build makefiles Description: I was attempting to build Allegro 5 and got this error message: It fails with the following output: Change Dir: /Users/hardnett/Downloads/allegro/build/CMakeFiles/CMakeTmp Run Build Command:/usr/bin/make "cmTryCompileExec1015337934/fast" /usr/bin/make -f CMakeFiles/cmTryCompileExec1015337934.dir/build.make CMakeFiles/cmTryCompileExec1015337934.dir/build "/Applications/CMake 2.8-10.app/Contents/bin/cmake" -E cmake_progress_report /Users/hardnett/Downloads/allegro/build/CMakeFiles/CMakeTmp/CMakeFiles 1 Building C object CMakeFiles/cmTryCompileExec1015337934.dir/testCCompiler.c.o /usr/bin/gcc -isysroot /Developer/SDKs/MacOSX10.6.sdk -o CMakeFiles/cmTryCompileExec1015337934.dir/testCCompiler.c.o -c /Users/hardnett/Downloads/allegro/build/CMakeFiles/CMakeTmp/testCCompiler.c Linking C executable cmTryCompileExec1015337934 "/Applications/CMake 2.8-10.app/Contents/bin/cmake" -E cmake_link_script CMakeFiles/cmTryCompileExec1015337934.dir/link.txt --verbose=1 /usr/bin/gcc -isysroot /Developer/SDKs/MacOSX10.6.sdk -Wl,-search_paths_first -Wl,-headerpad_max_install_names CMakeFiles/cmTryCompileExec1015337934.dir/testCCompiler.c.o -o cmTryCompileExec1015337934 ld: library not found for -lcrt1.10.6.o collect2: ld returned 1 exit status make[1]: *** [cmTryCompileExec1015337934] Error 1 make: *** [cmTryCompileExec1015337934/fast] Error 2 I then tried a stripped down version of CMakeLists.txt and got the same error: /usr/bin/make -f CMakeFiles/cmTryCompileExec4200036634.dir/build.make CMakeFiles/cmTryCompileExec4200036634.dir/build "/Applications/CMake 2.8-10.app/Contents/bin/cmake" -E cmake_progress_report /Users/hardnett/Downloads/cmake/build/CMakeFiles/CMakeTmp/CMakeFiles 1 Building C object CMakeFiles/cmTryCompileExec4200036634.dir/testCCompiler.c.o /usr/bin/gcc -isysroot /Developer/SDKs/MacOSX10.6.sdk -o CMakeFiles/cmTryCompileExec4200036634.dir/testCCompiler.c.o -c /Users/hardnett/Downloads/cmake/build/CMakeFiles/CMakeTmp/testCCompiler.c Linking C executable cmTryCompileExec4200036634 "/Applications/CMake 2.8-10.app/Contents/bin/cmake" -E cmake_link_script CMakeFiles/cmTryCompileExec4200036634.dir/link.txt --verbose=1 /usr/bin/gcc -isysroot /Developer/SDKs/MacOSX10.6.sdk -Wl,-search_paths_first -Wl,-headerpad_max_install_names CMakeFiles/cmTryCompileExec4200036634.dir/testCCompiler.c.o -o cmTryCompileExec4200036634 ld: library not found for -lcrt1.10.6.o collect2: ld returned 1 exit status make[1]: *** [cmTryCompileExec4200036634] Error 1 make: *** [cmTryCompileExec4200036634/fast] Error 2 CMake will not be able to correctly generate this project. Call Stack (most recent call first): CMakeLists.txt:3 (PROJECT) -- Configuring incomplete, errors occurred! Steps to Reproduce: You can reproduce this with the attached CMakeLists.txt file and main.c file: 1. unzip into a folder 2. type "cmake ." or you can: 1. unzip into a folder 2. cd build 3. cmake .. == Issue History Date ModifiedUsername FieldChange == 2012-12-16 00:24 CharlesH New Issue 2012-12-16 00:24 CharlesH File Added: cmake.zip == -- 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 0013799]: Optionally disable build order dependency target_link_libraries
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=13799 == Reported By:Christian Rorvik Assigned To: == Project:CMake Issue ID: 13799 Category: CMake Reproducibility:always Severity: feature Priority: normal Status: new == Date Submitted: 2012-12-16 09:00 EST Last Modified: 2012-12-16 09:00 EST == Summary:Optionally disable build order dependency target_link_libraries Description: target_link_libraries adds transitive link dependencies and build order dependencies between the target and its dependencies. In many (if not most) cases the build order dependency is not necessary and results in an overlay constrained dependency graph, which limits parallel execution of the build. Short of discarding transitive link dependencies and maintain all dependencies in each final target, I haven't found a CMake script workaround for this problem. I tried soliciting some feedback over the CMake mailing list earlier this year, without any response: http://www.cmake.org/pipermail/cmake/2012-July/051351.html I found modifying the source to not add these build order dependencies for static libraries was easy enough, and I was hoping there would be some interest in finding some way of adopting this feature into the product. == Issue History Date ModifiedUsername FieldChange == 2012-12-16 09:00 Christian RorvikNew 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 0013800]: Only one directory taken into account (CMAKE_FIND_ROOT_PATH)
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13800 == Reported By:Jonathan De Wachter Assigned To: == Project:CMake Issue ID: 13800 Category: CMake Reproducibility:always Severity: major Priority: high Status: new == Date Submitted: 2012-12-17 06:28 EST Last Modified: 2012-12-17 06:28 EST == Summary:Only one directory taken into account (CMAKE_FIND_ROOT_PATH) Description: CMake doesn't search at *all* path defined by CMAKE_FIND_ROOT_PATH (at least for headers include). I can get my headers found for the first path defined but the second, the third... it doesn't work. My scenario is a compiler split and located at different location (you'll find some headers and libraries located in several external directories). This is the case for Android compilers provided by the NDK which include the STL library version according: - the Android API you are targeting - the compiler brand/version. This is the main compiler directory: $NDK/toolchains/arm-compiler/bin/ $NDK/toolchains/arm-compiler/include/ This is an external directory including some headers and libraries: $NDK/platforms/android-9/include $NDK/platforms/android-14/include This is another external directory including several STL versions: $NDK/sources/cxx-stl/gnu-libstdc++/4.6/ $NDK/sources/cxx-stl/gnu-libstdc++/4.4.3/ $NDK/sources/cxx-stl/stlport/stlport/ The goal is pick up the right headers/libraries and so make a customized compiler suitable for the targeted mobile and the targeted os. Additional Information: I know I actually should use a script which generates a standalone compiler with all headers/libraries at a same location. But I don't want that. == Issue History Date ModifiedUsername FieldChange == 2012-12-17 06:28 Jonathan De WachterNew 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 0013802]: set_property doesn't work for CMAKE_XCODE_ATTRIBUTE_
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=13802
==
Reported By:tzeH
Assigned To:
==
Project:CMake
Issue ID: 13802
Category: CMake
Reproducibility:always
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2012-12-19 07:21 EST
Last Modified: 2012-12-19 07:21 EST
==
Summary:set_property doesn't work for CMAKE_XCODE_ATTRIBUTE_
Description:
These two things don't do the same although they should:
set(CMAKE_XCODE_ATTRIBUTE_GCC_VERSION "com.apple.compilers.llvmgcc42")
set_property(GLOBAL PROPERTY CMAKE_XCODE_ATTRIBUTE_GCC_VERSION
"com.apple.compilers.llvmgcc42")
The first line works, the second line doesn't.
Additional Information:
The code for this is in cmGlobalXCodeGenerator.cxx:
void cmGlobalXCodeGenerator::CreateBuildSettings(cmTarget& target,
cmXCodeObject* buildSettings,
const char* configName)
{
...
cmPropertyMap const& props = target.GetProperties();
for(cmPropertyMap::const_iterator i = props.begin(); i != props.end(); ++i)
{
if(i->first.find("XCODE_ATTRIBUTE_") == 0)
{
buildSettings->AddAttribute(i->first.substr(16).c_str(),
this->CreateString(i->second.GetValue()));
}
}
...
}
I don't know enough about the objects and classes involved, but it seems there
is something wrong here and I hope this pointer will help to fix it.
==
Issue History
Date ModifiedUsername FieldChange
==
2012-12-19 07:21 tzeH 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 0013803]: cmake generates RFC_FILE with back slashes for ninja
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=13803 == Reported By:Michael Rolnik Assigned To: == Project:CMake Issue ID: 13803 Category: CMake Reproducibility:always Severity: major Priority: high Status: new == Date Submitted: 2012-12-19 10:31 EST Last Modified: 2012-12-19 10:31 EST == Summary:cmake generates RFC_FILE with back slashes for ninja Description: CMake when generating ninja build system creates C_STATIC_LIBRARY_LINKER_RSP_FILE variable with backslashes. ar does not know how to handle backslashes. the build fails. Steps to Reproduce: - create OBJECT library - create a library out of it == Issue History Date ModifiedUsername FieldChange == 2012-12-19 10:31 Michael Rolnik 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 0013804]: CTest Debug CTestGTMCoverage (cmParseGTMCoverage.cxx): *hangs*, with out-of-bounds exception dialog on XINDEX.m
The following issue has been SUBMITTED.
==
http://www.itk.org/Bug/view.php?id=13804
==
Reported By:Andreas Mohr
Assigned To:
==
Project:CMake
Issue ID: 13804
Category: CTest
Reproducibility:have not tried
Severity: major
Priority: high
Status: new
==
Date Submitted: 2012-12-19 11:39 EST
Last Modified: 2012-12-19 11:39 EST
==
Summary:CTest Debug CTestGTMCoverage
(cmParseGTMCoverage.cxx): *hangs*, with out-of-bounds exception dialog on
XINDEX.m
Description:
Attempted executing a manually built ctest (Debug config) on git master,
MSVS10 10.0.40219.1 SP1Rel.
Progressed up to test 153/262 (CTestGTMCoverage).
Tests processing then hung with an out-of-bounds exception.
FindFunctionInMumpsFile() called with the following context:
filepath XINDEX.m
function "Q"
lineoffset currently 120
linenum currently 19
line " Q"
entered pos == 1 branch, there:
prevchar 32 (' ')
line[function.size()+1] is INVALID since line.size() is 2 (capacity() 127).
Probably the " Q" line *is* a valid candidate for locating this function,
so the evaluation here is both out-of-bounds and not sufficient since it
*should* return true in case this line is a valid candidate. But I'm not MUMPS
experienced by any stretch.
Severity major, prio high since it causes ongoing test processing to break, hard
(not that myself I'd care all too much, locally... ;).
Thanks!
==
Issue History
Date ModifiedUsername FieldChange
==
2012-12-19 11:39 Andreas Mohr 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 0013805]: Add support for CPACK_PACKAGE_RELOCATABLE to NSIS Generator
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13805 == Reported By:Andrew Bott Assigned To: == Project:CMake Issue ID: 13805 Category: (No Category) Reproducibility:have not tried Severity: minor Priority: normal Status: new == Date Submitted: 2012-12-19 22:51 EST Last Modified: 2012-12-19 22:51 EST == Summary:Add support for CPACK_PACKAGE_RELOCATABLE to NSIS Generator Description: I have a need for generating an NSIS installer that doesn't allow the user to select the install directory (Forces use of default). I expected this to be controlled by the CPACK_PACKAGE_RELOCATABLE variable, but found that this was not the case. Whilst relocatability should probably be ON by default for the NSIS generator, I'd like it to be configurable e.g.: Somewhere in NSIS.template.in: @CPACK_NSIS_PAGE_DIRECTORY@ And somewhere else: IF( CPACK_PACKAGE_RELOCATABLE ) SET( CPACK_NSIS_PAGE_DIRECTORY "!insertmacro MUI_PAGE_DIRECTORY" ) ENDIF Steps to Reproduce: Trivially reproducable == Issue History Date ModifiedUsername FieldChange == 2012-12-19 22:51 Andrew BottNew 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 0013806]: list(SORT) produces unavoidable data corruption (likely root cause: improper semi-colon string *payload* handling in CMake)
The following issue has been SUBMITTED.
==
http://www.itk.org/Bug/view.php?id=13806
==
Reported By:Andreas Mohr
Assigned To:
==
Project:CMake
Issue ID: 13806
Category: CMake
Reproducibility:always
Severity: major
Priority: urgent
Status: new
==
Date Submitted: 2012-12-20 08:52 EST
Last Modified: 2012-12-20 08:52 EST
==
Summary:list(SORT) produces unavoidable data corruption
(likely root cause: improper semi-colon string *payload* handling in CMake)
Description:
I just wanted to extend a test case for my work on a new ENVIRONMENT option to
add_custom_command() (adding many "interesting" env var key/value tests for
escaping of XML, batch, shell, ... specials),
and ended up realizing that any escaped semi-colon string content will end up
getting broken, hard, by CMake.
The test provided below will produce the following output:
$ cmake .
tlist pre-sort:
hi;there
cruel;world
tlist post-sort:
cruel
world
hi
there
extra_escaped_list pre-sort:
hi;there
cruel;world
extra_escaped_list post-sort:
cruel
world
hi
there
extra_escaped_list_i_mean_it pre-sort:
hi\\
there
cruel\\
world
extra_escaped_list_i_mean_it post-sort:
cruel\\
hi\\
there
world
-- Configuring done
-- Generating done
This shows that any SORT of the list will cause unsurviveable data corruption,
which is a major, INSURMOUNTABLE problem (as the futile attempts at
backslash-escaping in the test case below illustrate) when attempting to compile
a list of patterns for escape tests towards rather unrelated system components.
This wide-spread data corruption by CMake core layers should be fixed quickly
(we're now at 2.8.x, finally having reached good usability on the very large
number of systems that CMake supports, where I really wouldn't have expected
such data corruption issues to have remained).
I'd deem data corruption bugs to be of the near-highest level on the priority
scale (with perhaps actual security issues topping it), thereby assigning
priority urgent.
(I did read "[sldev] Semicolons and CMake"
https://lists.secondlife.com/pipermail/sldev/2009-April/013502.html , and have
to admit I walked away unconvinced)
This should possibly be handled by introducing a new case to the CMake policy
mechanism, to preserve the (reportedly quite important in this case) bug-for-bug
compat in older code.
If it isn't possible to fix this problem cleanly (or e.g. not in a single
evolution step), then one should think of other possibilities to be able to work
around the currently unavoidable data corruption. One way might be to introduce
a special CMAKE_ESCAPE_* variable which when inserted marks content in a special
manner to ensure proper handling.
Or possibly one could add new cmake_escape_*() function helpers rather than
resorting to often unclean global-variable-based handling.
Thanks!
Steps to Reproduce:
cmake_minimum_required(VERSION 2.8)
project(list_escape_semicolon_test NONE)
function(show_list _title _list)
message("${_title}:")
foreach(elem_ ${_list})
message("${elem_}")
endforeach(elem_ ${_list})
message("")
endfunction(show_list _title _list)
function(process_list _name _list)
show_list("${_name} pre-sort" "${_list}")
list(SORT _list)
show_list("${_name} post-sort" "${_list}")
endfunction(process_list _name _list)
function(test_list_sort_escaping)
set(tlist "")
list(APPEND tlist "hi\;there")
list(APPEND tlist "cruel\;world")
process_list(tlist "${tlist}")
set(tlist "")
list(APPEND tlist "hi\\;there")
list(APPEND tlist "cruel\\;world")
process_list(extra_escaped_list "${tlist}")
set(escape_string "")
set(tlist "")
list(APPEND tlist "hi${escape_string};there")
list(APPEND tlist "cruel${escape_string};world")
process_list(extra_escaped_list_i_mean_it "${tlist}")
endfunction(test_list_sort_escaping)
test_list_sort_escaping()
Additional Information:
That's now the second (and unrelated) time in about two weeks that I stumbled
(and fell) over this (the first time being reading in a file(STRINGS) with
semi-colon payload and iterating over elements of the resulting list).
==
Issue History
Date ModifiedUsername FieldChange
==
2012-12-20 08:52 Andreas Mohr New Issue
==
[cmake-developers] [CMake 0013807]: FLTK_WRAP_UI erroneous error message
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=13807 == Reported By:Nicholas Rishel Assigned To: == Project:CMake Issue ID: 13807 Category: CMake Reproducibility:always Severity: trivial Priority: low Status: new == Date Submitted: 2012-12-21 04:30 EST Last Modified: 2012-12-21 04:30 EST == Summary:FLTK_WRAP_UI erroneous error message Description: CMake outputs the following error message when using FLTK_WRAP_UI FLTK_WRAP_UI was called with a target that was never created: UI. The problem was found while processing the source directory: /CS_334. This FLTK_WRAP_UI call will be ignored. In testing, I found that commenting out this function causes build errors, suggesting to me that this error is incorrectly popping up. In addition, I find that changes to the FLUID file correctly propagate to the program even though this error is flagged. Steps to Reproduce: Extract attached project. In CMake, Configure the project. The following error occurs in the configure process. FLTK_WRAP_UI was called with a target that was never created: UI. The problem was found while processing the source directory: /CS_334. This FLTK_WRAP_UI call will be ignored. == Issue History Date ModifiedUsername FieldChange == 2012-12-21 04:30 Nicholas RishelNew Issue 2012-12-21 04:30 Nicholas RishelFile Added: fltk_wrap_ui error.7z == -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0013808]: Please add 64-Bit ARM endianness defines to cmake
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=13808 == Reported By:Riku Voipio Assigned To: == Project:CMake Issue ID: 13808 Category: CCMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2012-12-21 07:57 EST Last Modified: 2012-12-21 07:57 EST == Summary:Please add 64-Bit ARM endianness defines to cmake Description: When building for 64-Buit ARM (officially known as Aarch64), cmake will fail to build due unknown byte order. In file included from /data/oe/build/tmp-eglibc/work/aarch64-oe-linux/cmake/2.8.10.1-r0.0/cmake-2.8.10.1/Utilities/KWIML/test/test_ABI_C.c:13:0: /data/oe/build/tmp-eglibc/work/aarch64-oe-linux/cmake/2.8.10.1-r0.0/cmake-2.8.10.1/Utilities/cmIML/ABI.h:419:3: error: #error "Byte order of target CPU unknown." With the attached patch, cmake tests pass on the ARMv8 Foundation model simulator. Steps to Reproduce: mkdir oe cd oe git clone git://git.linaro.org/openembedded/meta-aarch64.git # the last commit has already the attached patch, so rewind from head git checkout 54d06ed77b0cc11ac1e260ee0ab9751f9ed2c4ed # this will clone and install a lot of stuff - debian/ubuntu expected. bash meta-aarch64/scripts/init.sh cd openembedded-core . oe-init-build-env ../build bitbake cmake The bitbake command will take a long while, as it will compile the crosscompiler and all tools first. This instruction is based upon the following page: https://wiki.linaro.org/HowTo/ARMv8/OpenEmbedded == Issue History Date ModifiedUsername FieldChange == 2012-12-21 07:57 Riku VoipioNew Issue 2012-12-21 07:57 Riku VoipioFile Added: 0001-Add-Aarch64-support.patch == -- 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 0013809]: add_dependencies and --graphviz
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=13809 == Reported By:Vassil Vassilev Assigned To: == Project:CMake Issue ID: 13809 Category: CMake Reproducibility:always Severity: feature Priority: normal Status: new == Date Submitted: 2012-12-21 09:04 EST Last Modified: 2012-12-21 09:04 EST == Summary:add_dependencies and --graphviz Description: Hi, I am using cmake in the context of C# and I don't use add_library or add_executable but I have my own functions that do that trick. I resolve the dependencies between the libraries (since have my home-grown csharp_add_library) using add_dependencies. Using that however doesn't allow me to print the dependencies between the targets, which is something IMO natural to expect. Am I doing something wrong in general or somebody just has to teach cmGraphVizWriter to react on cmTarget::UTILITY? If that is the case I can propose the attached patch. Cheers, Vassil PS1: Note that I am newbie (I've started using cmake 3 days ago). PS2: I had hard time building cmake sources in debug mode. Why there is no ./bootstrap --enable-debug switch? Steps to Reproduce: 1. add_custom_target(... libA ...) 2. add_custom_target(... libB ...) 3. add_dependencies(libA libB) 4. cmake --graphviz=file.dot path_to_some_source == Issue History Date ModifiedUsername FieldChange == 2012-12-21 09:04 Vassil VassilevNew Issue 2012-12-21 09:04 Vassil VassilevFile Added: cmGraphVizWriterPlusUtility.diff == -- 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 0013810]: Confusing documentation for GET_CMAKE_PROPERTY
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13810 == Reported By:David Golub Assigned To: == Project:CMake Issue ID: 13810 Category: Documentation Reproducibility:N/A Severity: minor Priority: normal Status: new == Date Submitted: 2012-12-22 11:19 EST Last Modified: 2012-12-22 11:19 EST == Summary:Confusing documentation for GET_CMAKE_PROPERTY Description: The documentation for GET_CMAKE_PROPERTY lists the properties VARIABLES, CACHE_VARIABLES, COMMANDS, MACROS, and COMPONENTS as able to be obtained using this command. However, in the properties help file, these properties are only listed under properties for help files. Furthermore, the GET_CMAKE_PROPERTY command can be used to obtain properties listed as being of global scope, but there is nothing said to indicate so in its documentation. This should all be clarified. == Issue History Date ModifiedUsername FieldChange == 2012-12-22 11:19 David GolubNew 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 0013811]: No Start menu icon for CMake variables help
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13811 == Reported By:David Golub Assigned To: == Project:CMake Issue ID: 13811 Category: CMakeSetup Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2012-12-22 11:22 EST Last Modified: 2012-12-22 11:22 EST == Summary:No Start menu icon for CMake variables help Description: The installer for CMake creates an icon on the start menu called "CMake Properties and Variables Help" that opens the help page for CMake properties only. There is no icon to open the help page for CMake variables. == Issue History Date ModifiedUsername FieldChange == 2012-12-22 11:22 David GolubNew 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 0013812]: NSIS: Custom install path was not considered during uninstallation.
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13812 == Reported By:Kolan Sh Assigned To: == Project:CMake Issue ID: 13812 Category: CPack Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2012-12-24 06:31 EST Last Modified: 2012-12-24 06:31 EST == Summary:NSIS: Custom install path was not considered during uninstallation. Description: When CPACK_NSIS_ENABLE_UNINSTALL_BEFORE_INSTALL CPack variable set to ON the user see dialogue "the package is already installed. Do you want to uninstall the old version before installing the new one?" Answering "Yes" the user sees dialogue with a default installation path instead of a path where the application is installed. Steps to Reproduce: 1. Create package with "SET (CPACK_NSIS_ENABLE_UNINSTALL_BEFORE_INSTALL ON)" and "SET (CPACK_NSIS_MODIFY_PATH ON)". 2. Set custom install installation path during installation. 3. Run installer again, confirm uninstallation and look for uninstallation path. == Issue History Date ModifiedUsername FieldChange == 2012-12-24 06:31 Kolan Sh New Issue 2012-12-24 06:31 Kolan Sh File Added: 0001-NSIS-Custom-install-path-was-not-considered-during-u.patch == -- 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 0013813]: CMAKE_SIZEOF_VOID_P undefined
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=13813 == Reported By:Kobi Gurkan Assigned To: == Project:CMake Issue ID: 13813 Category: CMake Reproducibility:always Severity: major Priority: low Status: new == Date Submitted: 2012-12-26 10:09 EST Last Modified: 2012-12-26 10:09 EST == Summary:CMAKE_SIZEOF_VOID_P undefined Description: This is similar to 0013526. The error I have is about CMake not being able to determine bitness of the platform. Digging, I found it's related to CMAKE_SIZEOF_VOID_P being undefined. Reading the discussion in 0013526, I tried reinstalling my OS and VS 2012, and it worked. I don't think the correct solution to this problem should be "reinstall, and it might work". I'd like to debug it and help find a solution. Does anyone have an idea where to start? == Issue History Date ModifiedUsername FieldChange == 2012-12-26 10:09 Kobi GurkanNew 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 0013814]: SWIG C# generates a DllImport line that doesn't match the library name
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=13814
==
Reported By:Matt Williams
Assigned To:
==
Project:CMake
Issue ID: 13814
Category: CMake
Reproducibility:always
Severity: major
Priority: normal
Status: new
==
Date Submitted: 2012-12-26 11:51 EST
Last Modified: 2012-12-26 11:51 EST
==
Summary:SWIG C# generates a DllImport line that doesn't
match the library name
Description:
When creating C# bindings with UseSWIG like:
swig_add_module(MyModuleCSharp csharp MyModule.i)
then SWIG will generate code containing
[DllImport("MyModule", EntryPoint="...")]
but the library name generated by CMake will be something like
libMyModuleCSharp.so (note the 'CSharp' suffix). This causes the generated
bindings to crash unless the library and module names just happen to match.
SWIG provides an argument to set the DllImport name to something else. By
passing "-dllimport MyModuleCSharp" the DllImport line will contain the correct
library name.
[DllImport("MyModuleCSharp", EntryPoint="...")]
Attached is a patch which implements this inside SWIG_MODULE_INITIALIZE.
==
Issue History
Date ModifiedUsername FieldChange
==
2012-12-26 11:51 Matt Williams New Issue
2012-12-26 11:51 Matt Williams File Added: swig_csharp_dllimport.patch
==
--
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 0013815]: CMake uses compiler settings under CMakeFiles without verifying that they match the current generator.
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=13815
==
Reported By:Stephen McCracken
Assigned To:
==
Project:CMake
Issue ID: 13815
Category: CMake
Reproducibility:always
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2012-12-26 19:10 EST
Last Modified: 2012-12-26 19:10 EST
==
Summary:CMake uses compiler settings under CMakeFiles
without verifying that they match the current generator.
Description:
The first time you run CMake in a clean directory, the enable_language(C) and
enable_language(CXX) commands test the compilers for the currently-selected
generator (say 32-bit Visual Studio 11) and caches the results in the files
CMakeFiles/CMakeCCompiler.cmake and CMakeFiles/CMakeCXXCompiler.cmake.
If you then delete CMakeCache.txt and switch the generator to 64-bit Visual
Studio 11 Win64, CMake will not re-test the compiler, and it will proceed with
the incorrect cached results for the old (32-bit) generator.
This behavior can be very confusing when debugging CMake errors. In my case,
find_package( PythonLibs 2.7 ) was failing because I was trying to use a 64-bit
Python 2.7.3 installation with the 32-bit Visual Studio 11 generator. However,
when I switched to 64-bit and deleted CMakeCache.txt (but not the CMakeFiles
directory), PythonLibs still was not found because CMake was reading
CMAKE_SIZEOF_VOID_P=4 from the CMakeFiles directory, which make it look for
32-bit registry settings for the Python installation directory.
Steps to Reproduce:
1) Create a simple CMakeLists.txt file with the following 2 lines:
enable_language( CXX )
message( STATUS "CMAKE_SIZEOF_VOID_P=${CMAKE_SIZEOF_VOID_P}" )
2) Run cmake-gui with the Visual Studio 11 generator, and observe the output:
CMAKE_SIZEOF_VOID_P=4
3) Delete the CMakeCache.txt file.
4) Run cmake-gui again from the same directory, but choose the Visual Studio 11
Win64 generator. Observe the incorrect output value:
CMAKE_SIZEOF_VOID_P=4
==
Issue History
Date ModifiedUsername FieldChange
==
2012-12-26 19:10 Stephen McCrackenNew 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 0013816]: Ninja Generator ignores source file property MACOSX_PACKAGE_LOCATION
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13816 == Reported By:stephan Aiche Assigned To: == Project:CMake Issue ID: 13816 Category: CMake Reproducibility:always Severity: major Priority: high Status: new == Date Submitted: 2012-12-27 05:34 EST Last Modified: 2012-12-27 05:34 EST == Summary:Ninja Generator ignores source file property MACOSX_PACKAGE_LOCATION Description: The ninja generator ignores the MACOSX_PACKAGE_LOCATION source file property (e.g., to copy the icon file into the app bundle). If you compile the same project with the Makefile Generator the resources gets correctly copied. Steps to Reproduce: See attached project (requires Qt to build the GUI). * build with the ninja generator * build with the Makefile generator == Issue History Date ModifiedUsername FieldChange == 2012-12-27 05:34 stephan Aiche New Issue 2012-12-27 05:34 stephan Aiche File Added: ninja_bug.zip == -- 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 0013817]: Can't export tests to XML without reporting to CDash
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13817 == Reported By:Keith Gardner Assigned To: == Project:CMake Issue ID: 13817 Category: CTest Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2012-12-27 11:57 EST Last Modified: 2012-12-27 11:57 EST == Summary:Can't export tests to XML without reporting to CDash Description: I would like to be able to export the results of the tests to an XML file with out submitting it to a dashboard. I use TeamCity for my automated regression tests server and it has the ability to load in the XML file exported by CTest. The problem is that I am having build errors when running tests because it is trying to submit the file to a server that does not exist. The executable closes with a non 0 exit code. Steps to Reproduce: ctest -D Experimental Don't provide any CTEST_DROP_* information. == Issue History Date ModifiedUsername FieldChange == 2012-12-27 11:57 Keith Gardner 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 0013818]: FindPythonInterp finds a cygwin symlink which can't be used with execute_process
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=13818
==
Reported By:Reid Kleckner
Assigned To:
==
Project:CMake
Issue ID: 13818
Category: Modules
Reproducibility:always
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2012-12-28 15:04 EST
Last Modified: 2012-12-28 15:04 EST
==
Summary:FindPythonInterp finds a cygwin symlink which can't
be used with execute_process
Description:
I'm using native Windows CMake from a Cygwin shell, so Cygwin Python is on my
PATH. My /usr/bin looks like:
$ ll /usr/bin/python*
lrwxrwxrwx 1 rnk Domain Users 13 Aug 20 18:35 /usr/bin/python -> python2.6.exe
-rwxr-xr-x 1 rnk Domain Users 4622 Jun 9 2012 /usr/bin/python2.6.exe
-rwxr-xr-x 1 rnk Domain Users 1419 Jun 9 2012 /usr/bin/python2.6-config
lrwxrwxrwx 1 rnk Domain Users 16 Aug 20 18:35 /usr/bin/python-config ->
python2.6-config
FindPythonInterp.cmake uses find_program() with "python" first, which succeeds.
This is a reasonable result to return, but then execute_process fails on the
Cygwin symlink file. It doesn't seem reasonable for native Windows CMake to
know how to follow Cygwin symlinks, so maybe find_program should fail on such
symlinks, or FindPythonInterp should test that it can actually execute the
python executable, and fall back to its version based queries.
As a workaround, it's pretty easy for me to point it at the right executable.
Steps to Reproduce:
Install or build native Windows CMake
In a Cygwin shell, run cmake on this script:
include(FindPythonInterp)
if( NOT PYTHONINTERP_FOUND )
message(FATAL_ERROR "can't find python")
endif ()
execute_process(
COMMAND ${PYTHON_EXECUTABLE} -c "print \"hello\"" RESULT_VARIABLE result)
if (NOT "${result}" STREQUAL "0")
message(FATAL_ERROR "PYTHON_EXECUTABLE failed, is it a symlink?")
endif ()
==
Issue History
Date ModifiedUsername FieldChange
==
2012-12-28 15:04 Reid Kleckner 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 0013819]: findSDL_image.cmake is failing - Regression from CMake 2.8.9
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13819 == Reported By:Chris Assigned To: == Project:CMake Issue ID: 13819 Category: CMake Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 2012-12-29 00:12 EST Last Modified: 2012-12-29 00:12 EST == Summary:findSDL_image.cmake is failing - Regression from CMake 2.8.9 Description: findSDL_image.cmake is failing when using SDLDIR environment variable to define the path where SDL and SDL_image are located. this appears to be a regression from 2.8.9 since uninstalling 2.8.10.2 and installing 2.8.9 resolves the issue for me. Steps to Reproduce: Set environment variable pointing to your SDL/SDL_image installation. for example: /bin /include /lib add "Find_Package ( SDL_image REQUIRED )" to a CMakeLists.txt and it will fail == Issue History Date ModifiedUsername FieldChange == 2012-12-29 00:12 Chris 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 0013820]: ccmake GUI is messed up after installing GNU ncurses library
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=13820 == Reported By:danielyang Assigned To: == Project:CMake Issue ID: 13820 Category: CCMake Reproducibility:always Severity: major Priority: high Status: new == Date Submitted: 2012-12-29 01:41 EST Last Modified: 2012-12-29 01:41 EST == Summary:ccmake GUI is messed up after installing GNU ncurses library Description: Apparently, ccmake uses curses and there's something wrong with the default curses library in CentOS. After my installation of GNU ncurses, everything curses-based (e.g., screen, htop, mc) looks perfect, but now ccmake GUI is totally messed up (it won't refresh the screen properly). Steps to Reproduce: install ncurses 5.9 run ccmake == Issue History Date ModifiedUsername FieldChange == 2012-12-29 01:41 danielyang 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 0013822]: Crash when using LibFindMacros
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=13822 == Reported By:Matt Arsenault Assigned To: == Project:CMake Issue ID: 13822 Category: CMake Reproducibility:always Severity: crash Priority: normal Status: new == Date Submitted: 2012-12-29 20:17 EST Last Modified: 2012-12-29 20:17 EST == Summary:Crash when using LibFindMacros Description: When running the attached test case, it crashes. -- Detecting CXX compiler ABI info - done Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x7fff5bc00bf8 0x000100096604 in cmCommandArgument_yyparse () (gdb) bt http://www.cmake.org/Bug/view.php?id=0 0x000100096604 in cmCommandArgument_yyparse () http://www.cmake.org/Bug/view.php?id=1 0x000100098804 in cmCommandArgumentParserHelper::ParseString () http://www.cmake.org/Bug/view.php?id=2 0x000100150c55 in cmMakefile::ExpandVariablesInString () http://www.cmake.org/Bug/view.php?id=3 0x000100151ea0 in cmMakefile::ExpandArguments () http://www.cmake.org/Bug/view.php?id=4 0x000100065551 in cmCommand::InvokeInitialPass () http://www.cmake.org/Bug/view.php?id=5 0x000100146caa in cmMakefile::ExecuteCommand () Steps to Reproduce: Run the attached test case. cd cmake_bug; cmake . Additional Information: Installed from macports == Issue History Date ModifiedUsername FieldChange == 2012-12-29 20:17 Matt Arsenault New Issue 2012-12-29 20:17 Matt Arsenault File Added: cmake_bug.zip == -- 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 0013823]: Auto-include Clang default include paths in Eclipse CDT
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=13823
==
Reported By:SirHase
Assigned To:
==
Project:CMake
Issue ID: 13823
Category: CMake
Reproducibility:always
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2012-12-30 15:47 EST
Last Modified: 2012-12-30 15:47 EST
==
Summary:Auto-include Clang default include paths in Eclipse
CDT
Description:
When generating a new Eclipse CDT project using CMake with Clang compiler
(/usr/bin/clang++), the project do not includes the default Clang
include/preprocessors symbols list, as it does when I use gcc.
Without the preprocessor symbols and include paths, Eclipse reports a lot of
false errors.
In Additional Information I talk about a solution, but may not be ideal because
requires extra steps, and the user needs to manually include the projects
compilation flags (-std=c++11 -stdlib=libc++).
Steps to Reproduce:
1) Create the first example from:
http://www.cmake.org/cmake/help/cmake_tutorial.html
2) Generate a Eclipse CDT project, specify native compiler to /usr/bin/clang and
/usr/bin/clang++ for C and C++ respectively
3) Import this new project in Eclipse
4) Check the include paths, it should be empty
Additional Information:
Software used:
Eclise IDE Version: Juno Service Release 1. Build id: 20121004-1855
Eclise CDT Version: 8.1.1.201209170703
Clang: 3.1 (branches/release_31) x86_64-pc-linux-gnu
--
Adding the include paths manually may not work because Eclipse can "forget" it
after a restart.
--
Using Eclipse automatic path/symbols list discovery solution:
Setting the discovery command to: "/usr/bin/clang++ -E -P -v -dD
${plugin_state_location}/${specs_file} -std=c++11 -stdlib=libc++"(here I use
C++11, so each environment will have it different, cant use CMake flags) then in
"C/C++ Project Paths" -> "Path Containers" add paths/symbols with this
discovery. This way, Eclipse preserves both CMake and default Clang
includes/symbols.
==
Issue History
Date ModifiedUsername FieldChange
==
2012-12-30 15:47 SirHaseNew 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 0013824]: FindCUDA: requires cmake project to have C++ toolchain
The following issue has been SUBMITTED. == http://cmake.org/Bug/view.php?id=13824 == Reported By:Mathieu Malaterre Assigned To: == Project:CMake Issue ID: 13824 Category: Modules Reproducibility:always Severity: block Priority: normal Status: new == Date Submitted: 2012-12-31 03:41 EST Last Modified: 2012-12-31 03:41 EST == Summary:FindCUDA: requires cmake project to have C++ toolchain Description: I cannot use FindCUDA from a C-only cmake project. Steps to Reproduce: $ cd /tmp $ mkdir cuda $ cd cuda $ touch empty.c $ cat CMakeLists.txt project(bla C) include(FindCUDA) CUDA_ADD_LIBRARY(foo SHARED empty.c) $ cmake . [...] -- Configuring done CMake Error: Error required internal CMake variable not set, cmake may be not be built correctly. Missing variable is: CMAKE_CXX_CREATE_SHARED_LIBRARY -- Generating done -- Build files have been written to: /tmp/cuda == Issue History Date ModifiedUsername FieldChange == 2012-12-31 03:41 Mathieu MalaterreNew 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 0013825]: ctest shouldn't report skipped tests as failed
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13825 == Reported By:mwoehlke Assigned To: == Project:CMake Issue ID: 13825 Category: CTest Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2012-12-31 14:36 EST Last Modified: 2012-12-31 14:36 EST == Summary:ctest shouldn't report skipped tests as failed Description: When CTest skips some tests, e.g. because their REQUIRED_FILES are missing, the tests contribute to the pass/fail statistics and are reported as failing. I would rather see output like: 50% tests passed, 2 tests failed out of 4 (17 tests were not run) ...and either only list tests that actually failed, or list skipped tests in a separate section This could be an option, if not suitable as default behavior (or maybe controlled by a global property in the CTestTestfile.cmake). == Issue History Date ModifiedUsername FieldChange == 2012-12-31 14:36 mwoehlke 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 0013826]: Problem with creating installation directories conatining a colon (:)
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=13826
==
Reported By:ofir
Assigned To:
==
Project:CMake
Issue ID: 13826
Category: CMake
Reproducibility:always
Severity: minor
Priority: low
Status: new
==
Date Submitted: 2013-01-01 14:28 EST
Last Modified: 2013-01-01 14:28 EST
==
Summary:Problem with creating installation directories
conatining a colon (:)
Description:
When running 'make install' with DESTDIR to a directory containing a colon,
cmake won't create parent directories. If parent directories already exist
everything works fine.
Steps to Reproduce:
With any cmake project that has some install() command:
make install DESTDIR=aa/b:b
mkdir aa
make install DESTDIR=aa/b:b
Additional Information:
The MakeDirectory function in Source/kwsys/SystemTools.cxx parses the directory
tree after the first colon it finds, probably to eliminate drive name in Windows
environment, although no #ifdef is in sight.
Also, it seems that this code just below
if(dir[dir.size()-1] == '/')
{
topdir = dir.substr(0, dir.size());
}
else
{
topdir = dir;
}
does nothing.
==
Issue History
Date ModifiedUsername FieldChange
==
2013-01-01 14:28 ofir 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 0013827]: UseQt4.cmake should add link_directories command
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=13827
==
Reported By:Martin Müllenhaupt
Assigned To:
==
Project:CMake
Issue ID: 13827
Category: Modules
Reproducibility:always
Severity: feature
Priority: normal
Status: new
==
Date Submitted: 2013-01-03 06:02 EST
Last Modified: 2013-01-03 06:02 EST
==
Summary:UseQt4.cmake should add link_directories command
Description:
UseQt4.cmake contains a
include_directories(${QT_INCLUDE_DIR})
command for the include directories.
It should contain a similar command
link_directories(${QT_LIBRARY_DIR})
for the lib directory.
This would complete the setup of Qt4 in my environment, where it wasn't
installed in the standard install prefix.
==
Issue History
Date ModifiedUsername FieldChange
==
2013-01-03 06:02 Martin MüllenhauptNew 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 0013828]: Need additional functionality for WiX packager
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13828 == Reported By:Jeremy Cook Assigned To: == Project:CMake Issue ID: 13828 Category: CPack Reproducibility:always Severity: feature Priority: normal Status: new == Date Submitted: 2013-01-03 09:12 EST Last Modified: 2013-01-03 09:12 EST == Summary:Need additional functionality for WiX packager Description: I am using the WiX packager and would like to see more flexibility in the build configuration. For example: pass the variable CPACK_PACKAGE_ICON to the WiX generator or in some other way set the WixVariables WixUIBannerBmp, WixUIDialogBmp and the property ARPPRODUCTICON Either improve documentation with examples for WIX.template.in or create a way to add application shortcuts from CMakeLists == Issue History Date ModifiedUsername FieldChange == 2013-01-03 09:12 Jeremy CookNew 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 0013829]: Internal error in add_custom_target crashes with $
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=13829
==
Reported By:Alessio M.
Assigned To:
==
Project:CMake
Issue ID: 13829
Category: CMake
Reproducibility:always
Severity: block
Priority: urgent
Status: new
==
Date Submitted: 2013-01-03 13:26 EST
Last Modified: 2013-01-03 13:26 EST
==
Summary:Internal error in add_custom_target crashes with
$
Description:
The following CMakeLists.txt crashes CMake during generation
cmake_minimum_required(VERSION 2.8.10)
project(TestBug)
add_executable(test test.cpp)
add_custom_target(test2
"some_bogus_custom_tool"
$
$
WORKING_DIRECTORY
"${CMAKE_CURRENT_SOURCE_DIR}")
== CMake output follows ===
Configuring done
CMake Internal Error (please report a bug):
Missing cmGeneratorTarget instance!
CMake Internal Error (please report a bug):
Missing cmGeneratorTarget instance!
Generating done
==
Issue History
Date ModifiedUsername FieldChange
==
2013-01-03 13:26 Alessio M. New Issue
2013-01-03 13:26 Alessio M. File Added: cmake-generator-expression-bug.7z
==
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0013830]: VS 2010 generator completely ignores the RC compiling rule
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=13830
==
Reported By:Amine Khaldi
Assigned To:
==
Project:CMake
Issue ID: 13830
Category: CMake
Reproducibility:always
Severity: major
Priority: normal
Status: new
==
Date Submitted: 2013-01-03 17:30 EST
Last Modified: 2013-01-03 17:30 EST
==
Summary:VS 2010 generator completely ignores the RC
compiling rule
Description:
ReactOS uses set(CMAKE_RC_COMPILE_OBJECT "
${I18N_DEFS} /fo ")
Which works perfectly with ninja and nmake makefiles. When you use the VS 2010
generator you will get a *very* different handling of rc files, that leads to
broken binaries. There is absolutely no way to customize it at least and put it
inside an if(MSVC_IDE) or something (as a hack).
==
Issue History
Date ModifiedUsername FieldChange
==
2013-01-03 17:30 Amine Khaldi 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 0013831]: VS 2010 generator doesn't respect the EXTERNAL_OBJECT propery
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13831 == Reported By:Amine Khaldi Assigned To: == Project:CMake Issue ID: 13831 Category: CMake Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 2013-01-03 17:33 EST Last Modified: 2013-01-03 17:33 EST == Summary:VS 2010 generator doesn't respect the EXTERNAL_OBJECT propery Description: We (ReactOS) tried to work around the lack of support for preprocessed asm file in the VS generators, by creating a custom command where we preprocess using cl and then pass to ml to generate objects. We then add these objects back as source files for the target in question, marking them as EXTERNAL_OBJECT. This works perfectly for the normal makefiles, the objects get used in the linker. With the VS 2010 generator we get these objects as "not part of the build" while they should in fact be Objects. == Issue History Date ModifiedUsername FieldChange == 2013-01-03 17:33 Amine Khaldi 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 0013832]: VS 2010 generator lack the opt-out of setting incremental, UAC flags, default includes, default libs...etc
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13832 == Reported By:Amine Khaldi Assigned To: == Project:CMake Issue ID: 13832 Category: CMake Reproducibility:have not tried Severity: major Priority: normal Status: new == Date Submitted: 2013-01-03 17:40 EST Last Modified: 2013-01-03 17:40 EST == Summary:VS 2010 generator lack the opt-out of setting incremental, UAC flags, default includes, default libs...etc Description: ReactOS codebase, especially drivers, get link errors because we explicitly set for example the /release flag, and the linker complains about it interfering with the incremental flag, that we never asked for. We can't find a way to completely remove such flags, so that we can have only what we explicitly ask for. This btw also applies to the default includes and libs folders. == Issue History Date ModifiedUsername FieldChange == 2013-01-03 17:40 Amine Khaldi 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 0013833]: fixup_bundle fails with libraries that aren't writable
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=13833 == Reported By:Matt Arsenault Assigned To: == Project:CMake Issue ID: 13833 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2013-01-04 01:04 EST Last Modified: 2013-01-04 01:04 EST == Summary:fixup_bundle fails with libraries that aren't writable Description: I'm having the same problem described here with 2.8.9, so this looks like a regression: http://www.cmake.org/Bug/view.php?id=9284 -- 26/34: fixing up 'install_prefix/example.app/Contents/MacOS/libcrypto.1.0.0.dylib' install_name_tool: can't open input file: install_prefix/example.app/Contents/MacOS/libcrypto.1.0.0.dylib for writing (Permission denied) install_name_tool: can't lseek to offset: 0 in file: install_prefix/example.app/Contents/MacOS/libcrypto.1.0.0.dylib for writing (Bad file descriptor) install_name_tool: can't write new headers in file: install_prefix/example.app/Contents/MacOS/libcrypto.1.0.0.dylib (Bad file descriptor) install_name_tool: can't close written on input file: install_prefix/example.app/Contents/MacOS/libcrypto.1.0.0.dylib (Bad file descriptor) $ ls -l /opt/local/lib/libcrypto.1.0.0.dylib -r-xr-xr-x 1 root admin 1.6M Jul 27 04:40 /opt/local/lib/libcrypto.1.0.0.dylib Steps to Reproduce: 1. Try to use fixup_bundle with a library dependency that isn't writable, e.g. libcrypto and libssl from macports. 2. It fails with a permission error == Issue History Date ModifiedUsername FieldChange == 2013-01-04 01:04 Matt Arsenault 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 0013834]: FindBLAS doesn't trust pkg-config and may, therefore, fail
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=13834 == Reported By:Gert Wollny Assigned To: == Project:CMake Issue ID: 13834 Category: CMake Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 2013-01-04 07:25 EST Last Modified: 2013-01-04 07:25 EST == Summary:FindBLAS doesn't trust pkg-config and may, therefore, fail Description: FindBLAS first tries to locate the BLAS libraries by using pkg-config. However, instead of trusting the returned information, it then tries to locate all libraries given in the returned string within the returned library directory. When on Gentoo ACML is selected to provide BLAS, this strategy fails, because apart from the acml libraries, libgfortran and libpthread are reported by phk-config and these libraries are not located within the given library directory, since they are in the default library search path. Steps to Reproduce: on Gentoo: eselect blas set acml-gfortran-openmp Add to CmakeLists.txt: FIND_PACKAGE(BLAS) run cmake Make Error at /usr/share/cmake/Modules/FindBLAS.cmake:58 (message): Something is wrong in your pkg-config file - lib gfortran not found in /opt/acml4.4.0/gfortran64_mp/lib Additional Information: Instead of searching for the libraries, FindBLAS should either just trust pkg-config, or try to link a simple program that requires a BLAS function. == Issue History Date ModifiedUsername FieldChange == 2013-01-04 07:25 Gert WollnyNew 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 0013835]: Ninja: relative header is always dirty
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=13835 == Reported By:Peter Kuemmel Assigned To: == Project:CMake Issue ID: 13835 Category: CMake Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 2013-01-05 03:25 EST Last Modified: 2013-01-05 03:25 EST == Summary:Ninja: relative header is always dirty Description: #include "../xyz/abc.h" in some source file, then xyz/abc.h is always dirty == Issue History Date ModifiedUsername FieldChange == 2013-01-05 03:25 Peter Kuemmel 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 0013836]: ENVIRONMENT property of CTest test is not documented
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13836 == Reported By:Sergey Zolotarev Assigned To: == Project:CMake Issue ID: 13836 Category: Documentation Reproducibility:have not tried Severity: minor Priority: normal Status: new == Date Submitted: 2013-01-06 16:07 EST Last Modified: 2013-01-06 16:07 EST == Summary:ENVIRONMENT property of CTest test is not documented Description: There doesn't seem to be any documentation on the ENVIRONMENT property at http://cmake.org/cmake/help/v2.8.10/cmake.html#command:set_tests_properties == Issue History Date ModifiedUsername FieldChange == 2013-01-06 16:07 Sergey ZolotarevNew 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 0013837]: QT_VERSION_* variables defined too late in FindQt4.cmake
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=13837 == Reported By:Martin Müllenhaupt Assigned To: == Project:CMake Issue ID: 13837 Category: Modules Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2013-01-07 10:03 EST Last Modified: 2013-01-07 10:03 EST == Summary:QT_VERSION_* variables defined too late in FindQt4.cmake Description: In FindQt4.cmake, lines 1174-1176, the variables QT_VERSION_MAJOR, QT_VERSION_MINOR and QT_VERSION_PATCH are defined. But they are used earlier in line 1076 by the Qt4ConfigDependentSettings.cmake macro. This results in failing static linkage of the QtNetwork library when compiling with OpenSSL support on my setup (http://mxe.cc/). == Issue History Date ModifiedUsername FieldChange == 2013-01-07 10:03 Martin MüllenhauptNew 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 0013838]: Targets for generating preprocessed files missing from Ninja generator
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13838 == Reported By:Óscar Fuentes Assigned To: == Project:CMake Issue ID: 13838 Category: CMake Reproducibility:always Severity: feature Priority: normal Status: new == Date Submitted: 2013-01-07 13:00 EST Last Modified: 2013-01-07 13:00 EST == Summary:Targets for generating preprocessed files missing from Ninja generator Description: The Ninja generator does not create *.i targets for generating preprocessed files from C++/C source files. == Issue History Date ModifiedUsername FieldChange == 2013-01-07 13:00 Óscar Fuentes 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 0013839]: Targets for generating Assembler files missing from Ninja generator
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13839 == Reported By:Óscar Fuentes Assigned To: == Project:CMake Issue ID: 13839 Category: CMake Reproducibility:always Severity: feature Priority: normal Status: new == Date Submitted: 2013-01-07 13:20 EST Last Modified: 2013-01-07 13:20 EST == Summary:Targets for generating Assembler files missing from Ninja generator Description: The Ninja generator does not create *.s targets for generating Assembler files from source files. With other Makefile generators, if you a have a source file foo.c you can execute `make foo.s' for obtaining the compiler's Assembler output for foo.c. It works like this: scar@qcore:~/dev/idb/lp0/build/variadic/gcc/release$ make tokenctr.s Compiling CXX source to assembly CMakeFiles/lp0core.dir/tokenctr.cpp.s == Issue History Date ModifiedUsername FieldChange == 2013-01-07 13:20 Óscar Fuentes 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 0013840]: Allow generator expressions anywhere
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=13840
==
Reported By:raspy
Assigned To:
==
Project:CMake
Issue ID: 13840
Category: CMake
Reproducibility:N/A
Severity: feature
Priority: normal
Status: new
==
Date Submitted: 2013-01-08 11:21 EST
Last Modified: 2013-01-08 11:21 EST
==
Summary:Allow generator expressions anywhere
Description:
add_custom_command allows to use generator expressions, but only in COMMAND
sections. They cannot be used in OUTPUT or DEPENDS sections. It would be useful
to support them anywhere in the CMakeLists.txt, so I could use them in variables
as well. Currently if I need to create a file in the same directory as output, I
would go with:
GET_TARGET_PROPERTY(OUTFILE_LOCATION file.out LOCATION)
GET_FILENAME_COMPONENT(OUTFILE_LOCATION_DIR ${OUTFILE_LOCATION} PATH)
SET(ANOTHER_FILE_NAME ${OUTFILE_LOCATION_DIR}/another.file)
It would be much more useful to just write:
SET(ANOTHER_FILE_NAME $/another.file)
(btw. tried this in hope of delayed expansion but it failed as well on the
OUTPUT line of add_custom_command)
==
Issue History
Date ModifiedUsername FieldChange
==
2013-01-08 11:21 raspy 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 0013841]: XCode post-build shell scripts fail
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=13841
==
Reported By:David Rosen
Assigned To:
==
Project:CMake
Issue ID: 13841
Category: CMake
Reproducibility:always
Severity: major
Priority: immediate
Status: new
==
Date Submitted: 2013-01-09 04:28 EST
Last Modified: 2013-01-09 04:28 EST
==
Summary:XCode post-build shell scripts fail
Description:
When opening any XCode project that is built out-of-source, an error like this
immediately appears, and the project cannot build:
PhaseScriptExecution "CMake Rules"
/Users/david/Documents/OvergrowthSVN/TempBuild/Overgrowth.build/Debug/ZERO_CHECK.build/Script-57C6D205AA0E4C069EB19117.sh
cd /Users/david/Documents/OvergrowthSVN/Projects
/bin/sh -c
/Users/david/Documents/OvergrowthSVN/TempBuild/Overgrowth.build/Debug/ZERO_CHECK.build/Script-57C6D205AA0E4C069EB19117.sh
make: CMakeScripts/ZERO_CHECK_cmakeRulesBuildPhase.makeDebug: No such file or
directory
make: *** No rule to make target
`CMakeScripts/ZERO_CHECK_cmakeRulesBuildPhase.makeDebug'. Stop.
I believe this error occurs because it is searching for the relative path
"CMakeScripts/ZERO_CHECK_cmakeRulesBuildPhase.makeDebug", and expecting the
working directory to be ${CMAKE_BINARY_DIR}. It is failing because immediately
before running the script, XCode is calling "cd ${CMAKE_SOURCE_DIR}".
This seems to be because XCode calls "cd ${projectDirPath}" before calling any
post-build shell scripts, and when CMake builds an XCode project, it sets the
XCode "projectDirPath" value to ${CMAKE_SOURCE_DIR}. This can be observed by
opening the pbxproj file and searching for "projectDirPath".
Steps to Reproduce:
Use CMake 2.8.10.2 to generate an XCode project with a different source and
binary directory. Open the project with XCode 4.5.2. You should immediately see
the error quoted in the description.
I have attached my project's CMakeLists.txt and subdirectories which have
exhibited this problem on three computers, in case it does not occur on every
CMake-created out-of-source XCode project.
Additional Information:
There are three paths that I see to solve this problem. First, the shell scripts
could be given an absolute path, so it doesn't matter what the working directory
is set to. Second, the projectDirPath could be set to ${CMAKE_BINARY_DIR}
instead of ${CMAKE_SOURCE_DIR}. Third, and most preferable I think, the
projectDirPath could just be left as "". That way the XCode project would not
break if it is moved.
I have tested these approaches by manually changing the pbxproj file, and they
all seem to solve the problem.
==
Issue History
Date ModifiedUsername FieldChange
==
2013-01-09 04:28 David RosenNew Issue
2013-01-09 04:28 David RosenFile Added: xcode_break_example.zip
==
--
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 0013354]: CMake hangs generating XCode project file when CXXFLAGS contains -g in a flag
The following issue is now in status NEW (again)
==
http://public.kitware.com/Bug/view.php?id=13354
==
Reported By:Jens Bäckman
Assigned To:
==
Project:CMake
Issue ID: 13354
Category: CMake
Reproducibility:always
Severity: major
Priority: normal
Status: new
Target Version: CMake 2.8.11
==
Date Submitted: 2012-06-27 08:14 EDT
Last Modified: 2013-01-09 10:27 EST
==
Summary:CMake hangs generating XCode project file when
CXXFLAGS contains -g in a flag
Description:
When adding the compiler flag -Wno-global-constructors,
Steps to Reproduce:
Add the following line to an existing CMakeLists.txt file:
set (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wno-global-constructors")
Run "cmake -G Xcode". You will be left with the message "Generating done", and
no project file generated.
Additional Information:
Might be related to the bug discussed here:
http://comments.gmane.org/gmane.comp.programming.tools.cmake.user/40319
==
Relationships ID Summary
--
related to 0012377 CMake misparses -g0 as enable debug
==
--
(0031933) David Cole (manager) - 2012-12-20 11:38
http://public.kitware.com/Bug/view.php?id=13354#c31933
--
This issue was introduced by the commit that "fixed" the related bug
http://public.kitware.com/Bug/view.php?id=12377:
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=cb22afc02c0524ff2b701b33a29339dde1e80bbd
Issue History
Date ModifiedUsername FieldChange
==
2012-06-27 08:14 Jens Bäckman New Issue
2012-06-27 08:14 Jens Bäckman Tag Attached: macosx
2012-06-27 08:14 Jens Bäckman Tag Attached: Xcode
2012-07-10 17:57 David Cole Assigned To => David Cole
2012-07-10 17:57 David Cole Status new => assigned
2012-12-03 14:49 David Cole Target Version=> CMake 2.8.11
2012-12-15 17:17 Arjun GovindjeeIssue Monitored: Arjun Govindjee
2012-12-20 11:36 David Cole Relationship added related to 0012377
2012-12-20 11:38 David Cole Note Added: 0031933
2013-01-09 10:26 David Cole Assigned To David Cole =>
2013-01-09 10:27 David Cole Status assigned => new
==
--
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 0013842]: No Support for C++11
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=13842 == Reported By:Dave Abrahams Assigned To: == Project:CMake Issue ID: 13842 Category: CMake Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 2013-01-09 11:02 EST Last Modified: 2013-01-09 11:02 EST == Summary:No Support for C++11 Description: We could use C++11 feature detection per http://pageant.ghulbus.eu/?p=664 and also a compiler-agnostic way to turn on C++11 support. == Issue History Date ModifiedUsername FieldChange == 2013-01-09 11:02 Dave Abrahams 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 0013843]: FindMPI doesn't set MPI_C_LINK_FLAGS or MPI_C_COMPILE_FLAGS (and same for CXX)
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=13843
==
Reported By:jgu
Assigned To:
==
Project:CMake
Issue ID: 13843
Category: Modules
Reproducibility:always
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2013-01-10 07:01 EST
Last Modified: 2013-01-10 07:01 EST
==
Summary:FindMPI doesn't set MPI_C_LINK_FLAGS or
MPI_C_COMPILE_FLAGS (and same for CXX)
Description:
I have a project which does a find_package(MPI). I use the following snippet to
print out all variables:
get_cmake_property(_variableNames VARIABLES)
foreach (_variableName ${_variableNames})
message(STATUS "${_variableName}=${${_variableName}}")
endforeach()
which produces for the MPI relevant variables:
-- MPIEXEC=/usr/lib64/openmpi/bin/mpiexec
-- MPIEXEC_MAX_NUMPROCS=2
-- MPIEXEC_NUMPROC_FLAG=-np
-- MPIEXEC_POSTFLAGS=
-- MPIEXEC_PREFLAGS=
-- MPI_COMPILER=/usr/lib64/openmpi/bin/mpicxx
-- MPI_COMPILER_IS_EXECUTABLE=0
-- MPI_CXX_COMPILER=/usr/lib64/openmpi/bin/mpicxx
-- MPI_CXX_COMPILE_FLAGS=
-- MPI_CXX_FOUND=TRUE
-- MPI_CXX_INCLUDE_PATH=/usr/include/openmpi-x86_64
--
MPI_CXX_LIBRARIES=/usr/lib64/openmpi/lib/libmpi_cxx.so;/usr/lib64/openmpi/lib/libmpi.so;/usr/lib64/libdl.so
-- MPI_CXX_LINK_FLAGS=
-- MPI_C_COMPILER=/usr/lib64/openmpi/bin/mpicc
-- MPI_C_COMPILE_FLAGS=
-- MPI_C_FOUND=TRUE
-- MPI_C_INCLUDE_PATH=/usr/include/openmpi-x86_64
-- MPI_C_LIBRARIES=/usr/lib64/openmpi/lib/libmpi.so;/usr/lib64/libdl.so
-- MPI_C_LINK_FLAGS=
-- MPI_EXTRA_LIBRARY=/usr/lib64/openmpi/lib/libmpi.so;/usr/lib64/libdl.so
-- MPI_EXTRA_LIBRARY_WORK=/usr/lib64/openmpi/lib/libmpi.so;/usr/lib64/libdl.so
-- MPI_FOUND=TRUE
-- MPI_HEADER_PATH=MPI_HEADER_PATH-NOTFOUND
-- MPI_INCLUDE_PATH=/usr/include/openmpi-x86_64
-- MPI_LIB=MPI_LIB-NOTFOUND
--
MPI_LIBRARIES=/usr/lib64/openmpi/lib/libmpi_cxx.so;/usr/lib64/openmpi/lib/libmpi.so;/usr/lib64/libdl.so
-- MPI_LIBRARY=/usr/lib64/openmpi/lib/libmpi_cxx.so
-- MPI_LIBRARY_WORK=/usr/lib64/openmpi/lib/libmpi_cxx.so
-- MPI_NUMLIBS=3
-- MpiPackageDir=
which shows empty MPI_C_LINK_FLAGS and MPI_C_COMPILE_FLAGS and the same for the
equivalent CXX variables. As a result, even though my project has this:
set_target_properties(myexec PROPERTIES
COMPILE_FLAGS "${MPI_C_COMPILE_FLAGS}"
COMPILE_DEFINITIONS "BUILD_WITH_MPI"
LINK_FLAGS "${MPI_C_LINK_FLAGS}"
)
it fails to link against mpi (-lmpi is missing, for a start).
==
Issue History
Date ModifiedUsername FieldChange
==
2013-01-10 07:01 jguNew 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 0013844]: PurifyPlus 7.0.1-003 cannot properly interpret SAVETEXTDATA command line switch due to quotation marks
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13844 == Reported By:Ingmar Voigt Assigned To: == Project:CMake Issue ID: 13844 Category: CTest Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2013-01-10 07:29 EST Last Modified: 2013-01-10 07:29 EST == Summary:PurifyPlus 7.0.1-003 cannot properly interpret SAVETEXTDATA command line switch due to quotation marks Description: PROBLEM: This started with PurifyPlus 7.0.1-003 - PurifyPlus 7.0.0 did not show such behaviour. The solution should however work for both CTest 2.8.3 memchecker produces on Windows the following command line to execute Purify (extracted from my logs): C:\Progra~1\IBM\RationalPurifyPlus\purify.exe "/SAVETEXTDATA=D:/MyBinDir/Testing/Temporary/MemoryChecker.log" "D:/MyBinDir/bin/Debug/MyTest.exe" When executing this Purify 7.0.1-003 complains the following way: Unable to find file /SAVETEXTDATA=D:/MyBinDir/Testing/Temporary/MemoryChecker.log. The reason is the command line /SAVETEXTDATA=... is wrapped in quotation marks "/SAVETEXTDATA=D:/MyBinFolder/Testing/Temporary/MemoryChecker.log" the problem does not occur when changing the command line by shift the quotation mark after the equal sign: /SAVETEXTDATA="D:/MyBinFolder/Testing/Temporary/MemoryChecker.log" SOLUTION: use /SAVETEXTDATA="D:/MyBinFolder/Testing/Temporary/MemoryChecker.log" instead of "/SAVETEXTDATA=D:/MyBinFolder/Testing/Temporary/MemoryChecker.log" i.e. C:\Progra~1\IBM\RationalPurifyPlus\purify.exe /SAVETEXTDATA="D:/MyBinFolder/Testing/Temporary/MemoryChecker.log" "D:/MyBinFolder/bin/Debug/MyTest.exe" Steps to Reproduce: Execute PurifyPlus 7.0.1-003 C:\Progra~1\IBM\RationalPurifyPlus\purify.exe "/SAVETEXTDATA=D:/MyBinFolder/Testing/Temporary/MemoryChecker.log" "D:/MyBinFolder/bin/Debug/MyTest.exe" and try again with C:\Progra~1\IBM\RationalPurifyPlus\purify.exe /SAVETEXTDATA="D:/MyBinFolder/Testing/Temporary/MemoryChecker.log" "D:/MyBinFolder/bin/Debug/MyTest.exe" Additional Information: >From the CTest logs: Memory check command: C:\Progra~1\IBM\RationalPurifyPlus\purify.exe "/SAVETEXTDATA=D:/MyBinDir/Testing/Temporary/MemoryChecker.log" 149: MemCheck command: C:\Progra~1\IBM\RationalPurifyPlus\purify.exe "/SAVETEXTDATA=D:/MyBinDir/Testing/Temporary/MemoryChecker.log" "D:/MyBinDir/bin/Debug/MyTest.exe" == Issue History Date ModifiedUsername FieldChange == 2013-01-10 07:29 Ingmar Voigt 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
