[cmake-developers] Ninja: Regressions re. def file handling with MSVC
Hi, Please note that commit a2514f15fae34abb6f29dddf6f5cfe8b171a8035 broke the handling of def files when using MSVC. We get errors like: ninja: ERROR: 'reactos\base\applications\kbswitch\kbsdll\kbsdll.def', needed by 'base\applications\kbswitch\kbsdll\kbsdll.dll', missing and no known rule to make it I found this revision by doing a bisect, I hope this will help solving this issue. In the gcc build we declare this generated def as an external object, but if I do the same with the MSVC build, the def file gets inserted into the link command twice: * The first one directly, i.e. link.exe /nologo rest of the link command> * The second time, it's passed using a /DEF: Needless to say, the first insertion is spurious and invalid, and it triggers " : fatal error LNK1107: invalid or corrupt file: cannot read at 0x3BBD. Regards, Amine. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please 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 0013091]: add enum like options
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13091 == Reported By:Christoph Anton Mitterer Assigned To: == Project:CMake Issue ID: 13091 Category: CCMake Reproducibility:always Severity: feature Priority: normal Status: new == Date Submitted: 2012-03-31 19:10 EDT Last Modified: 2012-03-31 19:10 EDT == Summary:add enum like options Description: Hi. I know this is a duplicate of bugs http://public.kitware.com/Bug/view.php?id=7313 and http://public.kitware.com/Bug/view.php?id=1527 and the (not longer existing?) http://public.kitware.com/Bug/view.php?id=39. I also know there is no real way of implementing enums, given the way cmake works. But can't the following be done: If for any variable "foo" a variable like "foo_ALLOWED_VALUES" exist, then and UIs (like ccmake, etc.) are allowed to interpret this variable in order to restrict the possible user inputs (yes I know it will still be possible via manual editing and via the command line to set any value). For the syntax of "foo_ALLOWED_VALUES" I'd recommend a extensible format e.g.: ":" Perhaps starting with the two types: enum regexp 1) enum could be something like this: enum:value[|value]* Where value is a allowed value. 2) regexp: could be something like this: regexp:: With regexp-type being for example POSIX_BRE for POSIX Basic Regular Expressions, or POSIX_ERE for POSIX Extended Regular Expressions. Maybe later one could add PCRE. expression would be the regular expression that must be matched for a value to be allowed. Why (1)? (2) would not allow for UIs to make choices (e.g. drop down lists), at least not easily. Chris. == Issue History Date ModifiedUsername FieldChange == 2012-03-31 19:10 Christoph Anton MittererNew 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 0013090]: three checks for more or less the same purpose (checking for include files)
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13090 == Reported By:Christoph Anton Mitterer Assigned To: == Project:CMake Issue ID: 13090 Category: Modules Reproducibility:always Severity: feature Priority: low Status: new == Date Submitted: 2012-03-31 15:42 EDT Last Modified: 2012-03-31 15:42 EDT == Summary:three checks for more or less the same purpose (checking for include files) Description: Hi. Maybe I just oversee something but to me it seems that: CheckIncludeFile.cmake CheckIncludeFileCXX.cmake CheckIncludeFiles.cmake do more or less the same and it should be possible to unify them / drop the others? Currently this seems to make just confusion on which to use. Chris. == Issue History Date ModifiedUsername FieldChange == 2012-03-31 15:42 Christoph Anton MittererNew 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 0013089]: lists parsing is quite strange and not as documented
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=13089
==
Reported By:Christoph Anton Mitterer
Assigned To:
==
Project:CMake
Issue ID: 13089
Category: CMake
Reproducibility:always
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2012-03-31 15:39 EDT
Last Modified: 2012-03-31 15:39 EDT
==
Summary:lists parsing is quite strange and not as documented
Description:
Hi.
http://www.cmake.org/cmake/help/syntax.html
tells that lists are set like:
set(VAR a;b;c)
or
set(VAR a b c)
However, when using string literals this doesn't work anymore, e.g.
1) List items separated by semicolons
set(foo "1 1";"2 2";"3 3")
message(${foo})
foreach(ff IN LISTS foo)
message("dd: ${ff}")
endforeach()
=> yields in:
1 1"2 2""3 3"
dd: 1 1
dd: "2 2"
dd: "3 3"
2) List items separated by spaces
set(foo "1 1" "2 2" "3 3")
message(${foo})
foreach(ff IN LISTS foo)
message("dd: ${ff}")
endforeach()
=> yields in:
1 12 23 3
dd: 1 1
dd: 2 2
dd: 3 3
(2) Is obviously what one would expect in both cases.
Cheers,
Chris.
==
Issue History
Date ModifiedUsername FieldChange
==
2012-03-31 15:39 Christoph Anton MittererNew 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 0013085]: Unable to run custom NSIS commands before installation
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=13085 == Reported By:David Golub Assigned To: == Project:CMake Issue ID: 13085 Category: CPack Reproducibility:N/A Severity: minor Priority: normal Status: new == Date Submitted: 2012-03-31 13:24 EDT Last Modified: 2012-03-31 13:24 EDT == Summary:Unable to run custom NSIS commands before installation Description: CPack provides the ability to run custom NSIS commands at the end of the setup process by setting the variable CPACK_NSIS_EXTRA_INSTALL_COMMANDS. However, there way to specify custom commands to run at the beginning of the setup process before files are copied. I'd like to submit a patch to address this issue. diff --git a/Modules/CPackNSIS.cmake b/Modules/CPackNSIS.cmake --- a/Modules/CPackNSIS.cmake +++ b/Modules/CPackNSIS.cmake @@ -29,8 +29,13 @@ ##end # ##variable +# CPACK_NSIS_EXTRA_PREINSTALL_COMMANDS - Extra NSIS commands that will +# be added to the beginning of the install Section. +##end +# +##variable # CPACK_NSIS_EXTRA_INSTALL_COMMANDS - Extra NSIS commands that will -# be added to the install Section. +# be added to the end of the install Section. ##end # ##variable diff --git a/Modules/NSIS.template.in b/Modules/NSIS.template.in --- a/Modules/NSIS.template.in +++ b/Modules/NSIS.template.in @@ -637,6 +637,7 @@ ;Use the entire tree produced by the INSTALL target. Keep the ;list of directories here in sync with the RMDir commands below. SetOutPath "$INSTDIR" + @CPACK_NSIS_EXTRA_PREINSTALL_COMMANDS@ @CPACK_NSIS_FULL_INSTALL@ ;Store installation folder == Issue History Date ModifiedUsername FieldChange == 2012-03-31 13:24 David GolubNew Issue == -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0013084]: FindCUDA is adding libcuda.so, but this is part of driver and not CUDA Runtime.
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=13084
==
Reported By:Vladislav
Assigned To:
==
Project:CMake
Issue ID: 13084
Category: CMake
Reproducibility:always
Severity: major
Priority: normal
Status: new
==
Date Submitted: 2012-03-31 17:25 YEKST
Last Modified: 2012-03-31 17:25 YEKST
==
Summary:FindCUDA is adding libcuda.so, but this is part of
driver and not CUDA Runtime.
Description:
FindCUDA shan't add libcuda.so library by default as it adds dependence on the
NVIDIA driver. It leads to impossibility of creation of one executable file
which can be launched regardless of NVIDIA GPU existence.
For example, it is watched in heterogeneous computing clusters when only a part
of nodes GPU are equipped.
See thread on NVIDIA forum: http://forums.nvidia.com/index.php?showtopic=190729
To fix this issue need remove next code from FindCUDA.cmake:
> # Add cuda library to the link line only if it is found.
> if (CUDA_CUDA_LIBRARY)
> set(CUDA_LIBRARIES ${CUDA_LIBRARIES} ${CUDA_CUDA_LIBRARY})
> endif(CUDA_CUDA_LIBRARY)
==
Issue History
Date ModifiedUsername FieldChange
==
2012-03-31 17:25 Vladislav 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
