2015-06-22 22:39 GMT+09:00 Brad King <[email protected]>: > 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
