[CMake] Post-Build commands on custom targets are always executed?

Oliver Buchtala oliver.buchtala at jku.at
Wed Apr 20 02:16:13 EDT 2011


Am 19.04.2011 16:10, schrieb David Cole:
> On Mon, Apr 18, 2011 at 11:22 PM, Michael Hertling
> <mhertling at online.de <mailto:mhertling at online.de>> wrote:
>
>     On 04/19/2011 02:17 AM, Oliver Buchtala wrote:
>     > Am 18.04.2011 06:58, schrieb Michael Hertling:
>     >> On 04/16/2011 12:05 AM, Oliver Buchtala wrote:
>     >>> Am 15.04.2011 23:48, schrieb Michael Hertling:
>     >>>> On 04/15/2011 11:22 PM, Oliver Buchtala wrote:
>     >>>>> Hi,
>     >>>>>
>     >>>>> I observe that a custom command attached to a custom target as
>     >>>>> POST-BUILD is launched on every build.
>     >>>>> Is that true? or is it a misconfiguration on my side?
>     >>>>>
>     >>>>> Bye,
>     >>>>> Oliver
>     >>>> A custom target is always out of date, i.e. it is always
>     rebuilt when
>     >>>> it is visited - as a prerequisite of another target or due to
>     the ALL
>     >>>> clause, e.g., and since the target has been rebuilt, each
>     associated
>     >>>> POST_BUILD custom command is rerun. Thus, the behaviour you
>     observed
>     >>>> is correct, expected and reasonable, IMO.
>     >>>>
>     >>>> Regards,
>     >>>>
>     >>>> Michael
>     >>> Yep. That's reasonable.
>     >>>
>     >>> Do have a suggestion how to get around a rerun of the post-build?
>     >> Prevent the custom target from being visited, i.e. from being
>     checked
>     >> if it's up to date since it will be found to be out of date, so the
>     >> immediately associated commands - if any - are run as well as the
>     >> associated POST_BUILD custom commands.
>     >>
>     >>> Or how would you do a post-build after custom-target without
>     being run
>     >>> when custom-target actually did nothing,
>     >> What do you mean with a custom target that "actually did
>     nothing"? Not
>     >> visited or no own commands? In the former case, the associated
>     custom
>     >> commands are not run, of course, but in the latter case, it
>     does not
>     >> matter if there are immediately associated commands or not
>     since the
>     >> target will be considered as out of date and
>     rebuilt-without-op, and
>     >> its POST_BUILD custom commands will be run. In other words: A
>     custom
>     >> target - even without own commands - is not good for preventing its
>     >> custom commands from being run when the custom target is visited.
>     >>
>     >>> i.e., custom target depends on custom command that did nothing?
>     >> The same holds for this kind of dependency, i.e. the visited custom
>     >> target will be rebuilt regardless whether the prerequisite custom
>     >> command did do something or not, or do you still talk about the
>     >> custom-command-associated-with-custom-target dependency?
>     >>
>     > Alright. Then, no way to get what i want with custom targets.
>     >
>     > I am asking, as I try to improve behavior with
>     UseJave.cmake::add_jar
>     > (on stage::next) which creates a custom target.
>     > E.g., after building the jar I want to copy the java archive into
>     > another destination (not install).
>
>     OK, I see; in fact, this would be a good job for a POST_BUILD custom
>     command associated with the custom target. Thus, as you can't prevent
>     the custom command from being run on behalf of the custom target, you
>     should set up the command to do nothing if there's actually nothing to
>     do. E.g., you might use "${CMAKE_COMMAND} -E copy_if_different ..." to
>     copy the updated-or-not-updated jar file, so the custom command is as
>     cheap as possible, although it always runs when the custom target is
>     examined. Moreover, "${CMAKE_COMMAND} -P ..." and the IF() command's
>     EXISTS and IS_NEWER_THAN clauses possibly provide further approaches
>     w.r.t. your concern.
>
>     Regards,
>
>     Michael
>
>     > As long as java support is on a weak basis (i.e., not built-in),
>     this
>     > won't change...
>     >
>     > Thank you for your help!
>     >
>     > Bye,
>     > Oliver
>     _______________________________________________
>     Powered by www.kitware.com <http://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://www.cmake.org/mailman/listinfo/cmake
>
>
>
> This is how I would do it:
>
> Why wouldn't you simply add *another* custom target that depends on
> the output of a custom command, and then make that custom command's
> output be your copy of the jar file, and then make the custom command
> depend on the "real" jar file?
>
> Then, the custom target would run "always" -- but it has no command,
> so there's never anything to do, but when the custom command's depends
> are out of date, it will execute, and the jar file will be copied...
>
> If you have something that depends on a file, then it should nearly
> always be a custom command.
>
> Custom targets are best at simply collecting related custom commands
> in. I've never found them that useful with commands associated
> directly in the add_custom_target call.
>
>
> HTH,
> David
>
>
> _______________________________________________
> 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://www.cmake.org/mailman/listinfo/cmake

Hi David,

I will go for your suggested solution in that particular case.

I was asking so eagerly to find out if there is some general way for
improving UseJava::add_jar.
Using that together with POST_BUILD commands will never be like using
POST_BUILDS on built-in targets like add_library.

Bye,
Oliver

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20110420/a8180f7f/attachment-0001.htm>


More information about the CMake mailing list