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

Petr Kmoch petr.kmoch at gmail.com
Thu Jan 30 03:18:34 EST 2014


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_<CONFIG>, but it's painful.

Petr


On Wed, Jan 29, 2014 at 11:54 PM, Steve Wilson <stevew at wolfram.com> wrote:

>
> 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?
>
> --
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20140130/86b7302f/attachment-0002.html>


More information about the cmake-developers mailing list