Thanks for the feedback! Here is an updated patch that uses a hash as filename, .cmd as extension, boolean argument, and some error checks.
Martin On Fri, May 20, 2016 at 3:40 PM Brad King <brad.k...@kitware.com> wrote: > On 05/20/2016 03:41 AM, Martin Ankerl wrote: > > From what I have understood it seems more safe to use .bat and not > > .cmd, because the behavior of the errorlevel is different. From > > > http://waynes-world-it.blogspot.co.at/2008/08/difference-between-bat-and-cmd.html > : > > > >> The differences between .CMD and .BAT as far as CMD.EXE is concerned > are: > >> With extensions enabled, PATH/APPEND/PROMPT/SET/ASSOC in .CMD files > will set > >> ERRORLEVEL regardless of error. .BAT sets ERRORLEVEL only on errors. > > I read that to mean the opposite: cmd is better than bat because it will > always set ERRORLEVEL even if it is to zero, so one can reliably determine > whether a command worked (Git's wrapper on windows is git.cmd and not > git.bat). > > > I've created a first attempt of this implementation, please see the > attached > > patch. > > Good start. > > > + // TODO fail if command is too long and no file specified > > Several of the call sites of BuildCommandLine are constructing > commands using ninja's $VAR reference/placeholder syntax. For > these call sites it is never safe to use a separate cmdFile. > Fortunately they tend to be for compiler/linker invocations > that can use the normal RSP_FILE approach. > > Instead of adding a cmdFile argument to BuildCommandLine, add > a boolean (or enum) to indicate whether the commands hold any > placeholders. Only when no placeholders are used is it safe to > activate the new behavior. When activated, I think it is > cleaner to use a hash of the command line as the cmdFile name. > That way when the command changes Ninja will be aware of the > change and re-run it. > > Thanks, > -Brad > > -- Martin
0001-Support-for-many-custom-commands-in-Windows.patch
Description: Binary data
-- 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
