[cmake-developers] add_custom_command changes, was [Introductions and questions]

[Steve Wilson]

On Jan 24, 2014, at 3:25 PM, Steve Wilson <stevew at wolfram.com> 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 <lang1> depend1
                                      [<lang2> 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 $<$<CONFIG:…>:…>
	COMMAND $<$<CONFIG:…>:…>
	COMMAND $<$<CONFIG:…>:…>
	...
)

repeatedly, while having to embed my command inside the generator $<$<CONFIG:…>:…> 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?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 236 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20140129/9280220a/attachment-0002.sig>