[cmake-developers] [CMake 0013241]: WriteBasicConfigVersionFile produces bad files without CMAKE_SIZEOF_VOID_P
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=13241
==
Reported By:Brad King
Assigned To:Alex Neundorf
==
Project:CMake
Issue ID: 13241
Category: CMake
Reproducibility:always
Severity: minor
Priority: normal
Status: assigned
Target Version: CMake 2.8.9
==
Date Submitted: 2012-05-21 11:49 EDT
Last Modified: 2012-05-21 11:49 EDT
==
Summary:WriteBasicConfigVersionFile produces bad files
without CMAKE_SIZEOF_VOID_P
Description:
Modules/BasicConfigVersion-*.cmake.in contain the code
# check that the installed version has the same 32/64bit-ness as the one which
is currently searching:
if(NOT "${CMAKE_SIZEOF_VOID_P}" STREQUAL "@CMAKE_SIZEOF_VOID_P@")
math(EXPR installedBits "@CMAKE_SIZEOF_VOID_P@ * 8")
set(PACKAGE_VERSION "${PACKAGE_VERSION} (${installedBits}bit)")
set(PACKAGE_VERSION_UNSUITABLE TRUE)
endif()
When this is configured with an empty CMAKE_SIZEOF_VOID_P the resulting file
breaks. This breaks find_package calls that load the version file with an
outright error instead of reporting an unsuitable version.
==
Issue History
Date ModifiedUsername FieldChange
==
2012-05-21 11:49 Brad King New Issue
2012-05-21 11:49 Brad King Status new => assigned
2012-05-21 11:49 Brad King Assigned To => Alex Neundorf
==
--
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 0013242]: CDash shows incorrect build error/warning count in project view if more than one build submission is used
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13242 == Reported By:Matthias Kretz Assigned To: == Project:CMake Issue ID: 13242 Category: (No Category) Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2012-05-22 09:14 EDT Last Modified: 2012-05-22 09:14 EDT == Summary:CDash shows incorrect build error/warning count in project view if more than one build submission is used Description: CDash overwrites builderrors/buildwarnings in the build table with the most recent number and thus only shows the number of the last submission. Instead it should add the numbers to the old ones on UPDATE. == Issue History Date ModifiedUsername FieldChange == 2012-05-22 09:14 Matthias Kretz New Issue 2012-05-22 09:14 Matthias Kretz File Added: fix-cdash.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 0013244]: components are append to Boost_LIBRARIES
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=13244
==
Reported By:dam
Assigned To:
==
Project:CMake
Issue ID: 13244
Category: CMake
Reproducibility:always
Severity: minor
Priority: high
Status: new
==
Date Submitted: 2012-05-23 05:03 EDT
Last Modified: 2012-05-23 05:03 EDT
==
Summary:components are append to Boost_LIBRARIES
Description:
When using FindBoost in the same CMakeLists.txt and with different components,
the variable Boost_LIBRARIES contains the union of the components.
I think that Boost_LIBRARIES variable should be cleared when each time
find_package(Boost ...) is invoked, or perhaps the doc should mentioned this
behavior.
Steps to Reproduce:
cmake_minimum_required(VERSION 2.8 FATAL_ERROR)
project(foo)
find_package(Boost COMPONENTS thread)
message("boost libs: ${Boost_LIBRARIES}")
find_package(Boost COMPONENTS date_time)
message("\nboost libs: ${Boost_LIBRARIES}")
# the result is:
# boost libs: /usr/lib/libboost_thread-mt.so
#
# boost libs: /usr/lib/libboost_thread-mt.so;/usr/lib/libboost_date_time-mt.so
# but I think it should be:
# boost libs: /usr/lib/libboost_date_time-mt.so
==
Issue History
Date ModifiedUsername FieldChange
==
2012-05-23 05:03 damNew 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 0013245]: FindQt4.cmake doesn't work on Windows 8
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=13245
==
Reported By:Stephen Kelly
Assigned To:Clinton Stimpson
==
Project:CMake
Issue ID: 13245
Category: CMake
Reproducibility:always
Severity: minor
Priority: normal
Status: assigned
==
Date Submitted: 2012-05-23 14:23 EDT
Last Modified: 2012-05-23 14:23 EDT
==
Summary:FindQt4.cmake doesn't work on Windows 8
Description:
The output of qmake --version can contain a message which confuses FindQt4.cmake
when run on Windows 8:
qWarning("Qt: Untested Windows version %d.%d detected!",
osver.dwMajorVersion, osver.dwMinorVersion);
This may or may not be fixable in Qt:
http://thread.gmane.org/gmane.comp.lib.qt.devel/4087
However, this issue most likely exists with all existing versions of Qt 4
anyway, so it may be worth working around by detecting and ignoring a line with
that message in the output.
==
Issue History
Date ModifiedUsername FieldChange
==
2012-05-23 14:23 Stephen Kelly New Issue
2012-05-23 14:23 Stephen Kelly Status new => assigned
2012-05-23 14:23 Stephen Kelly Assigned To => Clinton Stimpson
==
--
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 0013247]: VC generator add all shared library deps for dependent targets
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13247 == Reported By:4ertus2 Assigned To: == Project:CMake Issue ID: 13247 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2012-05-25 06:45 EDT Last Modified: 2012-05-25 06:45 EDT == Summary:VC generator add all shared library deps for dependent targets Description: I use lots of static libraries targets that are combined into resulting shared library (in example mylib.dll). After that I add executable that depends on resulting library only (ex. myprog.exe). VC Generator add all the mylib.dll dependencies to myprog.exe link flags. It is strange behavior cause if some function is already in mylib.dll I don't need any dependencies and if it's not - I better define some library in target_link_libraries manually. In fact it could be a problem - not all functions are included in mylib.dll. And CMake try to hide the problem from me. == Issue History Date ModifiedUsername FieldChange == 2012-05-25 06:45 4ertus2New 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 0013248]: CPackRPM bug - empty per-component REQUIRES
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=13248
==
Reported By:Sergei Golubchik
Assigned To:
==
Project:CMake
Issue ID: 13248
Category: CPack
Reproducibility:always
Severity: major
Priority: normal
Status: new
==
Date Submitted: 2012-05-25 12:57 CEST
Last Modified: 2012-05-25 12:57 CEST
==
Summary:CPackRPM bug - empty per-component REQUIRES
Description:
If building per-component RPMs and some rpms have OBSOLETES (or REQUIRES,
whatever) and other don't - in this case all rpm's that don't provide OBSOLETES
will inherit the OBSOLETES header of the previous (in the alphabetical order)
component. It happens because CPackRPM does not unset the corresponding header
variable, when a per-component variable is not set. This patch fixes it:
--- CPackRPM.cmake 2012-05-25 12:50:53.0 +0200
+++ CPackRPM.cmake 2012-05-25 12:50:45.0 +0200
@@ -488,6 +488,8 @@
MESSAGE("CPackRPM:Debug: User defined ${_PACKAGE_HEADER_NAME}:\n
${CPACK_RPM_PACKAGE_${_RPM_SPEC_HEADER}_TMP}")
ENDIF(CPACK_RPM_PACKAGE_DEBUG)
SET(TMP_RPM_${_RPM_SPEC_HEADER} "${_PACKAGE_HEADER_NAME}:
${CPACK_RPM_PACKAGE_${_RPM_SPEC_HEADER}_TMP}")
+ELSE(CPACK_RPM_PACKAGE_${_RPM_SPEC_HEADER}_TMP)
+UNSET(TMP_RPM_${_RPM_SPEC_HEADER})
ENDIF(CPACK_RPM_PACKAGE_${_RPM_SPEC_HEADER}_TMP)
ENDFOREACH(_RPM_SPEC_HEADER)
==
Issue History
Date ModifiedUsername FieldChange
==
2012-05-25 12:57 Sergei GolubchikNew 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 0013249]: Static fortran executables fail to build due to a missing libintlc reference.
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=13249 == Reported By:Travis Horine Assigned To: == Project:CMake Issue ID: 13249 Category: CMakeSetup Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2012-05-25 14:07 EDT Last Modified: 2012-05-25 14:07 EDT == Summary:Static fortran executables fail to build due to a missing libintlc reference. Description: Not 100% sure if this is a bug but thought I should submit it just in case. As I understand it, the first time cmake runs it tries to figure out some basic things like which compiler to use and what the compiler needs by way of basic flags,etc... I'm not sure why but according to the CMakeOutput.log generated during this compiler detection phase, cmake is trying to collect an explicit list of the implicit libraries used by the compiler. It then apparently applies these implicit libraries explicitly to each target link when the target was built with the associated compiler. Assuming that is what is happening then there may be a problem with that approach using the Intel 12.0.2 fortran compiler. That compiler reports the implicit use of a so called 'intlc' library which appears to only exist in shared object form on my machine. I think the compiler reports this as an implicit library because CMake is invoking it with the '-i_dynamic' flag (see cmake-2.8.4/share/cmake-2.8/Modules/Platform/Linux-Intel-Fortran.cmake). '-i_dynamic' is ostensibly slang for the 'shared-intel' flag. Since this -i_dynamic flag causes the intel compiler to report 'intlc' as an implicit library the -lintlc flag is therefore being explicitly appended to any link commands even when the '-static' flag is also present. Although my executable does not actually need this intlc library (ie...I can remove it manually from the link line and get a functional static build) the compiler fails to compile when the '-static' flag is present simply because it cannot find a static version of the intlc library ie.. 'libintlc.a' Assuming it is important for CMake to continue to explicitly list the normally 'implicit' libraries on the link lines then there may be a need to weed out those libraries which do not have static counter parts for a given compiler. At least, my workaround for this has been to use LIST(REMOVE_ITEM CMAKE_Fortran_IMPLICIT_LINK_LIBRARIES intlc) in my CMakeLists.txt file before trying to build the static executable. Steps to Reproduce: basically: Use add_executable to build a fortran executable with CMAKE_EXE_LINKER_FLAGS set to "-static". In my case, (maybe this is important) I am building a mixed language executable where the C++ compiler (icpc) builds an object, the Fortran compiler (ifort) builds an object and then the C++ compiler (icpc) is invoked for linking the two objects into a static executable. Additional Information: My CMakeList file is something like this: SET(CMAKE_EXE_LINKER_FLAGS "-static") ADD_EXECUTABLE(file file.cpp) TARGET_LINK_LIBRARIES(file alib blib) Where alib is a library built in the parent directory and blib is a library built in a subdirectory of the file.cpp source. == Issue History Date ModifiedUsername FieldChange == 2012-05-25 14:07 Travis Horine 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 0013250]: Freetype Detection needs Improvement
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=13250 == Reported By:Karthik Kumar Viswanathan Assigned To: == Project:CMake Issue ID: 13250 Category: (No Category) Reproducibility:have not tried Severity: minor Priority: high Status: new == Date Submitted: 2012-05-26 12:59 EDT Last Modified: 2012-05-26 12:59 EDT == Summary:Freetype Detection needs Improvement Description: FindFreetype.cmake is not useful to use an external directory for Freetype - needs modifications so it doesn't look for ft2build.h etc in root directories. Additional Information: I've attached a new module file with additional hints. == Issue History Date ModifiedUsername FieldChange == 2012-05-26 12:59 Karthik Kumar ViswanathanNew Issue 2012-05-26 12:59 Karthik Kumar ViswanathanFile Added: FindFreetype.cmake == -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://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 has been SUBMITTED. == http://public.kitware.com/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-05-27 07:37 EDT == 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. == Issue History Date ModifiedUsername FieldChange == 2012-05-27 07:37 sigma 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 0013254]: phonon_ds9 backend plugin not found on windows.
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13254 == Reported By:Kurtis Nusbaum Assigned To: == Project:CMake Issue ID: 13254 Category: Modules Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2012-05-29 15:59 EDT Last Modified: 2012-05-29 15:59 EDT == Summary:phonon_ds9 backend plugin not found on windows. Description: I'm deploying a Qt application which uses phonon on windows. For some reason, the DeployQt4.cmake module wasn't finding the phonon_ds9 backend plugin that is standard with windows installations of Qt4. More specifically (and was I'm almost positive this was what was tripping up DeployQt4), the QT_PHONON_DS9_PLUGIN_RELEASE variable was not set. I went and looked at the FindQt4.cmake file and found this line (it's line 1062 on cmake release 2.8.8): set( QT_PHONON_BACKEND_PLUGINS phonon_qt7 ) phonon_qt7 is the phonon backend used exclusively on mac. Sure enough, changing the line to set( QT_PHONON_BACKEND_PLUGINS phonon_ds9 ) resulted in the variable QT_PHONON_DS9_PLUGIN_RELEASE and QT_PHONON_DS9_PLUGIN_DEBUG being set to the correct libraries and DeployQt4 module finding the phonon_ds9 plugin and successfully bundling it with my application. I think this is a bug in FindQt4.cmake Steps to Reproduce: 1. Create an application that uses the phonon backend for Qt. 2. Use DeployQt and pass phonon_ds9 and the plugin argument when calling install_qt4_executable function. Additional Information: Attached is a patch that does a mediocre job at addressing the issue. It basically, if it detects you're building for an APPLE machine it sets the phonon backend plugin variable to phonon_qt7 and if you're on windows it sets the variable to phonon_ds9. This obviously doesn't take into account all the other possible phonon backend situations. A more rigorous fix would address detecting the presence of other phonon backends. == Issue History Date ModifiedUsername FieldChange == 2012-05-29 15:59 Kurtis Nusbaum New Issue 2012-05-29 15:59 Kurtis Nusbaum File Added: 0001-Added-conditional-for-the-phonon-backend-plugin.-If-.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 0013257]: On-the-fly switching of CMake generators (flexible build tree recreation) results in broken partial reconfiguration
The following issue has been SUBMITTED. == http://www.itk.org/Bug/view.php?id=13257 == Reported By:Andreas Mohr Assigned To: == Project:CMake Issue ID: 13257 Category: CMake Reproducibility:have not tried Severity: major Priority: normal Status: new == Date Submitted: 2012-05-30 04:45 EDT Last Modified: 2012-05-30 04:45 EDT == Summary:On-the-fly switching of CMake generators (flexible build tree recreation) results in broken partial reconfiguration Description: To investigate configuration issues with a certain CMakeCache.txt setup, it would be *very helpful* to be able to create a new *pristine* build directory, copy the old sufficiently complex (too many settings to try to figure out individually) CMakeCache.txt there, adapt CMakeCache.txt's build directory entries to the new name of the sibling directory, and then run e.g. "cmake -DCMAKE_GENERATOR="Unix Makefiles" ." (WITHIN BUILD TREE) to let CMake *re*create an entirely fresh build tree yet with a *slightly* different configuration (in this case, switching the generator). Well... this actually works. Going from a previous Ninja-based build tree, the new build directory now actually gets a full Makefile-based hierarchy created. Except... it falls flat on its face, since CMAKE_MAKE_PROGRAM and CMAKE_BUILD_TOOL remain set to the old Ninja-based arguments and don't get overridden to a Makefile-side setting when reconfiguring CMAKE_GENERATOR. Bad doggy, no cake today. Manually correcting the two cache variables to contain correct Makefile-side entries does seem to make everything work as expected (successfully test-builds an entire library target using make). Summary: - we want to play some thoroughly helpful tricks - it *almost* works - yet some stupid remaining non-overridden parts prevent it from working - Majorly annoying bug?? Hell yeah, we've got a winner... The question would be how to change CMake to handle it properly. Possibly required steps: 1. add detection to correctly realize that there's a change in CMAKE_GENERATOR setting (from old to new) 2. override CMAKE_MAKE_PROGRAM (or simply kill cache variable, to then simply automatically have it configured later) 3. dito with CMAKE_BUILD_TOOL I chose to initially indicate Severity "major" since it breaks an IMHO very useful feature. Thanks! Steps to Reproduce: See initial paragraph in text above. == Issue History Date ModifiedUsername FieldChange == 2012-05-30 04:45 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 0013258]: valgrind reports memory problems in cmIfCommand.cxx
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=13258
==
Reported By:Clinton Stimpson
Assigned To:
==
Project:CMake
Issue ID: 13258
Category: CMake
Reproducibility:always
Severity: major
Priority: normal
Status: new
==
Date Submitted: 2012-05-30 11:29 EDT
Last Modified: 2012-05-30 11:29 EDT
==
Summary:valgrind reports memory problems in cmIfCommand.cxx
Description:
Using DeployQt4.cmake, I can get some odd behavior.
Steps to Reproduce:
find_package(Qt4)
include(${QT_USE_FILE})
add_executable(myapp myapp.cpp)
target_link_libraries(myapp ${QT_LIBRARIES})
install(TARGETS myapp DESTINATION .)
include(DeployQt4)
install_qt4_executable(myapp "qtiff;qico")
Run cmake. No build or install necessary to see the problem.
Additional Information:
Valgrind reports:
==30955== Invalid read of size 8
==30955==at 0x55DA147: __GI___strncasecmp_l (strcmp.S:215)
==30955==by 0x5590EDA: strtod_l_internal (strtod_l.c:566)
==30955==by 0x711377: (anonymous namespace)::GetBooleanValue(std::string&,
cmMakefile*) (cmIfCommand.cxx:242)
That's triggered by the if(${executable_path}) at DeployQt4.cmake line 101, and
it appears that executable_path is populated with an unrelated variable.
==
Issue History
Date ModifiedUsername FieldChange
==
2012-05-30 11:29 Clinton StimpsonNew 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 0013261]: Default value of CMAKE_FIND_FRAMEWORK can not be overridden from the command line
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13261 == Reported By:Charlie Sharpsteen Assigned To: == Project:CMake Issue ID: 13261 Category: CMake Reproducibility:always Severity: major Priority: high Status: new == Date Submitted: 2012-05-30 13:43 EDT Last Modified: 2012-05-30 13:43 EDT == Summary:Default value of CMAKE_FIND_FRAMEWORK can not be overridden from the command line Description: `CMAKE_FIND_FRAMEWORK` always has a value of `FIRST` even if a user passes an argument such as `-DCMAKE_FIND_FRAMEWORK=LAST` when configuring a project. This is due to an unguarded default in the platform file `Darwin.cmake` that always overrides user input. See the following thread on the mailing list for more details: http://cmake.3232098.n2.nabble.com/Why-does-CMAKE-FIND-FRAMEWORK-always-default-to-FIRST-ignoring-command-line-definitions-tp7521759.html Patch attached which adds guards to the default in `Darwin.cmake`. No changes in the CMake testsuite were noticed after applying the patch. == Issue History Date ModifiedUsername FieldChange == 2012-05-30 13:43 Charlie SharpsteenNew Issue 2012-05-30 13:43 Charlie SharpsteenFile Added: 0001-Add-guards-to-CMAKE_FIND_FRAMEWORK-default.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 0013262]: unlimited appending to SDL_LIBRARY_TEMP in FindSDL.cmake
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=13262 == Reported By:-jK- Assigned To: == Project:CMake Issue ID: 13262 Category: (No Category) Reproducibility:have not tried Severity: minor Priority: normal Status: new == Date Submitted: 2012-05-30 14:17 EDT Last Modified: 2012-05-30 14:17 EDT == Summary:unlimited appending to SDL_LIBRARY_TEMP in FindSDL.cmake Description: Every call to FIND_PACKAGE(SDL) (even when cached) it appends "/usr/lib/libSDLmain.a;" to SDL_LIBRARY_TEMP causing a very long string after some runs. == Issue History Date ModifiedUsername FieldChange == 2012-05-30 14:17 -jK- 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 0013263]: SOURCES target property (get_property()) has very inconsistent result - wildly differing path specifications
The following issue has been SUBMITTED.
==
http://www.itk.org/Bug/view.php?id=13263
==
Reported By:Andreas Mohr
Assigned To:
==
Project:CMake
Issue ID: 13263
Category: CMake
Reproducibility:always
Severity: major
Priority: normal
Status: new
==
Date Submitted: 2012-06-01 08:41 EDT
Last Modified: 2012-06-01 08:41 EDT
==
Summary:SOURCES target property (get_property()) has very
inconsistent result - wildly differing path specifications
Description:
The appended sample yields the following output:
[amoh@lxamoh build]$ cmake ..
tgt_sources
main.cpp;[TEST_ROOT]/get_property_sources_broken_paths/test.rc;blubb.tas
-- Configuring done
CMake Error at CMakeLists.txt:17 (add_library):
Cannot find source file:
blubb.tas
Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp
.hxx .in .txx
-- Build files have been written to:
[TEST_ROOT]/get_property_sources_broken_paths/build
Note the very inconsistent items in the tgt_sources line shown above:
For (I assume) all language-related files a project-*relative* path will be
preserved, whereas for *existing* foreign-language files the *absolute* path to
the project-contained file (due to the result returned by the existence check?)
will be delivered, plus for *non-existing* foreign-language files the *relative*
path will be returned.
Whoa.
Since AFAIK it is recommended practice to add all files within a project to the
target (well, at least *.c* and *.h*, maybe NOT *.rc* and other more foreign
files?), this inconsistency is an annoying PROBLEM if detected, and a very
annoying BUG if undetected.
Thanks!
Steps to Reproduce:
cmake_minimum_required(VERSION 2.6)
project(get_property_sources_broken_paths)
file(WRITE main.cpp "
int main()
{
#include \"get_property_sources_broken_paths.h\"
return 0;
}
")
file(WRITE test.rc "")
#add_executable(get_property_sources_broken_paths main.cpp test.rc blubb.tas)
add_library(get_property_sources_broken_paths SHARED main.cpp test.rc blubb.tas)
get_property(tgt_sources TARGET get_property_sources_broken_paths PROPERTY
SOURCES)
message("tgt_sources ${tgt_sources}")
==
Issue History
Date ModifiedUsername FieldChange
==
2012-06-01 08:41 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 0013265]: Docs for --find-package should cross-reference CMakeFindPackageMode
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=13265 == Reported By:Dave Abrahams Assigned To: == Project:CMake Issue ID: 13265 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2012-06-02 18:59 EDT Last Modified: 2012-06-02 18:59 EDT == Summary:Docs for --find-package should cross-reference CMakeFindPackageMode Description: Since all the necessary settings are documented there. == Issue History Date ModifiedUsername FieldChange == 2012-06-02 18:59 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 0013266]: --find-package seems to be unworkable
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=13266 == Reported By:Dave Abrahams Assigned To: == Project:CMake Issue ID: 13266 Category: CMake Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 2012-06-02 19:01 EDT Last Modified: 2012-06-02 19:01 EDT == Summary:--find-package seems to be unworkable Description: cmake --find-package -DNAME=BZip2 -DCOMPILER_ID=GNU -DLANGUAGE=C -DMODE=LINK CMake Error at /opt/local/share/cmake-2.8/Modules/CheckLibraryExists.cmake:44 (TRY_COMPILE): The TRY_COMPILE() command is not supported in --find-package mode. Call Stack (most recent call first): /opt/local/share/cmake-2.8/Modules/FindBZip2.cmake:49 (CHECK_LIBRARY_EXISTS) /opt/local/share/cmake-2.8/Modules/CMakeFindPackageMode.cmake:167 (find_package) BZip2 not found. CMake Error: Problem processing arguments. Aborting. == Issue History Date ModifiedUsername FieldChange == 2012-06-02 19:01 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 0013268]: no argument specified with option '/machine:'
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=13268 == Reported By:Dave Abrahams Assigned To: == Project:CMake Issue ID: 13268 Category: CMake Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 2012-06-04 00:32 EDT Last Modified: 2012-06-04 00:32 EDT == Summary:no argument specified with option '/machine:' Description: Linking CXX executable quickbook.exe LINK : fatal error LNK1146: no argument specified with option '/machine:' LINK failed. with 2 NMAKE : fatal error U1077: 'C:\Users\dave\AppData\Local5a0cabb024c16b35116825b20f5d680a5ef08286install.net\implementat ions\sha1new=b003816f70afe2941763cf089f6c9d6ff2f09c44\bin\cmake.exe' : return code '0x' Steps to Reproduce: Outlined in detail at https://github.com/ryppl/ryppl/wiki/Setting-up-a-Ryppl-test/f10de6d5a88708b17b136e73f529ee272bc4c087 == Issue History Date ModifiedUsername FieldChange == 2012-06-04 00:32 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 0013269]: Improved documentation for "set" command
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13269 == Reported By:sleske Assigned To: == Project:CMake Issue ID: 13269 Category: Documentation Reproducibility:N/A Severity: minor Priority: normal Status: new == Date Submitted: 2012-06-04 20:55 CEST Last Modified: 2012-06-04 20:55 CEST == Summary:Improved documentation for "set" command Description: The documentation of the "set" command is incomplete and somewhat confusing (as shown by problems like those described in http://public.kitware.com/Bug/view.php?id=9008). I have tried to improve the documentation; see attached patch. Disclaimer: I'm new to CMake, so there may still be errors; feel free to correct them, or point them out so I can fix them. Additional Information: The attached patch is against CMake master HEAD from today (2012-06-04). == Issue History Date ModifiedUsername FieldChange == 2012-06-04 20:55 sleske New Issue 2012-06-04 20:55 sleske File Added: set-doc-2012-06-04.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 0013270]: Remove "temporary" debug message for ASM compiler id
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=13270
==
Reported By:raspy
Assigned To:
==
Project:CMake
Issue ID: 13270
Category: (No Category)
Reproducibility:always
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2012-06-05 04:05 EDT
Last Modified: 2012-06-05 04:05 EDT
==
Summary:Remove "temporary" debug message for ASM compiler id
Description:
This is regarding commit 9071b8b87f0e63f10f1f77949246c1b4241cfb6c.
Please remove this "temporary" message. After over a year in code it is no
longer temporary and its output is confusing users and is pure garbage in build
log. We use TI assembler so it barfs out many times before it is detected.
Please also do not put such "temporary" "debug" messages in official release
builds. It is confusing users and builders.
Steps to Reproduce:
Set CMAKE_C_COMPILER in a toolchain file to cl6x and then set CMAKE_ASM_COMPILER
to ${CMAKE_C_COMPILER}. Upon ASM configuration it barfs out all kind of compiler
versions and usages.
Additional Information:
Commit 4b40d4297aa7b984e9b5fa905cdee21960ec4f8a changed behavior for assembler
(which I consider a breaking change when connected to this faulty commit
9071b8b87f0e63f10f1f77949246c1b4241cfb6c).
In cmake 2.8.8 (and 2.8.6 at least, but probably somewhere around 2.8.4/5) when
CMAKE_ASM_COMPILER is not set it is taken from CMAKE_C_COMPILER (this is
4b40d4297aa7b984e9b5fa905cdee21960ec4f8a - a good thing). This is the only way
to avoid this faulty behavior of 9071b8b87f0e63f10f1f77949246c1b4241cfb6c and to
keep output silent when detecting ASM compiler id, so I need to remove setting
CMAKE_ASM_COMPILER(_INIT)? from toolchain file. This however will no longer work
with cmake 2.8.3 which does not have behavior from
4b40d4297aa7b984e9b5fa905cdee21960ec4f8a and it default to /usr/bin/as in such
situation.
==
Issue History
Date ModifiedUsername FieldChange
==
2012-06-05 04:05 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 0013271]: is_file_executable() from GetPrerequisites.cmake erroneously returns 0 for universal binaries (MacOSX)
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=13271
==
Reported By:recryn
Assigned To:
==
Project:CMake
Issue ID: 13271
Category: CMake
Reproducibility:always
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2012-06-05 18:01 CEST
Last Modified: 2012-06-05 18:01 CEST
==
Summary:is_file_executable() from GetPrerequisites.cmake
erroneously returns 0 for universal binaries (MacOSX)
Description:
On UNIX is_file_executable() executes the tool 'file' and then compares the
returned string with "executable": if("${file_ov}" MATCHES "executable")
However, on MacOSX, there are several 'file' tools available (macports, fink)
which do not share the same output format. Most notably, the output string does
not always match "executable" if the file is a universal binary. Here are some
possible output strings of 'file' for three different executables on a Mac:
Mach-O executable i386
Mach-O 64-bit executable
Mach-O fat file with 2 architectures
'file /bin/ls' results just in:
/bin/ls: Mach-O fat file with 2 architectures
Note, that a library would be reported as: "Mach-O 64-bit dynamically linked
shared library". So matching Mach-O is no good either.
Ideally is_file_executable() would call 'otool -hv' on APPLE and match the
result with "EXECUTE", e.g.:
otool -hv /bin/ls
/bin/ls:
Mach header
magic cputype cpusubtype capsfiletype ncmds sizeofcmds flags
MH_MAGIC_64 X86_64ALL LIB64 EXECUTE13 1928 NOUNDEFS
DYLDLINK TWOLEVEL
Steps to Reproduce:
1. Install 'file' from macports:
port install file
2. Prepend macports binary dir (/opt/local/bin) to PATH
3. With a project that uses fixup_bundle:
cmake -DCMAKE_OSX_ARCHITECTURES="x86_64;i386"
make
cpack -G Bundle --verbose
[...]
CPack Verbose: libs=''
CPack Verbose: dirs=''
CPack Verbose: warning: *NOT* handled - not .app dir, not executable file...
CMake Error at /opt/local/share/cmake-2.8/Modules/MyBundleUtilities.cmake:723
(message):
error: fixup_bundle: not a valid bundle
Call Stack (most recent call first):
/tmp/trunk/build/cmake/dist/cmake_install.cmake:38 (fixup_bundle)
/tmp/trunk/build/cmake_install.cmake:36 (INCLUDE)
Additional Information:
Patch attached.
==
Issue History
Date ModifiedUsername FieldChange
==
2012-06-05 18:01 recryn New Issue
2012-06-05 18:01 recryn 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 0013272]: Use of [o]stringstream instead of strstream breaks the build on older systems
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13272 == Reported By:Daniel R. Gomez Assigned To: == Project:CMake Issue ID: 13272 Category: CMake Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 2012-06-05 16:03 EDT Last Modified: 2012-06-05 16:03 EDT == Summary:Use of [o]stringstream instead of strstream breaks the build on older systems Description: Most CMake code uses strstream when stringstream is not available. However, the following files in the git nightly branch currently do not: Source/cmQtAutomoc.cxx Source/cmGlobalNinjaGenerator.cxx Source/cmLocalNinjaGenerator.cxx Source/cmNinjaTargetGenerator.cxx Source/cmNinjaNormalTargetGenerator.cxx The build failures may be reviewed at http://open.cdash.org/viewBuildError.php?buildid=2336790 == Issue History Date ModifiedUsername FieldChange == 2012-06-05 16:03 Daniel R. GomezNew 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 0013273]: From g++: "sorry: semantics of inline function static data `...' are wrong" in hashtable.hxx
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13273 == Reported By:Daniel R. Gomez Assigned To: == Project:CMake Issue ID: 13273 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2012-06-05 16:13 EDT Last Modified: 2012-06-05 16:13 EDT == Summary:From g++: "sorry: semantics of inline function static data `...' are wrong" in hashtable.hxx Description: I see this warning when building CMake from git nightly with g++ 2.9-aix51-020209 on an AIX 5.3 system: CMake-build/Source/cmsys/hashtable.hxx: In function `const long unsigned int *cmsys::get_stl_prime_list ()': CMake-build/Source/cmsys/hashtable.hxx:399: warning: sorry: semantics of inline function static data `const long unsigned int _stl_prime_list[31]' are wrong (you'll wind up with multiple copies) CMake-build/Source/cmsys/hashtable.hxx:399: warning: you can work around this by removing the initializer (Details at http://open.cdash.org/viewBuildError.php?type=1&buildid=2336790) This can be fixed by making get_stl_prime_list() a static function, as in the attached patch. == Issue History Date ModifiedUsername FieldChange == 2012-06-05 16:13 Daniel R. GomezNew Issue 2012-06-05 16:13 Daniel R. GomezFile Added: cmake-hashtable-fix.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 0013274]: test_INT_C.c and test_INT_CXX.cxx fail to compile due to broken PRIxNN macros
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13274 == Reported By:Daniel R. Gomez Assigned To: == Project:CMake Issue ID: 13274 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2012-06-06 13:33 EDT Last Modified: 2012-06-06 13:33 EDT == Summary:test_INT_C.c and test_INT_CXX.cxx fail to compile due to broken PRIxNN macros Description: Building CMake git nightly on AIX 4.3 yields these errors: In file included from .../CMake/Utilities/KWIML/test/test_INT_C.c:14: .../CMake-build/Utilities/KWIML/test/test_INT_format.h: In function `test_INT_format': .../CMake-build/Utilities/KWIML/test/test_INT_format.h:106: `hi' undeclared (first use in this function) .../CMake-build/Utilities/KWIML/test/test_INT_format.h:106: (Each undeclared identifier is reported only once .../CMake-build/Utilities/KWIML/test/test_INT_format.h:106: for each function it appears in.) .../CMake-build/Utilities/KWIML/test/test_INT_format.h:108: parse error before string constant .../CMake-build/Utilities/KWIML/test/test_INT_format.h:110: `hd' undeclared (first use in this function) .../CMake-build/Utilities/KWIML/test/test_INT_format.h:112: parse error before string constant [...] (Refer to http://open.cdash.org/viewBuildError.php?buildid=2337121 for the full list) This platform has a long-standing issue with broken PRIxNN format macros in /usr/include/inttypes.h. An excerpt: #define PRId8 %hd #define PRId16 %hd #define PRId32 %d #if defined(__64BIT__) #define PRId64 %ld #else #if defined(_LONG_LONG) #define PRId64 %lld #endif #endif On the Autoconf side, Gettext has an m4 macro gt_INTTYPES_PRI that checks for this: https://gnunet.org/svn/Extractor/m4/inttypes-pri.m4 CMake could probably avoid the use of inttypes.h on this system altogether; the above files compile correctly with -DcmIML_INT_NO_INTTYPES_H. Either that, or it needs to know to use its own format-string macros instead of the system's. == Issue History Date ModifiedUsername FieldChange == 2012-06-06 13:33 Daniel R. GomezNew 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 0013275]: Assembly source files are not recognized by Xcode 4.3.2 due to lastKnownFileType
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=13275 == Reported By:Lasse Öörni Assigned To: == Project:CMake Issue ID: 13275 Category: CMake Reproducibility:always Severity: major Priority: high Status: new == Date Submitted: 2012-06-06 19:40 EDT Last Modified: 2012-06-06 19:40 EDT == Summary:Assembly source files are not recognized by Xcode 4.3.2 due to lastKnownFileType Description: When a Xcode project is generated by CMake, and the project contains assembly (.S) files, the lastKnownFileType for the assembly files is set to "sourcecode" and as a result Xcode 4.3.2 does not know to invoke the assembler on them. The lastKnownFileType should be "sourcecode.asm". == Issue History Date ModifiedUsername FieldChange == 2012-06-06 19:40 Lasse ÖörniNew 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 0013277]: archive_endian.h needs "inline" fix for Sun WorkShop (SunPro) compiler
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=13277
==
Reported By:Daniel R. Gomez
Assigned To:
==
Project:CMake
Issue ID: 13277
Category: CMake
Reproducibility:always
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2012-06-07 12:57 EDT
Last Modified: 2012-06-07 12:57 EDT
==
Summary:archive_endian.h needs "inline" fix for Sun WorkShop
(SunPro) compiler
Description:
Building CMake's git nightly on a Solaris 8 system with the SunPro compiler
yields
[ 38%] Building C object
Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_read_support_filter_rpm.c.o
".../CMake/Utilities/cmlibarchive/libarchive/archive_endian.h.", line 59:
undefined or not a type: inline
".../CMake/Utilities/cmlibarchive/libarchive/archive_endian.h", line 61:
parameter not in identifier list: archive_be16dec
".../CMake/Utilities/cmlibarchive/libarchive/archive_endian.h", line 61: syntax
error before or at: {
[...]
(See http://open.cdash.org/viewBuildError.php?buildid=2340544 for more)
This compiler doesn't grok "inline"---at least not version 5.1.
A proposed patch (against git nightly) that addresses this is attached. The
macro magic is gleaned from
http://lists.x.org/archives/xorg-devel/2009-April/000580.html .
==
Issue History
Date ModifiedUsername FieldChange
==
2012-06-07 12:57 Daniel R. GomezNew Issue
2012-06-07 12:57 Daniel R. GomezFile Added: cmake-sunpro-inline-fix.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 0013280]: setting CMAKE_C_COMPILER and CMAKE_CXX_COMPILER breaks find_package
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13280 == Reported By:Alex Herrmann Assigned To: == Project:CMake Issue ID: 13280 Category: CMake Reproducibility:always Severity: major Priority: low Status: new == Date Submitted: 2012-06-07 15:44 EDT Last Modified: 2012-06-07 15:44 EDT == Summary:setting CMAKE_C_COMPILER and CMAKE_CXX_COMPILER breaks find_package Description: Hello, I just built gcc-4.7 in my /opt/ directory, and I would like to cmake to compile using those binaries. However, whenever I specify the C and CXX compiler with -D or set() commands, it always complains about it not being able to find anything. Steps to Reproduce: Specify CMAKE_C_COMPILER and CMAKE_CXX_COMPILER, and try to find() something. More specifically for me include(FindPNG) or include(FindJPEG), nothing like this works. Additional Information: I have a feeling this isn't a bug, and I've tried setting just about variable I can think to right this, but until this is fixed, my software is much less portable. == Issue History Date ModifiedUsername FieldChange == 2012-06-07 15:44 Alex Herrmann 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 0013281]: the module UseJava reports a warning when find_jar is used with a list of NAMES
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=13281 == Reported By:renzodenardi Assigned To: == Project:CMake Issue ID: 13281 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2012-06-08 07:39 EDT Last Modified: 2012-06-08 07:39 EDT == Summary:the module UseJava reports a warning when find_jar is used with a list of NAMES Description: when the command find_jar is used with multiple jar names e.g. find_jar(PROTO_JAVA NAMES protobuf protobuf-java) cmake reports a warning: CMake Warning at cmake/Modules/UseJava.cmake:523 (if): given arguments: "protobuf" "protobuf-java" "STREQUAL" "" Unknown arguments specified Call Stack (most recent call first): CMakeLists.txt:75 (find_jar) Steps to Reproduce: use the following as a CMakeLists.txt PROJECT(TEST) CMAKE_MINIMUM_REQUIRED(VERSION 2.8) set(PACKAGE_NAME"test") FIND_PACKAGE(Java) INCLUDE(UseJava) find_jar(PROTO_JAVA NAMES a_name another_name) Additional Information: as far as I understand this is due to the fact that the variable _jar_names in the function find_jar is actually a list, therefore the correct way of checking if it is empty is to test its length. A patch is attached. == Issue History Date ModifiedUsername FieldChange == 2012-06-08 07:39 renzodenardi New Issue 2012-06-08 07:39 renzodenardi File Added: UseJava.cmake.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 0013282]: No way to explicitly specify shared library exported symbols with xlc on AIX
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=13282
==
Reported By:brett.dellegrazie
Assigned To:
==
Project:CMake
Issue ID: 13282
Category: CMake
Reproducibility:always
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2012-06-08 10:41 EDT
Last Modified: 2012-06-08 10:41 EDT
==
Summary:No way to explicitly specify shared library exported
symbols with xlc on AIX
Description:
Hi,
The definition for the XLC compiler (modules/Compiler/XL.cmake) on AIX includes
the explicit call to the CMAKE_XL_CreateExportList (IBM's CreateExportList tool)
as follows:
set(CMAKE_${lang}_CREATE_SHARED_LIBRARY
"${CMAKE_XL_CreateExportList} /objects.exp "
"
-Wl,-bE:/objects.exp
-o
"
)
Note the first line of the script:
${CMAKE_XL_CreateExportList} /objects.exp
This generates an export file in the objects dir which:
(a) Fails to build if there are no objects, because the file will not exist if
there are no objects. Linking several static libraries together to make a shared
library will cause this. In our case the static libraries are externally
supplied and no source code is available (just headers). There's no way of
creating a shared library version without manually generating an empty
objects.exp file in the OBJECTS_DIR directory.
(b) Prevents the use of any explicit exports file in the general case
Is there any possibility of making this an optional per-target task (such as a
PRE_LINK step) that can be disabled?
Its certainly easy enough to add an explicit exports file to the LINK_FLAGS on a
per-target basis but there's no way of disabling the default export creation
without resorting to replicating the XL.cmake file and modifying the CMake
policy 0017 so cmake picks up the modified version (not maintainable long-term)
Steps to Reproduce:
1. requires IBM xlc compiler on AIX.
case A: Fails due to missing objects.exp:
PROJECT(test_case_a)
cmake_minimum_required(VERSION 2.8)
# Libraries myA and myB are static, externally supplied with header files
# Doesn't matter if these are C or C++, the same problem occurs with both
# In this case though, assume C libraries for linking purposes
set( myA_SRCS myA.h )
set( myB_SRCS myB.h )
# Static libraries
add_library( myA STATIC IMPORTED )
set_target_properties( myA PROPERTIES IMPORTED_LOCATION
${CMAKE_CURRENT_SOURCE_DIR}/myA.a )
add_library( myB STATIC IMPORTED )
set_target_properties( myB PROPERTIES IMPORTED_LOCATION
${CMAKE_CURRENT_SOURCE_DIR}/myB.a )
# Create shared library variant of both
add_library( myC SHARED ${A_SRCS} ${B_SRCS} )
set_target_properties( myC PROPERTIES
LINKER_LANGUAGE C
PUBLIC_HEADER "${A_SRCS}" "${B_SRCS}"
)
target_link_libraries( myC myA myB )
Additional Information:
A workaround would be to:
1) disable policy CMP0017
2) Supply our own copy of modules/Compiler/XL.cmake
Removing the entire "if (CMAKE_XL_CreateExportList)" section
This leaves the CMAKE_${lang}_SHARED_LIBRARY_CREATE rule at the default.
3) Supply the explicit export list as a compile / link flag per-target as
appropriate
==
Issue History
Date ModifiedUsername FieldChange
==
2012-06-08 10:41 brett.dellegrazieNew 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 0013286]: CMake always generates man pages in section 1
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13286 == Reported By:Alex Merry Assigned To: == Project:CMake Issue ID: 13286 Category: CMake Reproducibility:always Severity: minor Priority: low Status: new == Date Submitted: 2012-06-08 17:49 EDT Last Modified: 2012-06-08 17:49 EDT == Summary:CMake always generates man pages in section 1 Description: When generating a man page with CMake, such as by doing cmake --help-custom-modules cmake-custom-modules.7 CMake will always write the man page header as though the module were in section 1, even if the filename indicates that it is in another section. In the case of the example above, sections 3 or 7 would be appropriate for module help, not section 1. Steps to Reproduce: cmake --help-custom-modules cmake-custom-modules.7 == Issue History Date ModifiedUsername FieldChange == 2012-06-08 17:49 Alex Merry 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 0013287]: Eclipse CDT: Parallel builds enabled only for make targets
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=13287 == Reported By:Chris Stankevitz Assigned To: == Project:CMake Issue ID: 13287 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2012-06-08 18:36 EDT Last Modified: 2012-06-08 18:36 EDT == Summary:Eclipse CDT: Parallel builds enabled only for make targets Description: Using Eclipse Indigo, I have enabled parallel builds by setting CMAKE_ECLIPSE_MAKE_ARGUMENTS=-j4 CMAKE_ECLIPSE_VERSION=3.7 (Indigo) CMake creates many "make targets" each with a "make target Build command" of "/usr/bin/gmake -j4". This is correct. CMake also creates a single "project" with a "project Build command" of "/usr/bin/gmake". This is incorrect. It should have the -j4 suffix. You can view the "project Build command" from Eclipse by selecting Project | Properties | C/C++ Make Project | Make Builder | Build command (see attached) Thank you, Chris == Issue History Date ModifiedUsername FieldChange == 2012-06-08 18:36 Chris StankevitzNew Issue 2012-06-08 18:36 Chris StankevitzFile Added: project-build-command.png == -- 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 0013288]: ccmake screen cluttered by stray text when using the -C option
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=13288
==
Reported By:zub
Assigned To:
==
Project:CMake
Issue ID: 13288
Category: CCMake
Reproducibility:always
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2012-06-08 19:28 EDT
Last Modified: 2012-06-08 19:28 EDT
==
Summary:ccmake screen cluttered by stray text when using the
-C option
Description:
When -C option (initial cache file) is used with ccmake the screen is cluttered
by a stray text ("loading initial cache file"). See attached screenshot.
Looks like a stray printf breaking the otherwise curses-managed screen.
The stray message is annoying and it can obscure important fields.
Steps to Reproduce:
1. create an initial cmake cache file (empty file is ok)
2. create a hello world cmake project
3. run: ccmake . -Cyour-initial-cache-file
4. press 'c' to run the configure step
5. observe the stray text (pressing 'c' again causes another occurrence of the
text, always at the current position of the cursor)
Or just use the attached testcase (unpack, execute ./run.sh).
==
Issue History
Date ModifiedUsername FieldChange
==
2012-06-08 19:28 zubNew Issue
2012-06-08 19:28 zubFile Added: ccmake-initial-cache-bug.png
==
--
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 0013289]: In some cases, add_library( OBJECT ...) failure with unexpected warnings.
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13289 == Reported By:monaka Assigned To: == Project:CMake Issue ID: 13289 Category: CMake Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 2012-06-09 03:03 EDT Last Modified: 2012-06-09 03:03 EDT == Summary:In some cases, add_library( OBJECT ...) failure with unexpected warnings. Description: In case TARGET_SUPPORT_SHARED_LIBS is false, Calling add_library(... OBJECT ...) will get warnings below. "ADD_LIBRARY for library foobar is used with the MODULE option, but the target platform supports only STATIC libraries. Building it STATIC instead. This may lead to problems." And type is forced to cmTarget::STATIC_LIBRARY. Actually adding "object library" will succeed even if its target isn't support shared libs. The current implementation is unsuitable, I think. == Issue History Date ModifiedUsername FieldChange == 2012-06-09 03:03 monaka 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 0013291]: find_path(WIN32_INCLUDE_DIR windows.h) does not work with Visual Studio 10 generator
The following issue has been SUBMITTED.
==
http://cmake.org/Bug/view.php?id=13291
==
Reported By:Dimitri Merejkowsky
Assigned To:
==
Project:CMake
Issue ID: 13291
Category: CMake
Reproducibility:always
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2012-06-11 09:58 EDT
Last Modified: 2012-06-11 09:58 EDT
==
Summary:find_path(WIN32_INCLUDE_DIR windows.h) does not work
with Visual Studio 10 generator
Description:
Using find_path to find headers from the Microsoft SDK does not work
when using the Visual Studio 10 generator.
Steps to Reproduce:
CMakeLists.txt looking like:
cmake_minimum_required(VERSION 2.8.8)
project(foo C)
find_path(WIN32_INC windows.h)
message(STATUS "WIN32_INC: ${WIN32_INC}")
Ran from normal cmd.exe:
> cmake ..
-- Building for: Visual Studio 10
-- Check for working C compiler using: Visual Studio 10
-- Check for working C compiler using: Visual Studio 10 -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- WIN32_INC: WIN32_INC-NOTFOUND
-- Configuring done
-- Generating done
-- Build files have been written to: C:/Users/dmerejkowsky/work/tmp/cmake_bug/b
Additional Information:
Note that this works when ran from Microsoft Visual Studio command prompt:
> cmake -G "NMake Makefiles" ..
-- The C compiler identification is MSVC 16.0.30319.1
-- Check for CL compiler version
-- Check for CL compiler version - 1600
-- Check if this is a free VC compiler
-- Check if this is a free VC compiler - no
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio
10.0/VC/bin/cl.exe
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio
10.0/VC/bin/cl.exe -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- WIN32_INC: C:/Program Files (x86)/Microsoft SDKs/Windows/v7.0A/Include
-- Configuring done
-- Generating done
-- Build files have been written to: C:/Users/dmerejkowsky/work/tmp/cmake_bug/b
==
Issue History
Date ModifiedUsername FieldChange
==
2012-06-11 09:58 Dimitri MerejkowskyNew 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 0013292]: Windows : CMake Does Not Define _CONSOLE When Not Building A Win32 Target
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13292 == Reported By:Ryan H. Kawicki Assigned To: == Project:CMake Issue ID: 13292 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2012-06-11 16:24 EDT Last Modified: 2012-06-11 16:24 EDT == Summary:Windows : CMake Does Not Define _CONSOLE When Not Building A Win32 Target Description: Command add_executable does not define _CONSOLE when WIN32 is not specified. Expected that final output would have _CONSOLE defined for preprocessor definitions if WIN32 is not specified and _WINDOWS when WIN32 is specified. Steps to Reproduce: Create a very simple test with one single file. Additional Information: project(test-console) add_executable(test test.cpp) # the generated project has _WINDOWS define when _CONSOLE should be defined. == Issue History Date ModifiedUsername FieldChange == 2012-06-11 16:24 Ryan H. KawickiNew 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 0013293]: INTERNAL: Cache value overwritten without a FORCE option set.
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=13293
==
Reported By:Michael.jeulinl
Assigned To:
==
Project:CMake
Issue ID: 13293
Category: CMake
Reproducibility:always
Severity: feature
Priority: normal
Status: new
==
Date Submitted: 2012-06-11 18:44 EDT
Last Modified: 2012-06-11 18:44 EDT
==
Summary:INTERNAL: Cache value overwritten without a FORCE
option set.
Description:
On INTERNAL type, the cache value is overwritten without a FORCE option set.
Steps to Reproduce:
cmake_minimum_required(VERSION 2.8.8)
#
# From CMake 2.8.8 documentation:
#
# If is INTERNAL, then the is always written into the cache,
replacing any values
# existing in the cache. If it is not a cache variable, then this always writes
into the current
# makefile. The FORCE option will overwrite the cache value removing any changes
by the user.
#
project(testSetInternal)
message(STATUS "0-Foo:${Foo}")
set(Foo TrueFoo CACHE STRING "Foo value" FORCE)
message(STATUS "1-Foo:${Foo}")
set(Foo Foo CACHE STRING "Foo value")
message(STATUS "2-Foo:${Foo}")
message(STATUS "0-Bar:${Bar}")
set(Bar TrueBar CACHE INTERNAL "Bar value" FORCE)
message(STATUS "1-Bar:${Bar}")
set(Bar Bar CACHE INTERNAL "Bar value")
message(STATUS "2-Bar:${Bar}")
==
Issue History
Date ModifiedUsername FieldChange
==
2012-06-11 18:44 Michael.jeulinlNew 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 0013294]: patch to CheckC(XX)CompilerFlag.cmake to match ICC output
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=13294
==
Reported By:Matthias Kretz
Assigned To:
==
Project:CMake
Issue ID: 13294
Category: Modules
Reproducibility:always
Severity: feature
Priority: normal
Status: new
==
Date Submitted: 2012-06-12 12:32 EDT
Last Modified: 2012-06-12 12:32 EDT
==
Summary:patch to CheckC(XX)CompilerFlag.cmake to match ICC
output
Description:
The Intel compiler reports http://public.kitware.com/Bug/view.php?id=10159 if
you pass "-std=c++11", which it doesn't support yet.
diff --git a/cmake/CheckCCompilerFlag.cmake b/cmake/CheckCCompilerFlag.cmake
index 9e698b2..3c904dd 100644
--- a/cmake/CheckCCompilerFlag.cmake
+++ b/cmake/CheckCCompilerFlag.cmake
@@ -36,6 +36,7 @@ MACRO (CHECK_C_COMPILER_FLAG _FLAG _RESULT)
FAIL_REGEX "[Ww]arning: [Oo]ption" # SunPro
FAIL_REGEX "command option .* is not recognized" # XL
FAIL_REGEX "WARNING: unknown flag:"# Open64
+ FAIL_REGEX " http://public.kitware.com/Bug/view.php?id=10159: "
# ICC
)
SET (CMAKE_REQUIRED_DEFINITIONS "${SAFE_CMAKE_REQUIRED_DEFINITIONS}")
ENDMACRO (CHECK_C_COMPILER_FLAG)
diff --git a/cmake/CheckCXXCompilerFlag.cmake b/cmake/CheckCXXCompilerFlag.cmake
index b016cae..fccc97b 100644
--- a/cmake/CheckCXXCompilerFlag.cmake
+++ b/cmake/CheckCXXCompilerFlag.cmake
@@ -36,6 +36,7 @@ MACRO (CHECK_CXX_COMPILER_FLAG _FLAG _RESULT)
FAIL_REGEX "[Ww]arning: [Oo]ption" # SunPro
FAIL_REGEX "command option .* is not recognized" # XL
FAIL_REGEX "WARNING: unknown flag:"# Open64
+ FAIL_REGEX " http://public.kitware.com/Bug/view.php?id=10159: "
# ICC
)
SET (CMAKE_REQUIRED_DEFINITIONS "${SAFE_CMAKE_REQUIRED_DEFINITIONS}")
ENDMACRO (CHECK_CXX_COMPILER_FLAG)
Steps to Reproduce:
check_cxx_compiler_flag("-std=bogus" test)
test should be FALSE
==
Issue History
Date ModifiedUsername FieldChange
==
2012-06-12 12:32 Matthias Kretz 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 0013295]: find_package looks in wrong order of paths
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13295 == Reported By:Sune Vuorela Assigned To: == Project:CMake Issue ID: 13295 Category: CMake Reproducibility:always Severity: major Priority: high Status: new == Date Submitted: 2012-06-12 18:13 EDT Last Modified: 2012-06-12 18:13 EDT == Summary:find_package looks in wrong order of paths Description: On my system, I have among others /usr/lib/libgettextpo.a /usr/lib/x86_64-linux-gnu/libgettextpo.so trying to do a find_library(GETTEXTPO_LIBRARY NAMES gettextpo) gives me the static library, while I expected it to find the dynamic library. Steps to Reproduce: trying to build kdesdk master (or 4.9 prereleases) fails to build when trying to link libgettextpo.a into a shared library == Issue History Date ModifiedUsername FieldChange == 2012-06-12 18:13 Sune Vuorela 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 0013299]: Build should abort if moc fails
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=13299
==
Reported By:Stephen Kelly
Assigned To:
==
Project:CMake
Issue ID: 13299
Category: CMake
Reproducibility:always
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2012-06-13 16:06 EDT
Last Modified: 2012-06-13 16:06 EDT
==
Summary:Build should abort if moc fails
Description:
Add a signal which is templated (which causes moc to return an error), and run
the unit test. Instead of aborting when moc notifies an error, the build fails
later when attempting to include the generated file (using make -j1), as below.
As a failed moc run does not overwrite the target file, an old file can be left
behind, causing even the #include to work properly, hiding the bug.
Generating private_slot.moc
/home/stephen/dev/src/cmake/Tests/QtAutomoc/private_slot.h:15: Error: Template
function as signal or slot
AUTOMOC: error: process for
/home/stephen/dev/src/cmake/Tests/QtAutomoc/build/private_slot.moc failed:
/home/stephen/dev/src/cmake/Tests/QtAutomoc/private_slot.h:15: Error: Template
function as signal or slot
Generating sub/moc_bar.cpp
Generating moc_xyz.cpp
Generating yaf_p.moc
Generating moc_calwidget.cpp
Generating moc_foo.cpp
returning failed..
[ 28%] Built target foo_automoc
Scanning dependencies of target foo
[ 35%] Building CXX object CMakeFiles/foo.dir/main.cpp.o
[ 42%] Building CXX object CMakeFiles/foo.dir/calwidget.cpp.o
[ 50%] Building CXX object CMakeFiles/foo.dir/foo.cpp.o
[ 57%] Building CXX object CMakeFiles/foo.dir/blub.cpp.o
[ 64%] Building CXX object CMakeFiles/foo.dir/bar.cpp.o
[ 71%] Building CXX object CMakeFiles/foo.dir/abc.cpp.o
[ 78%] Building CXX object CMakeFiles/foo.dir/xyz.cpp.o
[ 85%] Building CXX object CMakeFiles/foo.dir/yaf.cpp.o
[ 92%] Building CXX object CMakeFiles/foo.dir/private_slot.cpp.o
/home/stephen/dev/src/cmake/Tests/QtAutomoc/private_slot.cpp:21:28: fatal error:
private_slot.moc: No such file or directory
compilation terminated.
make[2]: *** [CMakeFiles/foo.dir/private_slot.cpp.o] Error 1
make[1]: *** [CMakeFiles/foo.dir/all] Error 2
make: *** [all] Error 2
makeobj[0]: Leaving directory
`/home/stephen/dev/src/cmake/Tests/QtAutomoc/build'
Qt( 4.8 ) KDE ( )
stephen@hal:~/dev/src/cmake/Tests/QtAutomoc/build{master}$ git diff
diff --git a/Tests/QtAutomoc/private_slot.h b/Tests/QtAutomoc/private_slot.h
index 28e5448..b5177e3 100644
--- a/Tests/QtAutomoc/private_slot.h
+++ b/Tests/QtAutomoc/private_slot.h
@@ -12,6 +12,9 @@ class PrivateSlot : public QObject
public:
PrivateSlot(QObject *parent = 0);
+signals:
+ template void someSignal();
+
private:
PrivateSlotPrivate * const d;
Q_PRIVATE_SLOT(d, void privateSlot())
==
Issue History
Date ModifiedUsername FieldChange
[cmake-developers] [CMake 0013302]: Improve mechanism allowing to pass command line parameter to ctest script
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=13302
==
Reported By:Jean-Christophe Fillion-Robin
Assigned To:
==
Project:CMake
Issue ID: 13302
Category: CTest
Reproducibility:N/A
Severity: feature
Priority: normal
Status: new
==
Date Submitted: 2012-06-13 21:05 EDT
Last Modified: 2012-06-13 21:05 EDT
==
Summary:Improve mechanism allowing to pass command line
parameter to ctest script
Description:
When setting up dashboard it is sometimes useful to pass parameter to ctest
script.
A possible approach is to pass parameters doing the following:
ctest -S /path/to/script.cmake,OPTNAME1##OPTVALUE1^^OPTNAME2##OPTVALUE2
Then, the following code can be used in the called CTest script to "extract" the
associated value:
if(NOT CTEST_SCRIPT_ARG STREQUAL "")
string(REPLACE "^^" "\\;" CTEST_SCRIPT_ARG_AS_LIST "${CTEST_SCRIPT_ARG}")
set(CTEST_SCRIPT_ARG_AS_LIST ${CTEST_SCRIPT_ARG_AS_LIST})
foreach(argn_argv ${CTEST_SCRIPT_ARG_AS_LIST})
string(REPLACE "##" "\\;" argn_argv_list ${argn_argv})
set(argn_argv_list ${argn_argv_list})
list(GET argn_argv_list 0 argn)
list(GET argn_argv_list 1 argv)
set(${argn} ${argv})
endforeach()
endif()
When more complex value, like URL are passed as parameter, special characters
like ":" need also to be "encoded". See issue
http://public.kitware.com/Bug/view.php?id=12953
A mechanism similar to what's done with "cmake" executable could probably be
implemented. It means parameter could be passed using:
-DOPTNAME1:STRING=OPTVALUE1
==
Issue History
Date ModifiedUsername FieldChange
==
2012-06-13 21:05 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 0013303]: Strange issues when using "target_link_libraries" to link stlport and boost on XCode 4
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=13303
==
Reported By:tree
Assigned To:
==
Project:CMake
Issue ID: 13303
Category: CMake
Reproducibility:always
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2012-06-14 11:09 EDT
Last Modified: 2012-06-14 11:09 EDT
==
Summary:Strange issues when using "target_link_libraries" to
link stlport and boost on XCode 4
Description:
I orgnize stlport libraries in two directories like:
stlport/Debug/libstlportstlg.5.2.1.dylib (represented as A)
stlport/Release/libstlport.5.2.dylib (represented as B)
and then use command
target_link_libraries(taget debug ${A})
target_link_libraries(taget optimized ${B})
After generating XCode project, I found in "Building Settings/Other Linker
Flags", both the two libraries exist under both "Debug" and "RelWithDebInfo".
In happens to boost either. But for other libraries it works as expected.
==
Issue History
Date ModifiedUsername FieldChange
==
2012-06-14 11:09 tree 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 0013304]: rpmbuild -bb cmake.spec fails on CTestTestFailedSubmint-ftp
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13304 == Reported By:Shawn Adams Assigned To: == Project:CMake Issue ID: 13304 Category: (No Category) Reproducibility:always Severity: major Priority: high Status: new == Date Submitted: 2012-06-14 12:59 EDT Last Modified: 2012-06-14 12:59 EDT == Summary:rpmbuild -bb cmake.spec fails on CTestTestFailedSubmint-ftp Description: rpmbuild fails to compile cmake-2.8.8. CTestTestFailedSubmit-ftp fails with the following: "168/228 Test http://public.kitware.com/Bug/view.php?id=173: CTestTestFailedSubmit-ftp ...***Failed Required regular expression not found.Regex=[(Problems when submitting via S*CP|Error message was: ([Cc]ould *n.t resolve host|[Cc]ould *n.t connect to host|Empty reply from server|The requested URL returned error|libcurl was built with SSL disabled. https: not supported)|Submission method .xmlrpc. not compiled into CTest|Submission problem|Submission successful)" Steps to Reproduce: rpmbuild -bb ./SPECS/cmake.spec == Issue History Date ModifiedUsername FieldChange == 2012-06-14 12:59 Shawn AdamsNew Issue 2012-06-14 12:59 Shawn AdamsFile Added: cmake.spec == -- 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 0013306]: findglut bug
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=13306
==
Reported By:Jona
Assigned To:
==
Project:CMake
Issue ID: 13306
Category: Modules
Reproducibility:always
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2012-06-14 16:45 EDT
Last Modified: 2012-06-14 16:45 EDT
==
Summary:findglut bug
Description:
I have installed freeglut on my system, but FindGlut.cmake is unable to find it.
I have an enviroment variable called GLUT_ROOT_PATH but it is not used by the
skript.
I rewrote the script and now it works for me:
IF (WIN32)
FIND_PATH( GLUT_INCLUDE_DIR NAMES GL/glut.h
PATHS ENV GLUT_ROOT_PATH
PATH_SUFFIXES include
)
FIND_LIBRARY( GLUT_glut_LIBRARY NAMES glut glut32 freeglut
PATHS ENV OPENGL_LIBRARY_DIR GLUT_ROOT_PATH
PATH_SUFFIXES Release lib
)
ELSE (WIN32)
The old version was:
IF (WIN32)
FIND_PATH( GLUT_INCLUDE_DIR NAMES GL/glut.h
PATHS ${GLUT_ROOT_PATH}/include )
FIND_LIBRARY( GLUT_glut_LIBRARY NAMES glut glut32 freeglut
PATHS
${OPENGL_LIBRARY_DIR}
${GLUT_ROOT_PATH}/Release
)
ELSE (WIN32)
(as I can see, it uses the cmake variable GLUT_ROOT_PATH instead of the
enviromentvariable and doenst look inside /lib for the library.
==
Issue History
Date ModifiedUsername FieldChange
==
2012-06-14 16:45 Jona 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 0013307]: CPack Generators producing a single package only
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13307 == Reported By:Javier Assigned To: == Project:CMake Issue ID: 13307 Category: CPack Reproducibility:always Severity: major Priority: high Status: new == Date Submitted: 2012-06-14 17:36 EDT Last Modified: 2012-06-14 17:36 EDT == Summary:CPack Generators producing a single package only Description: When I try the component example as described in issue http://public.kitware.com/Bug/view.php?id=10736, sample downloaded from the links there, ZIP, TGZ, TG, STGZ generators generate a monolithic generator only. I downloaded CMake 2.8.3, and used the exact same example on the same environment, and the separate packages are generated correctly. Steps to Reproduce: 1) Download component example file: http://www.vtk.org/Wiki/File:ComponentExampleStart.zip 2) Run CMake with NMake Makefiles Generator. Running cpack -G ZIP will produce a single .zip file. Expected one per component. Repeat the above steps with CMake 2.8.3, and the result is several .zip files as expected. Additional Information: - Used CMake 2.8.8 - NMake Generator (Using Visual Studio 2008) - Didn't test this on Linux or OSX. == Issue History Date ModifiedUsername FieldChange == 2012-06-14 17:36 Javier 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 0013309]: FindBullet is missing a library name
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13309 == Reported By:Jona Assigned To: == Project:CMake Issue ID: 13309 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2012-06-16 10:34 EDT Last Modified: 2012-06-16 10:34 EDT == Summary:FindBullet is missing a library name Description: Line 66 of FindBullet.cmake is _FIND_BULLET_LIBRARY(BULLET_MATH_LIBRARY_DEBUG BulletMath_Debug BulletMath_d LinearMath_d) There is a LinearMath_Debug missing, (the _Debug Name is present in all other lines). So this line should look like: _FIND_BULLET_LIBRARY(BULLET_MATH_LIBRARY_DEBUG BulletMath_Debug BulletMath_d LinearMath_Debug LinearMath_d) After this change, the script manages to find all debug&release libraries on my system. == Issue History Date ModifiedUsername FieldChange == 2012-06-16 10:34 Jona 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 0013310]: Regular expression documentation doesn't match command effects.
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=13310
==
Reported By:don la dieu
Assigned To:
==
Project:CMake
Issue ID: 13310
Category: CMake
Reproducibility:always
Severity: minor
Priority: low
Status: new
==
Date Submitted: 2012-06-17 15:20 EDT
Last Modified: 2012-06-17 15:20 EDT
==
Summary:Regular expression documentation doesn't match
command effects.
Description:
The documentation for string(REGEX ...) says:
()Saves a matched subexpression, which can be referenced
in the REGEX REPLACE operation. Additionally it is saved
by all regular expression-related commands, including
e.g. if( MATCHES ), in the variables CMAKE_MATCH_(0..9).
This doesn't match the behavior of file(STRINGS ... REGEX ...)!
Steps to Reproduce:
$ echo foo > /tmp/foo
$ cat CMakeLists.txt
file(STRINGS "/tmp/foo" tmpvar REGEX "^(foo)")
message(STATUS "*** ${CMAKE_MATCH_1} = foo")
$ cmake .
results in:
-- *** = foo
not
-- *** foo = foo
as expected.
==
Issue History
Date ModifiedUsername FieldChange
==
2012-06-17 15:20 don la dieuNew 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 0013311]: LINK arguments incomplete when using cmake --find_package
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=13311
==
Reported By:Hendrik Sattler
Assigned To:
==
Project:CMake
Issue ID: 13311
Category: CMake
Reproducibility:always
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2012-06-18 02:52 EDT
Last Modified: 2012-06-18 02:52 EDT
==
Summary:LINK arguments incomplete when using cmake
--find_package
Description:
Hi,
I try the following commands with my projects config file. It is not installed
but the build tree is registered with export(TARGET).
$ cmake -DNAME=OpenObex -DCOMPILER_ID=GNU -DLANGUAGE=C -DMODE=COMPILE
--find-package
-I/home/hendrik/projects/obex/openobex/repository/include
$ cmake -DNAME=OpenObex -DCOMPILER_ID=GNU -DLANGUAGE=C -DMODE=LINK
--find-package
-rdynamic lib/libopenobex.so.1.6
-Wl,-rpath,/home/hendrik/projects/obex/openobex/repository/build/lib
I think the latter is missing the complete path to the library or alternatively
a -L entry so it should look the same as using it internally.
This probably also happends with a *-config.cmake file installed in a
non-standard location.
HS
Additional Information:
openobex-config.cmake:
---snip-
get_filename_component(OpenObex_CMAKE_DIR "${CMAKE_CURRENT_LIST_FILE}" PATH)
if (EXISTS "${OpenObex_CMAKE_DIR}/lib/openobex-build.cmake")
#in build tree
include(${OpenObex_CMAKE_DIR}/lib/openobex-build.cmake)
include(${OpenObex_CMAKE_DIR}/lib/openobex-build-settings.cmake)
set(OpenObex_INCLUDE_DIRS ${OpenObex_SOURCE_DIR}/include)
else ()
#in installed tree
include(${OpenObex_CMAKE_DIR}/openobex-target.cmake)
set(OpenObex_CMAKE_REL_INCLUDE_DIR "../../../include")
get_filename_component(OpenObex_ABS_INCLUDE_DIR
"${OpenObex_CMAKE_DIR}/${OpenObex_CMAKE_REL_INCLUDE_DIR}" ABSOLUTE)
set(OpenObex_INCLUDE_DIRS "${OpenObex_ABS_INCLUDE_DIR}")
endif()
set(OpenObex_LIBRARIES openobex)
---snip-
lib/openobex-build.cmake:
---snip-
# Generated by CMake 2.8.8
IF("${CMAKE_MAJOR_VERSION}.${CMAKE_MINOR_VERSION}" LESS 2.5)
MESSAGE(FATAL_ERROR "CMake >= 2.6.0 required")
ENDIF("${CMAKE_MAJOR_VERSION}.${CMAKE_MINOR_VERSION}" LESS 2.5)
CMAKE_POLICY(PUSH)
CMAKE_POLICY(VERSION 2.6)
#
# Generated CMake target import file.
#
# Commands may need to know the format version.
SET(CMAKE_IMPORT_FILE_VERSION 1)
# Create imported target openobex
ADD_LIBRARY(openobex SHARED IMPORTED)
# Import target "openobex" for configuration "Debug"
SET_PROPERTY(TARGET openobex APPEND PROPERTY IMPORTED_CONFIGURATIONS DEBUG)
SET_TARGET_PROPERTIES(openobex PROPERTIES
IMPORTED_LOCATION_DEBUG
"/home/hendrik/projects/obex/openobex/repository/build/lib/libopenobex.so.1.6"
IMPORTED_SONAME_DEBUG "libopenobex.so.2"
)
# Commands beyond this point should not need to know the version.
SET(CMAKE_IMPORT_FILE_VERSION)
CMAKE_POLICY(POP)
---snip-
lib/openobex-build-settings.cmake:
---snip-
set(OpenObex_SOURCE_DIR "/home/hendrik/projects/obex/openobex/repository")
---snip-
==
Issue History
Date ModifiedUsername FieldChange
==
2012-06-18 02:52 Hendrik SattlerNew 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 0013312]: Finding the tk.framework inside of Xcode 4.3 fails to find the private headers
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=13312
==
Reported By:Samuel John
Assigned To:
==
Project:CMake
Issue ID: 13312
Category: CMake
Reproducibility:always
Severity: minor
Priority: high
Status: new
==
Date Submitted: 2012-06-18 08:38 EDT
Last Modified: 2012-06-18 08:38 EDT
==
Summary:Finding the tk.framework inside of Xcode 4.3 fails
to find the private headers
Description:
The Framework inside of Xcode is located at
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/System/Library/Frameworks/Tk.framework.
I have no problems to set CMAKE_FRAMEWORK_PATH such that Tk.framework is found.
But the PrivateHeaders are actually located at
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/System/Library/Frameworks/Tk.framework/Headers/tk-private
>From this code in the FindTCL.cmake I see that the "tk-private" postfix is not
added but "/PrivateHeaders" which is not there.
```
SET(TK_FRAMEWORK_INCLUDES)
IF(Tk_FRAMEWORKS)
IF(NOT TK_INCLUDE_PATH)
FOREACH(dir ${Tk_FRAMEWORKS})
SET(TK_FRAMEWORK_INCLUDES ${TK_FRAMEWORK_INCLUDES}
${dir}/Headers ${dir}/PrivateHeaders)
ENDFOREACH(dir)
ENDIF(NOT TK_INCLUDE_PATH)
ENDIF(Tk_FRAMEWORKS)
```
Steps to Reproduce:
I stumbled upon this trying to build vtk on OS X.
Additional Information:
The homebrew vtk formula
https://github.com/mxcl/homebrew/pull/12807
==
Issue History
Date ModifiedUsername FieldChange
==
2012-06-18 08:38 Samuel JohnNew 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 0013313]: [Eclipse CDT] The MinGW include pathentry are not added to the .cproject
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13313 == Reported By:Eric Beuque Assigned To: == Project:CMake Issue ID: 13313 Category: CMake Reproducibility:always Severity: minor Priority: high Status: new == Date Submitted: 2012-06-18 09:31 EDT Last Modified: 2012-06-18 09:31 EDT == Summary:[Eclipse CDT] The MinGW include pathentry are not added to the .cproject Description: I'm using a Windows 7 under Virtualbox from a Linux host. When building a simple project with cmake to generate an Eclipse project, the include path are not added to the .cproject. This has effect that all c++ standard headers are not found by eclipse, but the compilation success. A strange thing is that it works depending on the sources folder: - In a directory like C:\Users\Me\Devel\cmaketest: it doesn't work - In a directory like C:\Me\cmaketest: it doesn't work - In a directory like E:\Devel\cmaketest: it works The only difference I see is the filesystem type: - E: is a shared folder by VBox from the host which have a filesystem type Ext4 - C: is a standard NTFS partition Steps to Reproduce: - Add to PATH the cmake and mingw bin path. - Unzip my archive - Run bootstrap.bat Additional Information: I attach the two generated .cproject. == Issue History Date ModifiedUsername FieldChange == 2012-06-18 09:31 Eric BeuqueNew Issue 2012-06-18 09:31 Eric BeuqueFile Added: cmaketest.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 0013314]: Fixes for various dashboard test failures
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=13314
==
Reported By:Daniel R. Gomez
Assigned To:
==
Project:CMake
Issue ID: 13314
Category: CMake
Reproducibility:always
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2012-06-18 16:02 EDT
Last Modified: 2012-06-18 16:02 EDT
==
Summary:Fixes for various dashboard test failures
Description:
This omnibus bug report addresses a handful of test failures that appear to have
a straightforward solution. (Note: I have not been able to test these changes,
as the normal CTest dashboard build reverts the Git repository it works from; is
there a way to do this?)
A patch against git master is attached.
Failed test: Assembler
http://open.cdash.org/testDetails.php?test=149633033&build=2372627
http://open.cdash.org/testDetails.php?test=149289472&build=2361814
Test fails because a .s assembly file is compiled without CFLAGS, and then
linked with CFLAGS. The CFLAGS for this dashboard build select 64-bit output,
but the compiler/linker do 32-bit by default. The linker barfs when told to link
a 32-bit object against a 64-bit C library.
Solution: Set COMPILE_FLAGS on the assembly source to ${CMAKE_C_FLAGS}. This
should be safe because the test is written so that the assembly is only ever
compiled by the C compiler.
Failed test: FindPackageModeMakefileTest
http://open.cdash.org/testDetails.php?test=148879982&build=2372627
Similar to the above, an object file is compiled with CXXFLAGS, and then linked
without CXXFLAGS, and the linker barfs on the mismatched ABIs.
Solution: Use CXXFLAGS in the makefile's link rule. This is trivial enough, so I
also retooled the makefile not to require GNU Make. (Using backticks instead of
$(shell ...) is safe so long as you guard against the possibility of backslashes
getting inside the backticks, which is why I used temporary shell variables.)
Failed test: IncludeDirectories
http://open.cdash.org/testDetails.php?test=148879964&build=2372627
Test fails because the HP-UX compiler really really wants source files to end
with a newline.
Test solution: Pretty indentation and FILE(WRITE ...) don't mix.
Bonus warning fix for test: VSGNUFortran
http://open.cdash.org/testDetails.php?test=149538620&build=2361814
"warning: tokens ignored at end of directive line"
(Note: The test failure is due to the build host's software environment; I'm
working on that)
==
Issue History
Date ModifiedUsername FieldChange
==
2012-06-18 16:02 Daniel R. GomezNew Issue
2012-06-18 16:02 Daniel R. GomezFile Added: cmake-test-fixes.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 0013315]: Modules/InstallRequiredSystemLibraries looks for non-existing files.
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13315 == Reported By:Alex Blekhman Assigned To: == Project:CMake Issue ID: 13315 Category: CPack Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 2012-06-19 02:16 EDT Last Modified: 2012-06-19 02:16 EDT == Summary:Modules/InstallRequiredSystemLibraries looks for non-existing files. Description: Modules/InstallRequiredSystemLibraries.cmake tries to install non-existing file: 'C:/Program Files (x86)/Microsoft Visual Studio 10.0/VC/redist/x64/Microsoft.VC100.MFCLOC/mfc100esp.dll' This file has been renamed to 'mfc100esn.dll' for both x86 and x64 versions of the MFC 10.0 library. Steps to Reproduce: Execute the following CMake script: INCLUDE(InstallRequiredSystemLibraries) The output is: CMake Warning at C:/Program Files (x86)/CMake 2.8/share/cmake-2.8/Modules/InstallRequiredSystemLibraries.cmake:342 (MESSAGE): system runtime library file does not exist: 'C:/Program Files (x86)/Microsoft Visual Studio 10.0/VC/redist/x64/Microsoft.VC100.MFCLOC/mfc100esp.dll' == Issue History Date ModifiedUsername FieldChange == 2012-06-19 02:16 Alex Blekhman 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 0013316]: FIND_PACKAGE ( X11 REQUIRED ) returns garbage...
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=13316
==
Reported By:George Petasis
Assigned To:
==
Project:CMake
Issue ID: 13316
Category: CMake
Reproducibility:always
Severity: block
Priority: normal
Status: new
==
Date Submitted: 2012-06-19 05:29 EDT
Last Modified: 2012-06-19 05:29 EDT
==
Summary:FIND_PACKAGE ( X11 REQUIRED ) returns garbage...
Description:
Hi all,
The following code:
MESSAGE ( STATUS "Searching for X11..." )
FIND_PACKAGE ( X11 REQUIRED )
IF ( X11_FOUND )
INCLUDE_DIRECTORIES ( ${X11_INCLUDE_DIR} )
LINK_LIBRARIES ( ${X11_LIBRARIES} )
MESSAGE ( STATUS " X11_INCLUDE_DIR: " ${X11_INCLUDE_DIR} )
MESSAGE ( STATUS " X11_LIBRARIES: " ${X11_LIBRARIES} )
ENDIF ( X11_FOUND )
Prints under Fedora 17:
Searching for X11...
-- Looking for XOpenDisplay in /usr/lib/libX11.so;/usr/lib/libXext.so
-- Looking for XOpenDisplay in /usr/lib/libX11.so;/usr/lib/libXext.so - found
-- Looking for gethostbyname
-- Looking for gethostbyname - found
-- Looking for connect
-- Looking for connect - found
-- Looking for remove
-- Looking for remove - found
-- Looking for shmat
-- Looking for shmat - found
-- Looking for IceConnectionNumber in ICE
-- Looking for IceConnectionNumber in ICE - found
-- Found X11: /usr/lib/libX11.so
-- X11_INCLUDE_DIR:
/usr/include/usr/include/usr/include/usr/include/usr/include/usr/include/usr/include/usr/include/usr/include/usr/include/usr/include/usr/include/usr/include/usr/include/usr/include/usr/include/usr/include/usr/include/usr/include/usr/include/usr/include/usr/include/usr/include/usr/include/usr/include/usr/include/usr/include/usr/include/usr/include
-- X11_LIBRARIES:
/usr/lib/libSM.so/usr/lib/libICE.so/usr/lib/libX11.so/usr/lib/libXext.so
==
Issue History
Date ModifiedUsername FieldChange
==
2012-06-19 05:29 George Petasis 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 0013317]: Generated moc files are not cleaned
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=13317 == Reported By:Rolf Eike Beer Assigned To:Alex Neundorf == Project:CMake Issue ID: 13317 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: assigned == Date Submitted: 2012-06-19 05:59 EDT Last Modified: 2012-06-19 05:59 EDT == Summary:Generated moc files are not cleaned Description: After "make clean" the automatically generated moc_*.cpp files are still around. == Issue History Date ModifiedUsername FieldChange == 2012-06-19 05:59 Rolf Eike Beer New Issue 2012-06-19 05:59 Rolf Eike Beer Status new => assigned 2012-06-19 05:59 Rolf Eike Beer Assigned To => Alex Neundorf == -- 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 0013318]: swig: -noproxy option not supported with python
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=13318 == Reported By:jeromerobert Assigned To: == Project:CMake Issue ID: 13318 Category: CMake Reproducibility:always Severity: feature Priority: normal Status: new == Date Submitted: 2012-06-19 06:47 EDT Last Modified: 2012-06-19 06:47 EDT == Summary:swig: -noproxy option not supported with python Description: When using python UseSWIG.cmake assume that the target library is always named _modulename. This target is expected to be loaded from a python wrapper (aka modulename.py). When using the swig -noproxy option there is no python wrapper and import modulename load the module from modulename.so. As UseSWIG.cmake always create _modulename.so, and not modulename.so, using -noproxy is currently not possible. == Issue History Date ModifiedUsername FieldChange == 2012-06-19 06:47 jeromerobert 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 0013319]: "no matching function for call to std::string.clear(), std::string.push_back()"
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=13319
==
Reported By:Daniel R. Gomez
Assigned To:
==
Project:CMake
Issue ID: 13319
Category: CMake
Reproducibility:always
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2012-06-19 12:31 EDT
Last Modified: 2012-06-19 12:31 EDT
==
Summary:"no matching function for call to
std::string.clear(), std::string.push_back()"
Description:
>From a nightly AIX dashboard, building with a vendor-supplied GCC ("g++ -v"
returns "gcc version 2.9-aix51-020209"):
.../CMake/Tests/CMakeLib/run_compile_commands.cxx: In method `void
CompileCommandParser::ParseString ()':
.../CMake/Tests/CMakeLib/run_compile_commands.cxx:66: no matching function for
call to `basic_string,
__default_alloc_template >::clear ()'
.../CMake/Tests/CMakeLib/run_compile_commands.cxx:71: no matching function for
call to `basic_string,
__default_alloc_template >::push_back (char &)'
(from http://open.cdash.org/viewBuildError.php?buildid=2375368)
==
Issue History
Date ModifiedUsername FieldChange
==
2012-06-19 12:31 Daniel R. GomezNew 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 0013320]: UINT32_C() et al. macro shenanigans break build on HP-UX
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13320 == Reported By:Daniel R. Gomez Assigned To: == Project:CMake Issue ID: 13320 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2012-06-19 16:08 EDT Last Modified: 2012-06-19 16:08 EDT == Summary:UINT32_C() et al. macro shenanigans break build on HP-UX Description: Bootstrapping CMake 2.8.8 on this HP-UX system fails with [ 1%] Building C object Utilities/KWIML/test/CMakeFiles/cmIML_test.dir/test_INT_C.c.o cd /tmp/cmake-build/Utilities/KWIML/test && /opt/tg/bin/tg-gcc -DKWIML_NAMESPACE=cmIML -DKWIML_LANGUAGE_C -DKWIML_LANGUAGE_CXX -pipe -W -Wall -Wcast-align -Wformat=2 -Wpointer-arith -Wundef -mpa-risc-2-0 -O3 -Wno-format -I/tmp/cmake-build/Utilities/KWIML/test -I/tmp/cmake-build/Utilities-o CMakeFiles/cmIML_test.dir/test_INT_C.c.o -c /home/src/cmake-2.8.8/Utilities/KWIML/test/test_INT_C.c In file included from /home/src/cmake-2.8.8/Utilities/KWIML/test/test_INT_C.c:14:0: /tmp/cmake-build/Utilities/KWIML/test/test_INT_format.h: In function 'test_INT_format': /tmp/cmake-build/Utilities/KWIML/test/test_INT_format.h:195:1: error: pasting ")" and "l" does not give a valid preprocessing token /tmp/cmake-build/Utilities/KWIML/test/test_INT_format.h:195:3: error: expected ',' or ';' before 'l' gmake[2]: *** [Utilities/KWIML/test/CMakeFiles/cmIML_test.dir/test_INT_C.c.o] Error 1 gmake[2]: Leaving directory `/tmp/cmake-build' gmake[1]: *** [Utilities/KWIML/test/CMakeFiles/cmIML_test.dir/all] Error 2 gmake[1]: Leaving directory `/tmp/cmake-build' gmake: *** [all] Error 2 The test_INT_format.h makes use of a symbol UINT32_C, and others like it. This is defined in inttypes.h: $ gnu-grep -R UINT32_C /usr/include /usr/include/inttypes.h:#define UINT32_C(__c) __CONCAT_U__(__c) /usr/include/inttypes.h:#define UINT32_C(__c) __CONCAT__(__CONCAT_U__(__c),l) /usr/include/inttypes.h:# define UINT32_MAX UINT32_C(4294967295) >From what I can tell, this macro is being expanded before being passed as an argument to TEST_C(). I'm not sure how to work around this. == Issue History Date ModifiedUsername FieldChange == 2012-06-19 16:08 Daniel R. GomezNew 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 0013321]: ABI.h doesn't know about older HP compilers
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13321 == Reported By:Daniel R. Gomez Assigned To: == Project:CMake Issue ID: 13321 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2012-06-20 01:55 EDT Last Modified: 2012-06-20 01:55 EDT == Summary:ABI.h doesn't know about older HP compilers Description: Bootstrapping CMake 2.8.8 on HP-UX 11.00 with the vendor-provided C compiler fails with [ 0%] Building C object Utilities/KWIML/test/CMakeFiles/cmIML_test.dir/test_ABI_C.c.o cd /tmp/cmake-2.8.8/_build/Utilities/KWIML/test && /opt/ansic/bin/cc -DKWIML_NAMESPACE=cmIML -DKWIML_LANGUAGE_C -DKWIML_LANGUAGE_CXX -Aa -Ae -Ae +DA2.0 +ESlit +w1 -z -Wp,-H262144 +O2 -I/tmp/cmake-2.8.8/_build/Utilities/KWIML/test -I/tmp/cmake-2.8.8/_build/Utilities-o CMakeFiles/cmIML_test.dir/test_ABI_C.c.o -c /tmp/cmake-2.8.8/Utilities/KWIML/test/test_ABI_C.c cpp: "/tmp/cmake-2.8.8/_build/Utilities/cmIML/ABI.h", line 163: error 4062: "Signedness of 'char' unknown." cpp: "/tmp/cmake-2.8.8/_build/Utilities/cmIML/ABI.h", line 257: error 4062: "Existence of 'long long' unknown." *** Error exit code 1 This compiler does not define __HP_cc nor __HP_aCC. I think it may be necessary to do the equivalent of #if defined(__hpux) && \ !defined(__HP_cc) && \ !defined(__HP_aCC) && \ !defined(__GNUC__) in order to catch this case. (__hpux is specifically mentioned in the cpp(1) man page.) Version information on this compiler, for reference: $ cc -V -c foo.c cpp.ansi: HP92453-01 A.11.01.20 HP C Preprocessor (ANSI) ccom: HP92453-01 A.11.01.20 HP C Compiler == Issue History Date ModifiedUsername FieldChange == 2012-06-20 01:55 Daniel R. GomezNew 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 0013323]: CMake crashes if language is set inproperly.
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13323 == Reported By:Mariusz Plucinski Assigned To: == Project:CMake Issue ID: 13323 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2012-06-20 08:02 EDT Last Modified: 2012-06-20 08:02 EDT == Summary:CMake crashes if language is set inproperly. Description: Found it during experimenting with adding new language support. CMake crashes when there is a problem with source file language property. Steps to Reproduce: 1. Create CMakeLists.txt and put the following code: project(BugTest) cmake_minimum_required(VERSION 2.8) add_executable(Foo Bar.asd) set_target_properties(Foo PROPERTIES LINKER_LANGUAGE asd) 2. Create empty Bar.asd file 3. Run "cmake ." under Windows, using Visual Studio 10 generator. Additional Information: Expected result: Getting an error message about missing variable: CMAKE_asd_LINK_EXECUTABLE Actual result: Application crash (Access violation). Attached patch fixes an error. == Issue History Date ModifiedUsername FieldChange == 2012-06-20 08:02 Mariusz PlucinskiNew Issue 2012-06-20 08:02 Mariusz PlucinskiFile Added: cmake_cmLocalGenerator.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 0013324]: Segfault with Swig CPLUSPLUS ON
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=13324
==
Reported By:jeromerobert
Assigned To:
==
Project:CMake
Issue ID: 13324
Category: CMake
Reproducibility:always
Severity: major
Priority: normal
Status: new
==
Date Submitted: 2012-06-20 09:44 EDT
Last Modified: 2012-06-20 09:44 EDT
==
Summary:Segfault with Swig CPLUSPLUS ON
Description:
How to reproduce:
$ cat > CMakeLists.txt
project (Foo C)
cmake_minimum_required(VERSION 2.8)
find_package(SWIG REQUIRED)
include(${SWIG_USE_FILE})
set_source_files_properties(foo.i PROPERTIES CPLUSPLUS ON)
swig_add_module(foo python foo.i)
$ touch foo.i
$ cmake .
-- Configuring done
Segmentation fault
Expected result:
A error message saying that it's wrong to enable the CPLUSPLUS property on a C
only project.
==
Issue History
Date ModifiedUsername FieldChange
==
2012-06-20 09:44 jeromerobert 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 0013330]: CMAKE_CXX_COMPILER_INIT used in CMakeDetermineCCompiler.cmake
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13330 == Reported By:Jaime Frey Assigned To: == Project:CMake Issue ID: 13330 Category: CMake Reproducibility:have not tried Severity: minor Priority: normal Status: new == Date Submitted: 2012-06-20 14:56 EDT Last Modified: 2012-06-20 14:56 EDT == Summary:CMAKE_CXX_COMPILER_INIT used in CMakeDetermineCCompiler.cmake Description: At line 35 of CMakeDetermineCCompiler.cmake, CMAKE_CXX_COMPILER_INIT is set to NOTFOUND. I suspect it should be setting CMAKE_C_COMPILER_INIT instead, as that variable is used immediately below. I don't know what effect this would have on users. == Issue History Date ModifiedUsername FieldChange == 2012-06-20 14:56 Jaime Frey 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 0013331]: AIX linker chokes on spaces in rpath
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13331 == Reported By:Daniel R. Gomez Assigned To: == Project:CMake Issue ID: 13331 Category: CMake Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 2012-06-20 15:14 EDT Last Modified: 2012-06-20 15:14 EDT == Summary:AIX linker chokes on spaces in rpath Description: I was looking into why so many tests were failing on my AIX 5.3 dashboard: http://open.cdash.org/viewTest.php?onlyfailed&buildid=2378283 It seems to come down to the linker's -blibpath option. Compare the below two invocations---the only difference is "My Tests" in the first one, and "My_Tests" in the second: host:~/Dashboards/My Tests/CMake-build/Tests/COnly> env OBJECT_MODE=32 /usr/bin/gcc -mminimal-toc -O0 CMakeFiles/COnly.dir/conly.c.o CMakeFiles/COnly.dir/foo.c.o -o COnly libtestc1.a libtestc2.so -Wl,-blibpath:"/home/cport/Dashboards/My Tests/CMake-build/Tests/COnly:/usr/lib:/lib" ld: 0706-014 The -b Tests/CMake-build/Tests/COnly option is not recognized. collect2: ld returned 255 exit status host:~/Dashboards/My Tests/CMake-build/Tests/COnly> env OBJECT_MODE=32 /usr/bin/gcc -mminimal-toc -O0 CMakeFiles/COnly.dir/conly.c.o CMakeFiles/COnly.dir/foo.c.o -o COnly libtestc1.a libtestc2.so -Wl,-blibpath:"/home/cport/Dashboards/My_Tests/CMake-build/Tests/COnly:/usr/lib:/lib" (no error) This should probably be checked when CMake first looks at the compiler/linker, as a fail-fast behavior would be helpful here. (I checked that this isn't a problem with gcc or even collect2 mishandling the option; I get the same error even if I pass -blibpath:"..." directly to ld.) == Issue History Date ModifiedUsername FieldChange == 2012-06-20 15:14 Daniel R. GomezNew 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 0013332]: Can't link a shared library with cc on HP-UX
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13332 == Reported By:Daniel R. Gomez Assigned To: == Project:CMake Issue ID: 13332 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2012-06-20 15:48 EDT Last Modified: 2012-06-20 15:48 EDT == Summary:Can't link a shared library with cc on HP-UX Description: Bootstrapping 2.8.8 on HP-UX 11.00 with the vendor compiler fails with [...] Linking C shared module libcmsysTestDynload.sl cd /tmp/cmake-2.8.8-test/_build-cc/Source/kwsys && /tmp/cmake-2.8.8-test/_build-cc/Bootstrap.cmk/cmake -E cmake_link_script CMakeFiles/cmsysTestDynload.dir/link.txt --verbose=1 /opt/ansic/bin/cc +Z -Ae +DA2.0 +ESlit +w1 -z -Wp,-H262144 +O2 -Wl,-E,+nodefaultrpath -b -L/usr/lib -Wl,+hlibcmsysTestDynload.sl -o libcmsysTestDynload.sl CMakeFiles/cmsysTestDynload.dir/testDynload.c.o -Wl,+b/usr/lib cc: warning 488: "cc +help" invokes On-Line C reference manual. cc: warning 422: Unknown option "b" ignored. /usr/ccs/bin/ld: Unsatisfied symbols: main (Not referenced yet! Probably due to -u option) gmake[2]: *** [Source/kwsys/libcmsysTestDynload.sl] Error 1 gmake[2]: Leaving directory `/tmp/cmake-2.8.8-test/_build-cc' gmake[1]: *** [Source/kwsys/CMakeFiles/cmsysTestDynload.dir/all] Error 2 gmake[1]: Leaving directory `/tmp/cmake-2.8.8-test/_build-cc' gmake: *** [all] Error 2 For one, that -b needs to be a -Wl,-b. If I do the compiler invocation that way, I get host:/tmp/cmake-2.8.8-test/_build-cc/Source/kwsys$ /opt/ansic/bin/ cc +Z -Ae +DA2.0 +ESlit +w1 -z -Wp,-H262144 +O2 -Wl,-E,+nodefaultrpath -Wl,-b -L /usr/lib -Wl,+hlibcmsysTestDynload.sl -o libcmsysTestDynload.sl CMakeFiles/cmsys TestDynload.dir/testDynload.c.o -Wl,+b/usr/lib /usr/ccs/bin/ld: CODE_ONE_SYM fixup to non-code subspace in file /opt/langtools/lib/crt0.o - shared library must be position independent. Use +z or +Z to recompile. Adding -v to that gives me cc: NLSPATH is /opt/ansic/lib/nls/msg/%L/%N.cat:/opt/ansic/lib/nls/msg/C/%N.cat: cc: CCOPTS is not set. cc: INCLUDIR is INCLUDIR=/usr/include cc: LPATH is /usr/lib:/opt/langtools/lib: /usr/ccs/bin/ld /opt/langtools/lib/crt0.o -u main -z -E +nodefaultrpath -b -L/usr/lib +hlibcmsysTestDynload.sl -o libcmsysTestDynload.sl CMakeFiles/cmsysTestDynload.dir/testDynload.c.o +b/usr/lib -lc cc: Entering Link editor. /usr/ccs/bin/ld: CODE_ONE_SYM fixup to non-code subspace in file /opt/langtools/lib/crt0.o - shared library must be position independent. Use +z or +Z to recompile. I don't know how crt0.o is getting in there, but if I invoke ld directly without that, the link works. There is probably an option that can be given to cc(1) so that it doesn't pass crt0.o to the linker, but I'm not seeing anything along those lines in the man page... == Issue History Date ModifiedUsername FieldChange == 2012-06-20 15:48 Daniel R. GomezNew 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 0013335]: Build installs into wrong directory due to bug in bootstrap script
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=13335
==
Reported By:MartinK
Assigned To:
==
Project:CMake
Issue ID: 13335
Category: CMakeSetup
Reproducibility:always
Severity: major
Priority: normal
Status: new
==
Date Submitted: 2012-06-21 09:54 EDT
Last Modified: 2012-06-21 09:54 EDT
==
Summary:Build installs into wrong directory due to bug in
bootstrap script
Description:
CMake build on Solaris with a given prefix fails since the substitution
expression is incompatible with Solaris /bin/sh:
bootstrap:547
--prefix=*) cmake_prefix_dir=`cmake_fix_slashes "${1#*=}"` ;;
Result on Solaris 10 (x86 and SPARC) is "bad substitution", resulting in empty
cmake_prefix_dir, thus trying to install into the root directory.
Workaround is to change the shell to /bin/bash.
Steps to Reproduce:
- Run configure with some value for --prefix (or --datadir etc) on Solaris.
- Run following test script with at least one parameter on Solaris:
#!/bin/sh
echo "${1#*=}"
==
Issue History
Date ModifiedUsername FieldChange
==
2012-06-21 09:54 MartinKNew 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 0013343]: Random Configure Failure
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13343 == Reported By:michael_cow Assigned To: == Project:CMake Issue ID: 13343 Category: CMake Reproducibility:random Severity: major Priority: normal Status: new == Date Submitted: 2012-06-21 18:47 EDT Last Modified: 2012-06-21 18:47 EDT == Summary:Random Configure Failure Description: I am seeing similar behavior that was reported as fixed here: http://public.kitware.com/Bug/view.php?id=12957 I attempt to configure a cmake project in windows and randomly the project will fail with the following errror message: Check for working C compiler using: Visual Studio 10 Check for working C compiler using: Visual Studio 10 -- works Detecting C compiler ABI info Detecting C compiler ABI info - failed Check for working CXX compiler using: Visual Studio 10 Check for working CXX compiler using: Visual Studio 10 -- broken CMake Error at C:/Program Files (x86)/CMake 2.8/share/cmake-2.8/Modules/CMakeTestCXXCompiler.cmake:45 (MESSAGE): The C++ compiler "cl" is not able to compile a simple test program. It fails with the following output: Change Dir: C:/workspaces/sampleproeject/build/cmake/sampleproeject/CMakeFiles/CMakeTmp Run Build Command:C:\PROGRA~2\MICROS~1.0\Common7\IDE\devenv.com CMAKE_TRY_COMPILE.sln /build Debug /project cmTryCompileExec506066143 Microsoft (R) Visual Studio Version 10.0.30319.1. Copyright (C) Microsoft Corp. All rights reserved. 1>-- Build started: Project: cmTryCompileExec506066143, Configuration: Debug Win32 -- 1> Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.30319.01 for 80x86 1> Copyright (C) Microsoft Corporation. All rights reserved. 1> 1> cl /c /Zi /W3 /WX- /Od /Ob0 /Oy- /D WIN32 /D _WINDOWS /D _DEBUG /D "CMAKE_INTDIR=\"Debug\"" /D _MBCS /Gm- /EHsc /RTC1 /MDd /GS /fp:precise /Zc:wchar_t /Zc:forScope /GR /Fo"cmTryCompileExec506066143.dir\Debug\\" /Fd"C:/workspaces/rmhsampleproeject/build/cmake/sampleproeject/CMakeFiles/CMakeTmp/Debug/cmTryCompileExec506066143.pdb" /Gd /TP /analyze- /errorReport:prompt C:\workspaces\sampleproeject\build\cmake\sampleproeject\CMakeFiles\CMakeTmp\testCXXCompiler.cxx /Zm1000 1> 1> testCXXCompiler.cxx 1>LINK : fatal error LNK1201: error writing to program database 'C:\workspaces\sampleproeject\build\cmake\sampleproeject\CMakeFiles\CMakeTmp\Debug\cmTryCompileExec506066143.pdb'; check for insufficient disk space, invalid path, or insufficient privilege == Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped == CMake will not be able to correctly generate this project. Call Stack (most recent call first): CMakeLists.txt:3 (project) Often times the second time will succeed. Once it has passed once it is generally ok. The problem is that Jenkins is running CI and is not so happy when it fails randomly. Configuring incomplete, errors occurred! Steps to Reproduce: Attempt to build on Win 7 multiple times. Some number of attempts will fail configure. == Issue History Date ModifiedUsername FieldChange == 2012-06-21 18:47 michael_cowNew 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 0013348]: Cmake not finding buld program for Visual Studio Express 2012 on Win8
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13348 == Reported By:ergo1 Assigned To: == Project:CMake Issue ID: 13348 Category: CMake Reproducibility:always Severity: block Priority: normal Status: new == Date Submitted: 2012-06-22 13:13 EDT Last Modified: 2012-06-22 13:13 EDT == Summary:Cmake not finding buld program for Visual Studio Express 2012 on Win8 Description: CMake Error: CMake was unable to find a build program corresponding to "Visual Studio 11". CMAKE_MAKE_PROGRAM is not set. You probably need to select a different build tool. CMake Error: Could not find cmake module file:E:/W8/BUILDS/ogrewinrt/CMakeFiles/CMakeCCompiler.cmake CMake Error: Could not find cmake module file:E:/W8/BUILDS/ogrewinrt/CMakeFiles/CMakeCXXCompiler.cmake Configuring incomplete, errors occurred! Steps to Reproduce: Try to make a sample Ogre3d project on Win8 for Visual Studio Express 2012 RC. Same error with either the 32 or 64 bit build tool selection Additional Information: Code developer advised: "2. You need patched CMake 2.8.7 from Feb 23 2012 or later for VS_WINRT_EXTENSIONS and VS_WINRT_REFERENCES special target properties." My understanding is that this patch was incorporated into Cmake 2.8.8 (??) PS: Code tested OK with above noted version of cmake on win8 consumer preview with Visual Studio 11 Ultimate Beta == Issue History Date ModifiedUsername FieldChange == 2012-06-22 13:13 ergo1 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 0013072]: Allow CPack to generate tar.xz archives
The following issue is now in status NEW (again) == http://cmake.org/Bug/view.php?id=13072 == Reported By:Mario Lang Assigned To:Eric NOULARD == Project:CMake Issue ID: 13072 Category: CPack Reproducibility:N/A Severity: feature Priority: normal Status: new == Date Submitted: 2012-03-29 16:33 CEST Last Modified: 2012-06-25 11:22 CEST == Summary:Allow CPack to generate tar.xz archives Description: For my project I'd like to use CPack to generate tar.xz source archives. After a bit of poking around in the git repository I realized that xz support is already there in the underlying library for handling archives. However, there is no Generator for TXZ. The attached patch adds the necessary generator. Tested and works as expected for me. I can set(CPACK_SOURCE_GENERATOR "TGZ;TXZ;") now and the result is just as expected. A second patch (also to be attached) adds the CPACK_BINARY_TXZ and CPACK_SOURCE_TXZ options as well. == Relationships ID Summary -- duplicate of0011040 TXZ support to cpack == -- (0029008) Eric NOULARD (developer) - 2012-03-30 17:40 http://cmake.org/Bug/view.php?id=13072#c29008 -- This looks fine but unfortnately this is may not be enough. CMake should build on any host, LZMA lib being installed or not. In order to achieve this for Bzip2, zip, z and gz compression CMake includes: Utilities/cmbzip2 Utilities/zlib in its source tree. Then options: CMAKE_USE_SYSTEM_BZIP2 and CMAKE_USE_SYSTEM_ZLIB are used to toggle between system version and shipped-in version of those libs. What would happen if CMake is compiled on a host where lzma lib is not installed? Will it fail to compile or will CPack have a non-functional TXZ generator? -- (0029010) Eric NOULARD (developer) - 2012-03-30 17:52 http://cmake.org/Bug/view.php?id=13072#c29010 -- Just remembered that there was a sibling bug closed some time ago, I did add the relationship, but read David's comment about portability: http://public.kitware.com/Bug/view.php?id=11040#c24155 -- (0029026) Mario Lang (reporter) - 2012-04-01 09:59 http://cmake.org/Bug/view.php?id=13072#c29026 -- > What would happen if CMake is compiled on a host where lzma lib is not installed? > Will it fail to compile or will CPack have a non-functional TXZ generator? Right now, Aas far as I can see, CPack will have a TXZ generator that reports that it was built without lzma support. cmlibarchive has ifdefs for HAVE_LZMA and will provide stub functions with a warning. From my POV, thats fine since TXZ is not enabled by default. If a user chooses to enable TXZ they will either have success or get an appropriate error from CPack. -- (0029027) Eric NOULARD (developer) - 2012-04-01 10:39 http://cmake.org/Bug/view.php?id=13072#c29027 -- Hi Mario, I let Kitware guys give their opinion on this, but CMake tries to avoid platform specific feature in his feature set unless it's obviously makes sense, like not support Visual Studio Generator on Linux is just fine. In the present case, the point of using libarchive is precisely the fact that the same range of features are available on all CMake-supported platforms. How would I write a portable CMakeLists.txt and use TXZ if I have not "by-design" clue that TXZ will be available on a particular platform? I can see two options for achieving this: 1) Create something like cmxzutils (from http://tukaani.org/xz/) and ensure it compiles on all CMake supported platform Then your patch is ok. 2) Create a TAR CPack generator (which does not exist yet) and authorize this generator to have a CPACK_TAR_POSTPROCESS option which could be used to specify a post-processing command on the file(s) produced
[cmake-developers] [CMake 0013349]: CTest.UpdateSVN test fails due to Subversion limitation
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13349 == Reported By:Daniel R. Gomez Assigned To: == Project:CMake Issue ID: 13349 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2012-06-25 16:32 EDT Last Modified: 2012-06-25 16:32 EDT == Summary:CTest.UpdateSVN test fails due to Subversion limitation Description: This test failure... http://open.cdash.org/testDetails.php?test=150750394&build=2384124 ...does not appear to be due to a problem with CMake. $ ls /tmp/foo ls: /tmp/foo: No such file or directory $ svnadmin --version svnadmin, version 1.7.5 (r1336830) compiled Jun 18 2012, 22:44:31 Copyright (C) 2012 The Apache Software Foundation. This software consists of contributions made by many people; see the NOTICE file for more information. Subversion is open source software, see http://subversion.apache.org/ The following repository back-end (FS) modules are available: * fs_fs : Module for working with a plain file (FSFS) repository. $ svnadmin create --config-dir /tmp/foo/config /tmp/foo/repo svnadmin: E02: Repository creation failed svnadmin: E02: Could not create top-level directory svnadmin: E02: Can't create directory '/tmp/foo/repo': No such file or directory == Issue History Date ModifiedUsername FieldChange == 2012-06-25 16:32 Daniel R. GomezNew 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 0013351]: GetPrerequisites.cmake doesn't catch errors from dumpbin
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13351 == Reported By:Clinton Stimpson Assigned To: == Project:CMake Issue ID: 13351 Category: Modules Reproducibility:have not tried Severity: minor Priority: normal Status: new == Date Submitted: 2012-06-26 13:29 EDT Last Modified: 2012-06-26 13:29 EDT == Summary:GetPrerequisites.cmake doesn't catch errors from dumpbin Description: I had a case of a corrupt dll, but BundleUtilities/GetPrerequisites silently skips right over it. in get_prerequisites(), I changed "set(verbose 1)" And "dumpbin /dependents" gave the error ... *.dll : fatal error LNK1136: invalid or corrupt file" and returns zero prerequisites. == Issue History Date ModifiedUsername FieldChange == 2012-06-26 13:29 Clinton StimpsonNew 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 0013352]: Incorrect linking of shared-library dependencies on AIX
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13352 == Reported By:Daniel R. Gomez Assigned To: == Project:CMake Issue ID: 13352 Category: CMake Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 2012-06-26 14:52 EDT Last Modified: 2012-06-26 14:52 EDT == Summary:Incorrect linking of shared-library dependencies on AIX Description: This report is borne of this failing dashboard test: http://open.cdash.org/testDetails.php?test=150972101&build=2394658 Some tinkering around in the test directory: cport@vibraslap:~/Dashboards/MyTests/CMake-build/Tests/CustomCommand/PerConfig> env OBJECT_MODE=32 /usr/bin/gcc -mminimal-toc -O0 CMakeFiles/perconfig.dir/perconfig.c.o -o ../bin/perconfig ../bin/libpcStatic.a ../bin/libpcShared.so -Wl,-blibpath:/home/cport/Dashboards/MyTests/CMake-build/Tests/CustomCommand/bin:/usr/lib:/lib cport@vibraslap:~/Dashboards/MyTests/CMake-build/Tests/CustomCommand/PerConfig> ldd ../bin/perconfig ../bin/perconfig needs: /usr/lib/libc.a(shr.o) ../bin/libpcShared.so /unix /usr/lib/libcrypt.a(shr.o) cport@vibraslap:~/Dashboards/MyTests/CMake-build/Tests/CustomCommand/PerConfig> ln -s ../bin/libpcShared.so . cport@vibraslap:~/Dashboards/MyTests/CMake-build/Tests/CustomCommand/PerConfig> env OBJECT_MODE=32 /usr/bin/gcc -mminimal-toc -O0 CMakeFiles/perconfig.dir/perconfig.c.o -o ../bin/perconfig ../bin/libpcStatic.a libpcShared.so -Wl,-blibpath:/home/cport/Dashboards/MyTests/CMake-build/Tests/CustomCommand/bin:/usr/lib:/lib cport@vibraslap:~/Dashboards/MyTests/CMake-build/Tests/CustomCommand/PerConfig> ldd ../bin/perconfig ../bin/perconfig needs: /usr/lib/libc.a(shr.o) /home/cport/Dashboards/MyTests/CMake-build/Tests/CustomCommand/bin/libpcShared.so /unix /usr/lib/libcrypt.a(shr.o) Notice how when the linker is given "../bin/libpcShared.so", it records exactly that in the executable's dependencies, and fails to find the library dependency. Only if I link in "libpcShared.so", without a path prefix, does the executable build correctly. Looking through the ld(1) man page, these bits appear relevant: Note: If you specify a shared object, or an archive file containing a shared object, with an absolute or relative path name, instead of with the -lName flag, the path name is included in the import file ID string in the loader section of the output file. You can override this behavior with the -bnoipath option. [...] noipath For shared objects listed on the command-line, rather than specified with the -l flag, use a null path component when listing the shared object in the loader section of the output file. A null path component is always used for shared objects specified with the -l flag. This option does not affect the specification of a path component by using a line beginning with #! in an import file. The default is the ipath option. Adding -Wl,-bnoipath allows the original link invocation to produce a correct binary. == Issue History Date ModifiedUsername FieldChange == 2012-06-26 14:52 Daniel R. GomezNew 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 0013353]: xcodebuild no longer recognizes the -buildstyle argument
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=13353 == Reported By:Grant Limberg Assigned To: == Project:CMake Issue ID: 13353 Category: CMake Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 2012-06-26 16:48 EDT Last Modified: 2012-06-26 16:48 EDT == Summary:xcodebuild no longer recognizes the -buildstyle argument Description: As of Xcode 4.4 Developer Previews, xcodebuild no longer supports the -buildstyle argument. A new method for generating Xcode builds is needed. Steps to Reproduce: 1) Install Mountain Lion Developer Preview 4 and Xcode 4.4 Developer Preview 6. 2) Try to generate an Xcode based project... Kaboom == Issue History Date ModifiedUsername FieldChange == 2012-06-26 16:48 Grant Limberg 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 0013354]: CMake hangs generating XCode project file when CXXFLAGS contains -g in a flag
The following issue has been SUBMITTED.
==
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
==
Date Submitted: 2012-06-27 08:14 EDT
Last Modified: 2012-06-27 08:14 EDT
==
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
==
Issue History
Date ModifiedUsername FieldChange
==
2012-06-27 08:14 Jens Bäckman 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 0013355]: UseJava ignores resources without extensions
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13355 == Reported By:Marcin Wojdyr Assigned To: == Project:CMake Issue ID: 13355 Category: Modules Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2012-06-27 14:17 EDT Last Modified: 2012-06-27 14:17 EDT == Summary:UseJava ignores resources without extensions Description: Resource files that have no filename extension are ignored. Steps to Reproduce: With this CMakeLists.txt: cmake_minimum_required(VERSION 2.8.6) find_package(Java) include(UseJava) project(foo Java) add_jar(foo foo.java res1.txt res2) file 'res2' will be ignored and not included in jar. Additional Information: Any workaround would be welcome. == Issue History Date ModifiedUsername FieldChange == 2012-06-27 14:17 Marcin Wojdyr 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 0013357]: CPACK macros in own copy of NSIS.template.in are still generated even though they are commented out
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13357 == Reported By:David Sandberg Assigned To: == Project:CMake Issue ID: 13357 Category: CPack Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2012-06-27 22:32 EDT Last Modified: 2012-06-27 22:32 EDT == Summary:CPACK macros in own copy of NSIS.template.in are still generated even though they are commented out Description: The parser of NSIS.template.in generates output for CPACK macros that are commented out (for example @CPACK_NSIS_CREATE_ICONS@). The parser only comments out the first row of the macro's output. Here's an example: CMakeLists.txt: set(CPACK_COMPONENTS_ALL APP1 APP2) NSIS.template.in (don't want it to install default icons because I need to use arguments in the shortcut collected during installation): ;@CPACK_NSIS_CREATE_ICONS@ This will generate the following output in project.nsi: ; CreateShortCut "$SMPROGRAMS\$STARTMENU_FOLDER\APP1.lnk" "$INSTDIR\bin\APP1.exe" CreateShortCut "$SMPROGRAMS\$STARTMENU_FOLDER\APP2.lnk" "$INSTDIR\bin\APP2.exe" == Issue History Date ModifiedUsername FieldChange == 2012-06-27 22:32 David Sandberg 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 0013358]: Error importing generated Eclipse project with LIBRARY_OUTPUT_PATH set to ${CMAKE_CURRENT_BINARY_DIR}
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=13358
==
Reported By:muhkuh
Assigned To:
==
Project:CMake
Issue ID: 13358
Category: CMake
Reproducibility:always
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2012-06-28 05:41 EDT
Last Modified: 2012-06-28 05:41 EDT
==
Summary:Error importing generated Eclipse project with
LIBRARY_OUTPUT_PATH set to ${CMAKE_CURRENT_BINARY_DIR}
Description:
Setting LIBRARY_OUTPUT_PATH to the current binary directory in a CMakeLists.txt
and using it with the "Eclipse CDT4 - MinGW Makefiles" generator creates an
Eclipse project that causes an error when being imported into an eclipse
workspace.
Steps to Reproduce:
1. Create CMakeLists.txt containing these two lines:
SET (LIBRARY_OUTPUT_PATH ${CMAKE_CURRENT_BINARY_DIR})
PROJECT ( Test )
2. Use the "Eclipse CDT4 - MinGW Makefiles" generator of cmake to create an
Eclipse project. It doesn't matter if an in source or out of source build is
done. For example CMakeLists.txt can reside in C:\TestProject\src and the
Eclipse project is created at C:\TestProject\build.
3. Import this project into an eclipse workspace.
An error message appears:
"Error processing changed links in project description file."
"Cannot create a link to C:\TestProject\build because it overlaps the locations
of the project that contains the linked resource."
Additional Information:
After removing the line that sets LIBRARY_OUTPUT_PATH the generated project can
be imported without errors.
Fortunately eclipse imports the generated project despite of the error message.
It's just quite annoying.
==
Issue History
Date ModifiedUsername FieldChange
==
2012-06-28 05:41 muhkuh 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 0013359]: Feature Request: performing the "Configure" step but not Generation with cmake command line tool (as in cmake-gui and ccmake)
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=13359 == Reported By:tetractius Assigned To: == Project:CMake Issue ID: 13359 Category: CMake Reproducibility:always Severity: major Priority: urgent Status: new == Date Submitted: 2012-06-28 07:11 EDT Last Modified: 2012-06-28 07:11 EDT == Summary:Feature Request: performing the "Configure" step but not Generation with cmake command line tool (as in cmake-gui and ccmake) Description: Feature Request: possibility to perform only the "Configure" step but not Generation with cmake command line tool (as is possible in cmake-gui and ccmake). I'm dealing with a very huge project (around 150 targets). Each target is defined in its own CMakeLists.txt inside the hierarchy and defines some variable for exposing some functionality related to the target its self (i.e. include path needed for using a library). But we have some cross dependencies. Because of that we have to perform a 2 step generation for creating the right cache. >From the developer perspective, if a change to a cache variable is required, sometime is easier to change the value in the CMakeLists.txt, remove the cache and rerun the configure/generate step, than surfing in the huge CMakeCache.txt or cmake-gui The problem when I use cmake command line is that in the "first" step (with previous CMakeCache.txt deleted) I will obtain: - the intermediate CMakeCache.txt to be used for the second step (this is exactly what I want) - the first intermediate (incomplete) version of building configuration (Makefile, vcproj). Doing this, when I run the compilation it will recompile the whole project (even files that don't need to be recompiled) because of huge changes in the building configurations. Instead, if for the first step I run only the configure step (by cmake-gui or by cmake sending an error), no build configuration are generated in the first step, and the resultant build conf of the complete second step (no artificial errors) rebuild only what is possibly really needed to be recompiled. So shortly: for automation purpose would be nice to have a cmake tool command line parameter (i.e. --build_cache_only) for configuring only the cache but not writing makefiles/vcproj exactly as cmake-gui/ccmake can do. Our current way is to "SEND_ERROR" during first generation only causing that only the intermediate cache is generated (but not build configuration files written) Steps to Reproduce: A sample of the cmake command line parameter that would be nice to have might be : cmake --build_cache_only or simply: cmake --configure (consistent with the cmake-gui) == Issue History Date ModifiedUsername FieldChange == 2012-06-28 07:11 tetractius 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 0013360]: Java add_jar() doesn't copy resources to build directory when make is run for the first time
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13360 == Reported By:Marcin Wojdyr Assigned To: == Project:CMake Issue ID: 13360 Category: Modules Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 2012-06-28 07:16 EDT Last Modified: 2012-06-28 07:16 EDT == Summary:Java add_jar() doesn't copy resources to build directory when make is run for the first time Description: With this CMakeLists.txt: cmake_minimum_required(VERSION 2.8.6) find_package(Java) include(UseJava) project(foo Java) add_jar(foo foo.java res1.txt) the first time I run "make" it fails with message: res1.txt : no such file or directory but when I run make again it works: [ 25%] Copying res1.txt to the build directory [100%] Built target foo Additional Information: Full session: $ cmake . CMake Warning at /usr/share/cmake/Modules/FindJava.cmake:120 (message): regex not supported: java version "1.7.0_03-icedtea" OpenJDK Runtime Environment (fedora-2.2.1.fc17.8-x86_64) OpenJDK 64-Bit Server VM (build 23.0-b21, mixed mode). Please report Call Stack (most recent call first): CMakeLists.txt:2 (find_package) -- Found Java: /bin/java (found version "..") -- Configuring done -- Generating done -- Build files have been written to: /run/mw/test/sub $ make Scanning dependencies of target foo [ 25%] Building Java objects for foo.jar [ 50%] Generating CMakeFiles/foo.dir/java_class_filelist [ 75%] Creating Java archive foo.jar res1.txt : no such file or directory make[2]: *** [foo.jar] Error 1 make[1]: *** [CMakeFiles/foo.dir/all] Error 2 make: *** [all] Error 2 $ make [ 25%] Copying res1.txt to the build directory [100%] Built target foo == Issue History Date ModifiedUsername FieldChange == 2012-06-28 07:16 Marcin Wojdyr 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 0013361]: Notes on FindPythonLibs(PYTHON_ADD_MODULE)
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=13361
==
Reported By:Daniel Franke
Assigned To:
==
Project:CMake
Issue ID: 13361
Category: Modules
Reproducibility:have not tried
Severity: tweak
Priority: normal
Status: new
==
Date Submitted: 2012-06-28 15:47 EDT
Last Modified: 2012-06-28 15:47 EDT
==
Summary:Notes on FindPythonLibs(PYTHON_ADD_MODULE)
Description:
A follow-up to http://public.kitware.com/Bug/view.php?id=10068.
Throughout the module file, the variable ${PYTHON_MODULE_PREFIX} is used
multiple times, but it is never set?! Funnily, the contents "empty" is actually
correct.
On MacOS, the required extension is .so, the default extension is .dylib:
IF(WIN32 AND NOT CYGWIN)
SET_TARGET_PROPERTIES(${_NAME} PROPERTIES SUFFIX ".pyd")
+ ELSE IF(APPLE)
+ SET_TARGET_PROPERTIES(${_NAME} PROPERTIES SUFFIX ".so")
ENDIF(WIN32 AND NOT CYGWIN)
Another function, say, PYTHON_INSTALL_MODULE that installs to
${CMAKE_INSTALL_PREFIX}/lib/python${PYTHON_VERSION_MAJOR}.${PYTHON_VERSION_MINOR}/site-packages
(or wherever the preferred location nowadays is), would be nice.
==
Issue History
Date ModifiedUsername FieldChange
==
2012-06-28 15:47 Daniel Franke 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 0013362]: Problems find/removing links using cmake
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=13362
==
Reported By:dakke
Assigned To:
==
Project:CMake
Issue ID: 13362
Category: CMake
Reproducibility:have not tried
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2012-06-30 02:29 EDT
Last Modified: 2012-06-30 02:29 EDT
==
Summary:Problems find/removing links using cmake
Description:
There is problems removing links using cmake. I get file not found error (though
it looks for the correct file at correct place).
Additional Information:
The command IF(EXISTS "$ENV{DESTDIR}${file}") fails on links.
==
Issue History
Date ModifiedUsername FieldChange
==
2012-06-30 02:29 dakke 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 0013363]: target_link_libraries does not sets target's include and link paths according to li
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13363 == Reported By:Orçun Gökbulut Assigned To: == Project:CMake Issue ID: 13363 Category: CMake Reproducibility:always Severity: feature Priority: normal Status: new == Date Submitted: 2012-06-30 11:50 WAT Last Modified: 2012-06-30 11:50 WAT == Summary:target_link_libraries does not sets target's include and link paths according to li Description: When target_link_libraries used with a cmake static library target as a link library, CMake does not combine linked static library targets include and linker directory paths to target's include and linker directory paths. Suppose that there is a directory like this; + Project | + Sub Project | | +-Dependencies | | |-Library.h | | |-Library.lib | |-CMakeLists.txt | |-SubProject.cpp |-Main.cpp |-CMakeLists.txt Content of SubProject/CMakeLists.txt; link_directories(Dependencies) include_directories(Dependencies) add_library(SubProject SubProject.cpp) target_link_library(SubProject Library.lib) Content of /CMakeLists.txt add_executable(Main) target_link_libraries(Main SubProject) This setup causes linker and include problems in visual studio becouse linker or compiler can not find Library.lib or Library.h while compiling Main target. In order to work around this problem we have to move link_directories and include_directories SubProject/CMakeLists.txt to /CMakeLists.txt. This work around causes problems in big projects which uses different libraries on different project configurations. In this kind of project, when a new sub project/module added to the project it's library and include directories should be added to /CMakeLists.txt. If a sub project's/module's dependent library has some constrains like platform dependency (like external library is a windows library and does not work on linux but we have a linux alternative which is implamented on an other sub project/module) we have to use many if clauses on include_directories and library_directory. In summary, missing of this feature prevents more moduler and non-centered project structures becouse we have to modify or maintain when a new module with non-shared library dependency added to project instead of just a simple add_subdirectory command. Steps to Reproduce: Create a project structure like this one; + Project | + Sub Project | | +-Dependencies | | |-Library.h | | |-Library.lib | |-CMakeLists.txt | |-SubProject.cpp |-Main.cpp |-CMakeLists.txt Content of SubProject/CMakeLists.txt; link_directories(Dependencies) include_directories(Dependencies) add_library(SubProject SubProject.cpp) target_link_library(SubProject Library.lib) Content of /CMakeLists.txt add_executable(Main) target_link_libraries(Main SubProject) Compiler can not find Library.lib when linking target named 'Main'. == Issue History Date ModifiedUsername FieldChange == 2012-06-30 11:50 Orçun Gökbulut 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 0013364]: BundleUtilities test fails
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=13364 == Reported By:Michael Palimaka Assigned To: == Project:CMake Issue ID: 13364 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2012-06-30 12:28 EDT Last Modified: 2012-06-30 12:28 EDT == Summary:BundleUtilities test fails Description: With both 2.8.8 release and git experimental build, the BundleUtilities test fails. The details can be seen here on the dashboard: http://open.cdash.org/testDetails.php?test=151819064&build=2404293 == Issue History Date ModifiedUsername FieldChange == 2012-06-30 12:28 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 0013366]: Ninja generator on windows does not take everything into account when checking the command line length limit
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=13366 == Reported By:Josh Faust Assigned To: == Project:CMake Issue ID: 13366 Category: CMake Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 2012-07-01 16:59 EDT Last Modified: 2012-07-01 16:59 EDT == Summary:Ninja generator on windows does not take everything into account when checking the command line length limit Description: When generating the ninja build files, on windows cmake will check the command line length and generate a response file if it's too long. It does this by checking the args and the build line passed to the ninja rule. This does not take into account, though, what the ninja rule actually expands to including any variables passed such as link flags, full executable path, etc. CMake sets the command line limit to 8000 characters on windows, though the actual limit is 8192. I'm assuming it's set to 8000 because it's trying to account for the lack of these flags, but this is not always enough. In rare cases the build can still fail with a "The command line is too long." error. In my specific case, these extra flags account for ~500 characters, while cmake only actually checks http://www.cmake.org/Bug/view.php?id=5058#c7700 characters -- and added together they're above the 8192 limit. The quick fix seems to be changing the max command line to be shorter (say, 7000) in cmNinjaNormalTargetGenerator.cxx:483. The real fix would be to retrieve the rule and expand all the variables in the command, which I do not see an easy way of doing after a quick look through the code. == Issue History Date ModifiedUsername FieldChange == 2012-07-01 16:59 Josh Faust 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 0013367]: Problem with Eclipse project generation : OpenGL and GLUT headers
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13367 == Reported By:Nicholas Yue Assigned To: == Project:CMake Issue ID: 13367 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2012-07-01 19:37 EDT Last Modified: 2012-07-01 19:37 EDT == Summary:Problem with Eclipse project generation : OpenGL and GLUT headers Description: Hi, I am using CMake 2.8.8 I have been generating Eclipse project and building my software successfully both on the command line and within Eclipse. However, when I open up my project in Eclipse, the indexer fails to find the necessary headers for OpenGL and GLUT Moreover, I noticed the following via ccmake GLUT_INCLUDE_DIR /System/Library/Frameworks/GLUT.framework/Headers OPENGL_INCLUDE_DIR /System/Library/Frameworks/OpenGL.framework Note the differences in the directory "Headers" Is there additional steps for the OS X platform so that code completion and C++ indexer works properly when using OpenGL and GLUT on OS X when generating Eclipse project files via CMake. == Issue History Date ModifiedUsername FieldChange == 2012-07-01 19:37 Nicholas Yue 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 0013370]: Visual Studio filter tree as source directory tree (with patch)
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=13370 == Reported By:LordJZ Assigned To: == Project:CMake Issue ID: 13370 Category: CMake Reproducibility:always Severity: feature Priority: normal Status: new == Date Submitted: 2012-07-02 17:35 EDT Last Modified: 2012-07-02 17:35 EDT == Summary:Visual Studio filter tree as source directory tree (with patch) Description: Currently, CMake groups the source files into 'Header Files', 'Source Files', etc. When there are quite a lot of files, it becomes hard to navigate through this mess. A lot of other IDEs make the same solution tree as directory tree. Netbeans in particular. I have created a rough patch to implement this feature for Visual Studio. Links: My CMake fork with this feature: https://github.com/LordJZ/CMake/commits/master Direct patch file: https://dl.dropbox.com/u/9241118/cmake.patch (also attached) An example of the resulting tree: https://dl.dropbox.com/u/9241118/cmake-file-tree-respect-trinitycore.png Compiled binaries for Windows: https://github.com/downloads/LordJZ/CMake/cmake-file-tree-respect.7z (no dependencies) There are some issues of the patch: 1) Works for Visual Studio 10 (2010 pre-release), Visual Studio 2010, Visual Studio 11 (2012 pre-release), and Visual Studio 2012. 2) My changes are not yet fixed to fit CMake coding style. 3) The patch eliminates in-Studio view of source groups (though they are not seen in other IDEs). Seems to deprecate bug http://www.cmake.org/Bug/view.php?id=11229. 4) Is possibly still affected by bug http://www.cmake.org/Bug/view.php?id=7921. RFC. == Issue History Date ModifiedUsername FieldChange == 2012-07-02 17:35 LordJZ New Issue 2012-07-02 17:35 LordJZ File Added: cmake.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 0013371]: Ninja: ADDITIONAL_MAKE_CLEAN_FILES is not supported
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=13371 == Reported By:Peter Kuemmel Assigned To:Peter Kuemmel == Project:CMake Issue ID: 13371 Category: CMake Reproducibility:always Severity: minor Priority: low Status: assigned == Date Submitted: 2012-07-03 09:12 EDT Last Modified: 2012-07-03 09:12 EDT == Summary:Ninja: ADDITIONAL_MAKE_CLEAN_FILES is not supported Description: No clean rule for ADITIONAL_MAKE_CLEAN_FILES content. http://www.cmake.org/pipermail/cmake/2012-April/049832.html == Issue History Date ModifiedUsername FieldChange == 2012-07-03 09:12 Peter Kuemmel New Issue 2012-07-03 09:12 Peter Kuemmel Status new => assigned 2012-07-03 09:12 Peter Kuemmel Assigned To => Peter Kuemmel == -- 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 0013374]: cmake_depends support for ninja
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13374 == Reported By:Joe Drago Assigned To: == Project:CMake Issue ID: 13374 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2012-07-03 21:06 EDT Last Modified: 2012-07-03 21:06 EDT == Summary:cmake_depends support for ninja Description: It looks like the makefile/NMakefile/jom generators leverage cmake's build-in command cmake_depends in order to generate header dependencies, but the new ninja generator doesn't use this, and instead has specific support for VS. I deal with a large cmake project at work which uses a compiler that is not based in either gcc or comes from MS, and in order for header deps to work at all, we depend on the jom generator's cmake_depends feature. Is there any way to add a (global?) option for the ninja generator which uses the cmDependsC/cmake_depends calls for implicit deps instead of requiring either -MMD compiler support or cmcldeps? == Issue History Date ModifiedUsername FieldChange == 2012-07-03 21:06 Joe Drago 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 0013375]: Xcode generator does not add path to source groups
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13375 == Reported By:Francois Best Assigned To: == Project:CMake Issue ID: 13375 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2012-07-04 18:54 EDT Last Modified: 2012-07-04 18:54 EDT == Summary:Xcode generator does not add path to source groups Description: The Xcode generator does not add the "path" information to generated source groups. All groups remain to the path of the project, although the architecture is generated and displayed correctly. The point of having the path set is to add new files directly to the right location from within Xcode (eg using template files) without having to duplicate/move anything, just to edit the CMakeLists.txt. Steps to Reproduce: Generate any Xcode project with source groups. Additional Information: Note: the group path system can be quite elaborated, using the parent group as a reference and using relative paths, but this might be a bit overkill, absolute path would do the job nicely. A problem with this is that one may want to create a source group that does not represent a physical folder on the fillesystem (just a way to sort things up). In this case (I don't know if that's easy to detect for you guys), a solution would be to keep the parent group path and define this group as "Relative to enclosing group". == Issue History Date ModifiedUsername FieldChange == 2012-07-04 18:54 Francois Best 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 0013376]: For unset variables IF(${var}) and IF(NOT ${var}) both return FALSE which fails to work for predefined vars such as CYGWIN
The following issue has been SUBMITTED.
==
http://cmake.org/Bug/view.php?id=13376
==
Reported By:Bruce Cartland
Assigned To:
==
Project:CMake
Issue ID: 13376
Category: CMake
Reproducibility:always
Severity: minor
Priority: low
Status: new
==
Date Submitted: 2012-07-04 22:59 EDT
Last Modified: 2012-07-04 22:59 EDT
==
Summary:For unset variables IF(${var}) and IF(NOT ${var})
both return FALSE which fails to work for predefined vars such as CYGWIN
Description:
(I'm a noob so please excuse if this is already report, not formatted correctly,
or invalid :)
See steps to reproduce.
Steps to Reproduce:
message(STATUS "CYGWIN = '${CYGWIN}'")
if(${CYGWIN})
message(STATUS "CYGWIN set")
else()
set(CYGWIN 0) #this "fixes" the problem and results in expected
behaviour
message(STATUS "CYGWIN not set")
endif()
if(NOT ${CYGWIN})
message(STATUS "CYGWIN not set")
else()
message(STATUS "CYGWIN set - or is it?")
endif()
Additional Information:
The script in steps to reproduce results in the following output:
-- CYGWIN = ''
-- CYGWIN not set
-- CYGWIN set - or is it?
Seems to me that FALSE should be defined to include blank as well as NO, etc OR
variables such as CYGWIN should be set to 0 and not left blank.
==
Issue History
Date ModifiedUsername FieldChange
==
2012-07-04 22:59 Bruce Cartland 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 0013377]: SET_TARGET_PROPERTIES: TARGET_PDB overriden by OUTPUT_NAME
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=13377
==
Reported By:Nodrev
Assigned To:
==
Project:CMake
Issue ID: 13377
Category: CMake
Reproducibility:always
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2012-07-05 10:10 EDT
Last Modified: 2012-07-05 10:10 EDT
==
Summary:SET_TARGET_PROPERTIES: TARGET_PDB overriden by
OUTPUT_NAME
Description:
when using both OUTPUT_NAME and TARGET_PDB properties, the pdb generated use
output_name to generate it's name, ignoring target_pdb that was explicitly
specified.
Steps to Reproduce:
I have two projects in my msvc solution that i generate using cmake, an exe and
a dll, both are named with the same name ("myrealname" in the following
example). So, as every cmake's target must be unique, i set a "myrealname"
target for the exe and "mydummytarget" for the dll. I use
"SET_TARGET_PROPERTIES" to change the dummy target output filename:
>>> set_target_properties(mydummytarget PROPERTIES OUTPUT_NAME myrealname) <<<
The problem with this setup, one of the too target pdb will be overwrited (as
they now both named "myrealname.pdb"). So I try to replace with this line:
>>> set_target_properties(mydummytarget PROPERTIES OUTPUT_NAME myrealname
TARGET_PDB mydummytarget) <<<
But the "TARGET_PDB" command is ignored, the pdb that is generated is named
"myrealname.pdb" instead of "mydummytarget.pdb" (it seems that output_name is
used to generate the name of the pdb even when it's explicitly defined by the
user using target_pdb").
Maybe the problem is from cmTarget.cxx file, but i'm not an cmake source expert,
so i'm not sure about that.
==
Issue History
Date ModifiedUsername FieldChange
==
2012-07-05 10:10 Nodrev 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 0013378]: FindPostgreSQL fails on Fedora/RHEL
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13378 == Reported By:Orion Poplawski Assigned To: == Project:CMake Issue ID: 13378 Category: Modules Reproducibility:have not tried Severity: minor Priority: normal Status: new == Date Submitted: 2012-07-05 13:33 EDT Last Modified: 2012-07-05 13:33 EDT == Summary:FindPostgreSQL fails on Fedora/RHEL Description: See https://bugzilla.redhat.com/show_bug.cgi?id=828467 for more info. Basically FindPostgeSQL parses /usr/include/pg_config.h, but on Fedora/RHEL this is a wrapper to resolve multilib support and so fails. This is a proposed patch to use pg_config instead. The author, Petr Machata, notes: This fetches all necessary values from pg_config. This required more changes in the code, and frankly I have no idea whether it works on Windows. == Issue History Date ModifiedUsername FieldChange == 2012-07-05 13:33 Orion PoplawskiNew Issue 2012-07-05 13:33 Orion PoplawskiFile Added: cmake-FindPostgreSQL.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 0013379]: Toolchain prefix not set correctly for Fortran projects
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13379 == Reported By:Yngve Inntjore Levinsen Assigned To: == Project:CMake Issue ID: 13379 Category: CMakeSetup Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2012-07-06 05:14 EDT Last Modified: 2012-07-06 05:14 EDT == Summary:Toolchain prefix not set correctly for Fortran projects Description: I have a project involving Fortran, C, and C++. I was writing a toolchain file for MinGW so I could compile Windows binaries on my Linux box. I had the following on the top of my CMakeLists.txt: project(name Fortran C CXX) In my toolchain file I sat the C, CXX and Fortran compiler, and root path. What I then noticed was that instead of using the AR/RANLIB with the MinGW prefix, it was using the default /usr/bin/[ar/ranlib]. This was solved simply by changing the order in the project line as described above, to instead read: project(name C CXX Fortran) (not having Fortran first). See also mail exchange: http://www.cmake.org/pipermail/cmake/2012-July/051136.html and attached two toolchain files in: http://www.cmake.org/pipermail/cmake/2012-July/051152.html Please ask if something is unclear. I should also add that I do not know the origin of the problem, so for what I know it does not need to be fortran related. Steps to Reproduce: Create a project with Fortran as the first enabled language Create a toolchain file which should enable a prefix for additional tools == Issue History Date ModifiedUsername FieldChange == 2012-07-06 05:14 Yngve Inntjore LevinsenNew 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 0013380]: Xcode paths generated incorrectly
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=13380
==
Reported By:Jay Sistar
Assigned To:
==
Project:CMake
Issue ID: 13380
Category: CMake
Reproducibility:always
Severity: major
Priority: high
Status: new
==
Date Submitted: 2012-07-06 07:46 EDT
Last Modified: 2012-07-06 07:46 EDT
==
Summary:Xcode paths generated incorrectly
Description:
This is problem is seen in 2 places:
1. CMake leaves the product paths (paths to library files and executables)
blank, so it's impossible to tell which has been build, and which hasn't.
2. Many paths in Xcode must be relative paths from the Xcode project for Xcode
to work properly. CMake accounts for this nuance, but it does so as if the
project file were at the root of the source. Doing any out of source builds (the
common case, I believe) results in the inability to open files in sub-projects
(projects that were included by a CMake "add_subdirectory(project_dir)" that has
a CMakeLists.txt with a "project(project_name)" statement at the top of it,
which were most likely external to the project, and through the use of git
submodules or similar mechanisms, were included as part of the build of the
outer project.
Steps to Reproduce:
I've attached a file called "TheMainApp.tar.bz2" It consists of an application
and 2 libraries. The application is at the root.
1. On a Mac with Xcode: from the root ("TheMainApp/") do a "mkdir build; cd
build; cmake -G Xcode .."
2. Do a "open TheMainApp.xcodeproj"
3. In the file browser panel (on the left side of the Xcode window) Look at the
"Product" folder, as well as the "ConsolePrinter" and "Sleeper" folders. You
will see that they are in red.
Under normal circumstances, the Product folder files will be red until they are
built, but because the path doesn't exist (that can be seen in Xcode 4 or later
in the panel on the right side of the window) these Products will always be red.
Additional Information:
It should be noted that everything still builds correctly, it's only the IDE
that has problems, but that seriously attenuates development speed in Xcode when
using CMake.
To whomever picks-up this ticket: Thank you very much for the great product that
is CMake! It has made my cross platform development much easier.
==
Issue History
Date ModifiedUsername FieldChange
==
2012-07-06 07:46 Jay Sistar New Issue
2012-07-06 07:46 Jay Sistar File Added: TheMainApp.tar.bz2
==
--
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 0013381]: /usr/include ignored by code::Blocks generator
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13381 == Reported By:Nicholas Katzakis Assigned To: == Project:CMake Issue ID: 13381 Category: (No Category) Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 2012-07-06 12:25 EDT Last Modified: 2012-07-06 12:25 EDT == Summary:/usr/include ignored by code::Blocks generator Description: include_directories(/usr/include) ^--- Even if I include this directive, if I open the project in Qt Creator it fails to build. Going to command prompt and doing "VERBOSE=1 make" reveals that /usr/include is not passed at all to the compiler (macports GCC 4.6 or 4.7.1). If on the other hand I use cmake's default generator (unix MakeFiles) then "/usr/include" is properly included. Steps to Reproduce: 1. include_directories(/usr/include) 2. use codeblocks generator == Issue History Date ModifiedUsername FieldChange == 2012-07-06 12:25 Nicholas KatzakisNew 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 0013383]: CMAKE Autodetect defaults to "NMake Makefiles" when "MinGW Makefiles" should be used.
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13383 == Reported By:Ken Phillis Assigned To: == Project:CMake Issue ID: 13383 Category: CCMake Reproducibility:always Severity: major Priority: high Status: new == Date Submitted: 2012-07-07 04:09 EDT Last Modified: 2012-07-07 04:09 EDT == Summary:CMAKE Autodetect defaults to "NMake Makefiles" when "MinGW Makefiles" should be used. Description: When i try to generate makefiles using the command line and gui program for cmake, the autodetection feature automatically forces the makefile generator to "NMake Makefiles". This behaviour is incorrect because I do not have visual studio installed at all, and it causes cmake to fail in a scenario where this should not happen. Steps to Reproduce: 1) Use a computer that has never had Visual Studio Installed. 2) Installing Visual studio runtimes is also ok. 3) Install Mingw GCC 4) Install gnu make 4) Install CMake ( i used the provided build of cmake-2.8.8-win32-x86.zip ) 5) Select any random cmake project that can be built using cmake and mingw. 6) As long as visual studio itself is not installed, get the dependencies for said project. 7) build makefiles ( cmake . ) 8) Compile project Additional Information: For pkg-config, see: the "Glib and PKG-CONFIG" at this page of the vlc wiki: http://wiki.videolan.org/Win32CompileMSYSNew The version of mingw gcc I used is tdm-gcc (mingw-w64 based). This is located at: http://tdm-gcc.tdragon.net/ For gnu make, I used the latest build using mingw-w64 located at: http://sourceforge.net/projects/mingw-w64/files/External%20binary%20packages%20%28Win64%20hosted%29/make/ A temporary solution is to specify the mingw generator each time you run the cmake, however this is extremely cumbersome and most end developers will probably not want to mess with this in any fashion. cmake . -G "MinGW Makefiles" as for an more permanent solution, It's possible to fix this by improving the autodetection code ( lines 2181 to 5 of Source/cmake.cxx ), or provide windows binaries that are made using mingw ( or mingw-w64) that have "CMAKE_BOOT_MINGW" defined. == Issue History Date ModifiedUsername FieldChange == 2012-07-07 04:09 Ken PhillisNew 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 0013384]: Inconsistent documentation for Project() command
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13384 == Reported By:Yuri Assigned To: == Project:CMake Issue ID: 13384 Category: CMake Reproducibility:always Severity: text Priority: normal Status: new == Date Submitted: 2012-07-09 02:34 EDT Last Modified: 2012-07-09 02:34 EDT == Summary:Inconsistent documentation for Project() command Description: Documentation states: "If a variable exists called CMAKE_PROJECT__INCLUDE_FILE" However code looks for "CMAKE_PROJECT__INCLUDE", i.e. without _FILE. == Issue History Date ModifiedUsername FieldChange == 2012-07-09 02:34 Yuri 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 0013385]: Ninja: LINK_LIBRARIES not spilled to response file
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13385 == Reported By:Zaheer Chothia Assigned To: == Project:CMake Issue ID: 13385 Category: CMake Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 2012-07-09 11:03 WAT Last Modified: 2012-07-09 11:03 WAT == Summary:Ninja: LINK_LIBRARIES not spilled to response file Description: * Command line length is limited on Windows. * To alleviate this, CMake places object files into a response file, but the same is not done for libraries. * This can pose a problem when the link line becomes too long. Steps to Reproduce: See attached testcase generator. Additional Information: I am primarily interested in a solution for the Ninja generator, although this issue affects other generators too (e.g. NMake, MinGW Makefiles). For further discussion see the mailing list: http://www.cmake.org/pipermail/cmake/2012-June/051065.html == Issue History Date ModifiedUsername FieldChange == 2012-07-09 11:03 Zaheer Chothia New Issue 2012-07-09 11:03 Zaheer Chothia File Added: testcase.sh == -- 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 0013386]: CPack-generated Debian packages do not comply to Debian policy (discovered via lintian)
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=13386
==
Reported By:Johannes Wienke
Assigned To:
==
Project:CMake
Issue ID: 13386
Category: CPack
Reproducibility:always
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2012-07-09 08:22 EDT
Last Modified: 2012-07-09 08:22 EDT
==
Summary:CPack-generated Debian packages do not comply to
Debian policy (discovered via lintian)
Description:
Running lintian on a CPack-generated Debian package produces the following
output (some warnings not related to CPack bugs have been removed; our package
name is "rsb0.7", the library is called "librsbcore.so"):
E: rsb0.7: control-file-has-bad-permissions md5sums 0640 != 0644
E: rsb0.7: no-copyright-file [1]
W: rsb0.7: non-standard-dir-perm usr/ 0700 != 0755[2]
W: rsb0.7: non-standard-dir-perm usr/bin/ 0700 != 0755
W: rsb0.7: non-standard-dir-perm usr/include/ 0700 != 0755
W: rsb0.7: non-standard-dir-perm usr/lib/ 0700 != 0755
W: rsb0.7: non-standard-dir-perm usr/share/ 0700 != 0755
E: rsb0.7: md5sums-lists-nonexisting-file usr/lib/librsbcore.so [3]
E: rsb0.7: no-shlibs-control-file usr/lib/librsbcore.so.0.7.0
E: rsb0.7: postinst-must-call-ldconfig usr/lib/librsbcore.so.0.7.0
Notes:
[1] We use SET(CPACK_RESOURCE_FILE_LICENSE
"${CMAKE_CURRENT_SOURCE_DIR}/COPYING.txt"), therefore CPack should use the
specified file as package license file
[2] The exact permissions and therefore error message depend on the current
umask. CPack should set a fixed, compliant umask independently of what the user
happens to use.
[3] This is caused by symlinking usr/lib/librsbcore.so to
usr/lib/librsbcore.so.0.7.0 which happens when sonames and -versions are used in
CMake.
Steps to Reproduce:
Our CMake and CPack files are a bit length to include here (viewable at
https://code.cor-lab.org/projects/rsb/repository/entry/trunk/cpp/core/CMakeLists.txt).
We called cpack (or make package) with fakeroot to achieve correct user- and
group-ids.
Packaging any CMake based library project should produce identical warnings.
==
Issue History
Date ModifiedUsername FieldChange
==
2012-07-09 08:22 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 0013387]: ARGV1 scope leak
The following issue has been SUBMITTED.
==
http://cmake.org/Bug/view.php?id=13387
==
Reported By:Clinton Stimpson
Assigned To:
==
Project:CMake
Issue ID: 13387
Category: CMake
Reproducibility:always
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2012-07-09 12:13 EDT
Last Modified: 2012-07-09 12:13 EDT
==
Summary:ARGV1 scope leak
Description:
ARGV1 values can leak into sub functions if they are optional arguments.
Steps to Reproduce:
cmake_minimum_required(VERSION 2.8)
function(bar arg)
set(bar_arg ${ARGV1})
message("bar_arg=${bar_arg}")
endfunction()
function(foo arg)
set(foo_arg "${ARGV1}")
message("foo_arg=${foo_arg}")
bar(${arg})
endfunction()
foo(dummy dummy2)
bar() was called with 1 argument, not 2. But the ARGV1 from foo() leaked into
the ARGV1 of bar().
==
Issue History
Date ModifiedUsername FieldChange
==
2012-07-09 12:13 Clinton StimpsonNew 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 0013388]: include("${NONEXISTENT_FILE_VARIABLE}" OPTIONAL) will add bogus dir dependency, causing frequent reconfigure runs
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=13388
==
Reported By:Andreas Mohr
Assigned To:
==
Project:CMake
Issue ID: 13388
Category: CMake
Reproducibility:always
Severity: major
Priority: normal
Status: new
==
Date Submitted: 2012-07-10 03:25 CDT
Last Modified: 2012-07-10 03:25 CDT
==
Summary:include("${NONEXISTENT_FILE_VARIABLE}" OPTIONAL)
will add bogus dir dependency, causing frequent reconfigure runs
Description:
A bogus include with an empty string (which may happen very frequently, namely
whenever a user uses a variable-based include() and does not bother to set the
variable)
will cause very wasteful CMake re-configure runs due to inserting a bogus
directory dependency (empty file argument seems to get evaluated to the current
source directory during module file lookup algorithms) for the build system to
consider for CMake re-configuration evaluation.
Steps to Reproduce:
CMakeLists.txt:
#include("" OPTIONAL)
Enabling that bogus include() and generating a Ninja build tree will cause the
following line in build.ninja:
# Re-run CMake if any of its inputs changed.
build build.ninja: RERUN_CMAKE |
/home/amoh/Projects/cmake_tests/include_hook_bug_test
/home/amoh/Projects/cmake_tests/include_hook_bug_test/CMakeLists.txt
/home/amoh/Projects/cmake_tests/include_hook_bug_test/build/CMakeFiles/CMakeCCompiler.cmake
/home/amoh/Projects/cmake_tests/include_hook_bug_test/build/CMakeFiles/CMakeCXXCompiler.cmake
/home/amoh/Projects/cmake_tests/include_hook_bug_test/build/CMakeFiles/CMakeSystem.cmake
/usr/local/share/cmake-2.8/Modules/CMakeCInformation.cmake
/usr/local/share/cmake-2.8/Modules/CMakeCXXInformation.cmake
/usr/local/share/cmake-2.8/Modules/CMakeCommonLanguageInclude.cmake
/usr/local/share/cmake-2.8/Modules/CMakeGenericSystem.cmake
/usr/local/share/cmake-2.8/Modules/CMakeSystemSpecificInformation.cmake
/usr/local/share/cmake-2.8/Modules/Compiler/GNU-C.cmake
/usr/local/share/cmake-2.8/Modules/Compiler/GNU-CXX.cmake
/usr/local/share/cmake-2.8/Modules/Compiler/GNU.cmake
/usr/local/share/cmake-2.8/Modules/Platform/Linux-GNU-C.cmake
/usr/local/share/cmake-2.8/Modules/Platform/Linux-GNU-CXX.cmake
/usr/local/share/cmake-2.8/Modules/Platform/Linux-GNU.cmake
/usr/local/share/cmake-2.8/Modules/Platform/Linux.cmake
/usr/local/share/cmake-2.8/Modules/Platform/UnixPaths.cmake CMakeCache.txt
Pay special attention to the mentioning of
/home/amoh/Projects/cmake_tests/include_hook_bug_test
Now if you actually modify the "stat" status quo of this source directory (say,
by editing a file in it via vim), then this will trigger - potentially VERY
lengthy! - CMake re-configure runs once re-running the build (via "ninja").
Same effect with Makefile generator.
Thank you!
==
Issue History
Date ModifiedUsername FieldChange
==
2012-07-10 03:25 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 0013390]: Tests/Assembler fails to link due to bare library-directory arguments
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13390 == Reported By:Daniel Richard G. Assigned To: == Project:CMake Issue ID: 13390 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2012-07-10 13:00 EDT Last Modified: 2012-07-10 13:00 EDT == Summary:Tests/Assembler fails to link due to bare library-directory arguments Description: >From http://open.cdash.org/testDetails.php?test=150972074&build=2429333 : Linking ASM executable HelloAsm /home/cport/Dashboards/MyTests/CMake-build/bin/cmake -E cmake_link_script CMakeFiles/HelloAsm.dir/link.txt --verbose=1 /usr/bin/gcc -mminimal-toc -O0 CMakeFiles/HelloAsm.dir/main.s.o -o HelloAsm /usr/lib /lib ld: 0711-168 SEVERE ERROR: Input file: /usr/lib Input files must be regular files. collect2: ld returned 12 exit status make[1]: *** [HelloAsm] Error 1 make[1]: Leaving directory `/home/cport/Dashboards/MyTests/CMake-build/Tests/Assembler' make: *** [CMakeFiles/HelloAsm.dir/all] Error 2 make: The error code from the last command is 2. Stop. I'm having trouble finding where the "/usr/lib /lib" bit in link.txt is coming from. == Issue History Date ModifiedUsername FieldChange == 2012-07-10 13:00 Daniel Richard G.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 0013391]: file(DOWNLOAD ...) not working on AIX
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13391 == Reported By:Daniel Richard G. Assigned To: == Project:CMake Issue ID: 13391 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2012-07-10 13:22 EDT Last Modified: 2012-07-10 13:22 EDT == Summary:file(DOWNLOAD ...) not working on AIX Description: >From http://open.cdash.org/testDetails.php?test=150972205&build=2429333 : -- FileDownload:1 -- FileDownload:2 -- [download 100% complete] -- FileDownload:3 CMake Error at FileDownloadTest.cmake:28 (file): file DOWNLOAD MD5 mismatch for file: [/home/cport/Dashboards/MyTests/CMake-build/Tests/CMakeTests/downloads/file3.png] expected MD5 sum: [d16778650db435bda3a8c3435c3ff5d1] actual MD5 sum: [d41d8cd98f00b204e9800998ecf8427e] All three "downloaded" files are empty (0 bytes). == Issue History Date ModifiedUsername FieldChange == 2012-07-10 13:22 Daniel Richard G.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
