On Jan 24, 2014, at 3:25 PM, Steve Wilson <ste...@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?
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
