[cmake-developers] [CMake 0015630]: ENABLE_EXPORTS value is not used for gcc makefile -rdynamic option
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=15630 == Reported By:Nicolas Deherly Assigned To: == Project:CMake Issue ID: 15630 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2015-06-24 04:32 EDT Last Modified: 2015-06-24 04:32 EDT == Summary:ENABLE_EXPORTS value is not used for gcc makefile -rdynamic option Description: Whatever is the value of ENABLE_EXPORTS, executable are linked with the -rdynamic option. I have to reset the __linux_compiler_gnu macro to link without -rdynamic parameter. Additional Information: This bug has already been opened (9985). == Issue History Date ModifiedUsername FieldChange == 2015-06-24 04:32 Nicolas DeherlyNew Issue == -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Add command line options for deprecation message control
Thanks for the comments, here is the previous patch, with the suggested amendments. Cheers, Michael On 24/06/2015 15:45, Brad King wrote: On 06/23/2015 03:57 PM, Michael Scott wrote: I've implemented some changes to cmake.cxx and cmake.h, to implement setting the CMAKE_ERROR_DEPRECATED and CMAKE_WARN_DEPRECATED variables via command line options, for the Mantis issue 0014669, in a generic GCC style pattern. I've taken on board the previous suggestions, including adding tests for the new options and updating the cmake application options documentation. I've attached the proposed patch to this email, please let me know if there are any incorrect changes in the patch. Thanks. Here are some comments: * Please update the Help/variable/CMAKE_*_DEPRECATED.rst documents to mention the appropriate command-line options, perhaps with a :manual:`cmake(1)` link. * Please add a Help/release/dev/cmake-Wdeprecated.rst file with a release note mentioning the options. * Please ensure all sources added/modified by the patch have a newline on the last line (but not a trailing blank line). Thanks, -Brad From a588e904c414270c78465b6423c89ece52801fbd Mon Sep 17 00:00:00 2001 From: Michael Scott michael.scott...@gmail.com Date: Sat, 13 Jun 2015 18:34:31 +0100 Subject: [PATCH] Refactored the -Wdev and -Wno-dev to use a generic -W parser, which follows the GCC pattern. Included support for setting CMAKE_ERROR_DEPRECATED and CMAKE_WARN_DEPRECATED via the deprecated warning. Added tests for new options and updated cmake documentation and release notes to list new options. --- Help/manual/OPTIONS_BUILD.txt | 24 + Help/release/dev/cmake-Wdeprecated.rst | 9 ++ Help/variable/CMAKE_ERROR_DEPRECATED.rst | 4 + Help/variable/CMAKE_WARN_DEPRECATED.rst| 4 + Source/cmake.cxx | 112 + Source/cmake.h | 23 +++-- Tests/RunCMake/CommandLine/RunCMakeTest.cmake | 37 +++ Tests/RunCMake/CommandLine/W_bad-arg1-result.txt | 1 + Tests/RunCMake/CommandLine/W_bad-arg1-stderr.txt | 2 + Tests/RunCMake/CommandLine/W_bad-arg2-result.txt | 1 + Tests/RunCMake/CommandLine/W_bad-arg2-stderr.txt | 2 + Tests/RunCMake/CommandLine/W_bad-arg3-result.txt | 1 + Tests/RunCMake/CommandLine/W_bad-arg3-stderr.txt | 2 + Tests/RunCMake/CommandLine/Wdeprecated-stderr.txt | 4 + Tests/RunCMake/CommandLine/Wdeprecated.cmake | 1 + .../CommandLine/Werror_deprecated-result.txt | 1 + .../CommandLine/Werror_deprecated-stderr.txt | 4 + Tests/RunCMake/CommandLine/Werror_deprecated.cmake | 1 + Tests/RunCMake/CommandLine/Wno-deprecated.cmake| 1 + .../CommandLine/Wno-error_deprecated.cmake | 1 + 20 files changed, 207 insertions(+), 28 deletions(-) create mode 100644 Help/release/dev/cmake-Wdeprecated.rst create mode 100644 Tests/RunCMake/CommandLine/W_bad-arg1-result.txt create mode 100644 Tests/RunCMake/CommandLine/W_bad-arg1-stderr.txt create mode 100644 Tests/RunCMake/CommandLine/W_bad-arg2-result.txt create mode 100644 Tests/RunCMake/CommandLine/W_bad-arg2-stderr.txt create mode 100644 Tests/RunCMake/CommandLine/W_bad-arg3-result.txt create mode 100644 Tests/RunCMake/CommandLine/W_bad-arg3-stderr.txt create mode 100644 Tests/RunCMake/CommandLine/Wdeprecated-stderr.txt create mode 100644 Tests/RunCMake/CommandLine/Wdeprecated.cmake create mode 100644 Tests/RunCMake/CommandLine/Werror_deprecated-result.txt create mode 100644 Tests/RunCMake/CommandLine/Werror_deprecated-stderr.txt create mode 100644 Tests/RunCMake/CommandLine/Werror_deprecated.cmake create mode 100644 Tests/RunCMake/CommandLine/Wno-deprecated.cmake create mode 100644 Tests/RunCMake/CommandLine/Wno-error_deprecated.cmake diff --git a/Help/manual/OPTIONS_BUILD.txt b/Help/manual/OPTIONS_BUILD.txt index 4207db4..5366cae 100644 --- a/Help/manual/OPTIONS_BUILD.txt +++ b/Help/manual/OPTIONS_BUILD.txt @@ -84,3 +84,27 @@ Enable warnings that are meant for the author of the CMakeLists.txt files. + +``-Wdeprecated`` + Enable deprecated macro and function warnings. + + Enable warnings for usage of deprecated macros and functions, that are meant + for the author of the CMakeLists.txt files. + +``-Wno-deprecated`` + Suppress deprecated macro and function warnings. + + Suppress warnings for usage of deprecated macros and functions, that are meant + for the author of the CMakeLists.txt files. + +``-Werror=deprecated`` + Make deprecated macro and function warnings errors. + + Make warnings for usage of deprecated macros and functions, that are meant + for the author of the CMakeLists.txt files, errors. + +``-Wno-error=deprecated`` + Make deprecated macro and function warnings not errors. + + Make warnings for usage of deprecated macros and functions, that are meant + for the author of the CMakeLists.txt files, not errors. diff
Re: [cmake-developers] Add command line options for deprecation message control
On 06/23/2015 03:57 PM, Michael Scott wrote: I've implemented some changes to cmake.cxx and cmake.h, to implement setting the CMAKE_ERROR_DEPRECATED and CMAKE_WARN_DEPRECATED variables via command line options, for the Mantis issue 0014669, in a generic GCC style pattern. I've taken on board the previous suggestions, including adding tests for the new options and updating the cmake application options documentation. I've attached the proposed patch to this email, please let me know if there are any incorrect changes in the patch. Thanks. Here are some comments: * Please update the Help/variable/CMAKE_*_DEPRECATED.rst documents to mention the appropriate command-line options, perhaps with a :manual:`cmake(1)` link. * Please add a Help/release/dev/cmake-Wdeprecated.rst file with a release note mentioning the options. * Please ensure all sources added/modified by the patch have a newline on the last line (but not a trailing blank line). Thanks, -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [PATCH] Discussion needed: FindBISON: refine VERBOSE feature of BISON_TARGET
2015-06-22 22:39 GMT+09:00 Brad King brad.k...@kitware.com:
On 06/21/2015 09:06 AM, 정언 wrote:
internal macro defines a custom command that makes a copy of the
default named report file to the specified file path. The custom
command is not invoked until any other command requires the file,
for example, from its dependencies.
This could be fixed by moving the copy logic to a second COMMAND
argument to the add_custom_command for the actual bison invocation.
This can't be a solution.
Suppose we have a bison file `foo.y`. We get `foo.tab.c` and
`foo.tab.h` (in default) as a result of running bison, and
additionally `foo.output` if we put `--verbose`. What we need is, for
example, `foo.verbose` with the same content as `foo.output`.
The copying command should be run right after each execution of bison.
However, add_custom_command never guarantees a running order of
internal commands. The documentation says, the commands can run
parallel so never ever put commands with implicit dependencies.
Please see
http://www.cmake.org/cmake/help/v3.3/command/add_custom_command.html
for details.
Again, we have two custom commands as a result of passing `VERBOSE` to
bison_target(). One runs bison, and the other runs cp. The former one
produces header and source, BISON_${Name}_OUTPUTS. That's all, and
most of targets are only dependent on them. Even FindFLEX example
does:
http://www.cmake.org/cmake/help/v3.3/module/FindFLEX.html
Please see the last example with add_executable(). So, in many cases
we don't have any dependencies over the file by VERBOSE, the latter
command (cp) will never run.
How about making the former command dependent on the latter one? Doing
that causes circular dependencies, because the latter is obviously
dependent on the former, by `foo.output`.
To avoid circular dependencies, we might have three custom commands in
total; the first runs bison; the second runs cp which is dependent on
the first; the third is dependent on the first and on the second.
However, dependencies over BISON_${Name}_OUTPUTS would run the first
one only.
Or using add_custom_target? I'm not sure.
I think VERBOSE can't be fixed to behave right.
And this:
I think that can be added as a separate REPORT_FILE option that is
considered separately from the VERBOSE option and uses --report-file.
It could be an error if the discovered bison tool does not support
the option.
I think what I intended is misunderstood because of my poor
explanation; my fault.
If VERBOSE behaved right, REPORT_FILE would not have any benefits over
it. But it doesn't. Should we keep VERBOSE not changed in this case,
so almost same functionalities defined duplicate? I'm not sure either.
Thanks.
Eon
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [PATCH] Discussion needed: FindBISON: refine VERBOSE feature of BISON_TARGET
On 06/24/2015 11:13 AM, 정언 wrote:
The copying command should be run right after each execution of bison.
Yes.
However, add_custom_command never guarantees a running order of
internal commands. The documentation says, the commands can run
parallel so never ever put commands with implicit dependencies.
I'm not sure what text from the documentation you're referencing,
but I think that is warning about listing one output in multiple
independent targets, e.g.
add_custom_command(OUTPUT out.txt ...)
add_custom_target(tgt1 DEPENDS out.txt)
add_custom_target(tgt2 DEPENDS out.txt)
That is not the case here.
Again, we have two custom commands as a result of passing `VERBOSE` to
bison_target(). One runs bison, and the other runs cp.
We only need one add_custom_command call. It can list both outputs
and have two COMMAND arguments. Something like (untested):
if(...)
set(_maybe_copy_verbose_output ${BISON_TARGET_ARG_VERBOSE})
set(_maybe_copy_verbose_command
COMMAND ${CMAKE_COMMAND} -E copy
${BISON_TARGET_output_path}/${BISON_TARGET_output_name}.output
${BISON_TARGET_ARG_VERBOSE}
)
endif()
add_custom_command(OUTPUT ${BISON_TARGET_outputs}
${_maybe_copy_verbose_output}
${BISON_TARGET_extraoutputs}
COMMAND ${BISON_EXECUTABLE} ${BISON_TARGET_cmdopt} -o ${BisonOutput}
${BisonInput}
${_maybe_copy_verbose_command}
DEPENDS ${BisonInput}
COMMENT [BISON][${Name}] Building parser with bison ${BISON_VERSION}
WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR})
When both COMMAND options are present they will run sequentially.
If VERBOSE behaved right, REPORT_FILE would not have any benefits over it.
Wouldn't it be able to skip the intermediate file and copy step?
-Brad
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
