Re: [cmake-developers] add_custom_command changes, was [Introductions and questions]
Sounds good. I will get this work prepared and submitted as soon as I can. SteveW On Feb 3, 2014, at 12:43 PM, Brad King wrote: > On 01/29/2014 05:54 PM, Steve Wilson wrote: >> Is there a need for the add_custom_command() version with CONFIG? > > Yes. Petr's example of handling per-config OUTPUT is one justification. > It is also easier to write and read code using the proposed CONFIG > option rather than generator expressions, especially when the command > is only to be executed in a subset of configurations. > > Thanks, > -Brad > > -- > > 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 signature.asc Description: Message signed with OpenPGP using GPGMail -- 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
Re: [cmake-developers] add_custom_command changes, was [Introductions and questions]
On 01/29/2014 05:54 PM, Steve Wilson wrote: > Is there a need for the add_custom_command() version with CONFIG? Yes. Petr's example of handling per-config OUTPUT is one justification. It is also easier to write and read code using the proposed CONFIG option rather than generator expressions, especially when the command is only to be executed in a subset of configurations. Thanks, -Brad -- 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
Re: [cmake-developers] add_custom_command changes, was [Introductions and questions]
Hi. I am only a CMake user, not a developer, but I wholeheartedly support adding the CONFIG keyword to add_custom_*(). While variations in COMMAND can be handled by generator expressions, variations in OUTPUT can't (see e.g. bug 12877). Thus, adding the CONFIG keyword would kill two (very annoying) birds with one stone. I have rather complex CMake framework at work, and this option would simplify it *tremendously.* So far, I've been working around it with EXCLUDE_FROM_DEFAULT_BUILD_, but it's painful. Petr On Wed, Jan 29, 2014 at 11:54 PM, Steve Wilson wrote: > > On Jan 24, 2014, at 3:25 PM, Steve Wilson wrote: > > > The first item I would like to see merged back to the project is issue > 9974 in the Mantis tracker (CMake should support custom commands that can > vary by configuration). I am the author of the original set of patches > submitted in that report. I did not have time to follow up on that Mantis > issue as responses developed, but can follow up now. > > In looking back through my changes for this issue and updating the changes > for the current sources, I've realized that generator expressions in custom > commands might be sufficient for my needs (my build system was initially > designed in 2009 and hasn't been significantly updated for new features > such as generator expressions). However there is one bug (14353) that > prevents them from being fully useful. My proposed changes for > add_custom_command would be the following: > > add_custom_command(OUTPUT output1 [output2 ...] > COMMAND command1 [ARGS] [args1...] > [COMMAND command2 [ARGS] [args2...] ...] > [MAIN_DEPENDENCY depend] > [DEPENDS [depends...]] > [IMPLICIT_DEPENDS depend1 > [ depend2] ...] > [WORKING_DIRECTORY dir] > [COMMENT comment] [VERBATIM] [APPEND] > [CONFIG Debug | MinSizeRel | Release | RelWithDebInfo > | ...]) > > add_custom_command(TARGET target > PRE_BUILD | PRE_LINK | POST_BUILD > COMMAND command1 [ARGS] [args1...] > [COMMAND command2 [ARGS] [args2...] ...] > [WORKING_DIRECTORY dir] > [COMMENT comment] [VERBATIM] > [CONFIG Debug | MinSizeRel | Release | RelWithDebInfo > | ...]) > > > The addition of course here is the CONFIG keyword that takes a > configuration argument. When add_custom_command() has a CONFIG argument, > all of the commands in the custom command only get executed if the build is > configured in the requisite configuration (or is selected in an IDE > configuration). > > > Currently generator expressions in custom commands cannot work for this > kind of usage because of bug 14353. In 14353 generator expressions that > have a space character (i.e. more content than just one word/command) don't > parse correctly and thus make complex custom commands that vary by > configuration impossible to construct. > > Is there a need for the add_custom_command() version with CONFIG? > > While the generator expressions make short add_custom_command() usages > work quite nicely I could see the case where the generator expression > syntax might become unwieldy for larger custom commands that have many > COMMAND statements.I personally would not want to write: > > add_custom_command(... > COMMAND $<$:...> > COMMAND $<$:...> > COMMAND $<$:...> > ... > ) > > repeatedly, while having to embed my command inside the generator > $<$:...> syntax. My build systems have custom commands for > Unix/Windows/etc... that require careful attention to make sure the commands > execute correctly in the platform specific command interpreters and the > $<$<>> syntax would just be an extra confusing layer to have to maintain. > Even though most usage cases would be fine with the generator > expressions, I would still find the add_custom_command() with the CONFIG > keyword useful for use with long custom commands. > > However, if everyone else thinks there is really no need for this form of > add_custom_command, then I would stop working on re-integrating my changes > into the source tree and work on 14353 instead. > > Opinions? > > -- > > 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 > -- 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://publi
Re: [cmake-developers] add_custom_command changes, was [Introductions and questions]
On Jan 24, 2014, at 3:25 PM, Steve Wilson wrote: > The first item I would like to see merged back to the project is issue 9974 > in the Mantis tracker (CMake should support custom commands that can vary by > configuration). I am the author of the original set of patches submitted in > that report. I did not have time to follow up on that Mantis issue as > responses developed, but can follow up now. In looking back through my changes for this issue and updating the changes for the current sources, I’ve realized that generator expressions in custom commands might be sufficient for my needs (my build system was initially designed in 2009 and hasn’t been significantly updated for new features such as generator expressions). However there is one bug (14353) that prevents them from being fully useful. My proposed changes for add_custom_command would be the following: add_custom_command(OUTPUT output1 [output2 ...] COMMAND command1 [ARGS] [args1...] [COMMAND command2 [ARGS] [args2...] ...] [MAIN_DEPENDENCY depend] [DEPENDS [depends...]] [IMPLICIT_DEPENDS depend1 [ depend2] ...] [WORKING_DIRECTORY dir] [COMMENT comment] [VERBATIM] [APPEND] [CONFIG Debug | MinSizeRel | Release | RelWithDebInfo | ...]) add_custom_command(TARGET target PRE_BUILD | PRE_LINK | POST_BUILD COMMAND command1 [ARGS] [args1...] [COMMAND command2 [ARGS] [args2...] ...] [WORKING_DIRECTORY dir] [COMMENT comment] [VERBATIM] [CONFIG Debug | MinSizeRel | Release | RelWithDebInfo | ...]) The addition of course here is the CONFIG keyword that takes a configuration argument. When add_custom_command() has a CONFIG argument, all of the commands in the custom command only get executed if the build is configured in the requisite configuration (or is selected in an IDE configuration). Currently generator expressions in custom commands cannot work for this kind of usage because of bug 14353. In 14353 generator expressions that have a space character (i.e. more content than just one word/command) don’t parse correctly and thus make complex custom commands that vary by configuration impossible to construct. Is there a need for the add_custom_command() version with CONFIG? While the generator expressions make short add_custom_command() usages work quite nicely I could see the case where the generator expression syntax might become unwieldy for larger custom commands that have many COMMAND statements. I personally would not want to write: add_custom_command(… COMMAND $<$:…> COMMAND $<$:…> COMMAND $<$:…> ... ) repeatedly, while having to embed my command inside the generator $<$:…> syntax. My build systems have custom commands for Unix/Windows/etc… that require careful attention to make sure the commands execute correctly in the platform specific command interpreters and the $<$<>> syntax would just be an extra confusing layer to have to maintain. Even though most usage cases would be fine with the generator expressions, I would still find the add_custom_command() with the CONFIG keyword useful for use with long custom commands. However, if everyone else thinks there is really no need for this form of add_custom_command, then I would stop working on re-integrating my changes into the source tree and work on 14353 instead. Opinions? signature.asc Description: Message signed with OpenPGP using GPGMail -- 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
