<div class="gmail_quote">On Mon, Apr 18, 2011 at 11:22 PM, Michael Hertling <span dir="ltr"><<a href="mailto:mhertling@online.de">mhertling@online.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div><div></div><div class="h5">On 04/19/2011 02:17 AM, Oliver Buchtala wrote:<br>
> Am 18.04.2011 06:58, schrieb Michael Hertling:<br>
>> On 04/16/2011 12:05 AM, Oliver Buchtala wrote:<br>
>>> Am 15.04.2011 23:48, schrieb Michael Hertling:<br>
>>>> On 04/15/2011 11:22 PM, Oliver Buchtala wrote:<br>
>>>>> Hi,<br>
>>>>><br>
>>>>> I observe that a custom command attached to a custom target as<br>
>>>>> POST-BUILD is launched on every build.<br>
>>>>> Is that true? or is it a misconfiguration on my side?<br>
>>>>><br>
>>>>> Bye,<br>
>>>>> Oliver<br>
>>>> A custom target is always out of date, i.e. it is always rebuilt when<br>
>>>> it is visited - as a prerequisite of another target or due to the ALL<br>
>>>> clause, e.g., and since the target has been rebuilt, each associated<br>
>>>> POST_BUILD custom command is rerun. Thus, the behaviour you observed<br>
>>>> is correct, expected and reasonable, IMO.<br>
>>>><br>
>>>> Regards,<br>
>>>><br>
>>>> Michael<br>
>>> Yep. That's reasonable.<br>
>>><br>
>>> Do have a suggestion how to get around a rerun of the post-build?<br>
>> Prevent the custom target from being visited, i.e. from being checked<br>
>> if it's up to date since it will be found to be out of date, so the<br>
>> immediately associated commands - if any - are run as well as the<br>
>> associated POST_BUILD custom commands.<br>
>><br>
>>> Or how would you do a post-build after custom-target without being run<br>
>>> when custom-target actually did nothing,<br>
>> What do you mean with a custom target that "actually did nothing"? Not<br>
>> visited or no own commands? In the former case, the associated custom<br>
>> commands are not run, of course, but in the latter case, it does not<br>
>> matter if there are immediately associated commands or not since the<br>
>> target will be considered as out of date and rebuilt-without-op, and<br>
>> its POST_BUILD custom commands will be run. In other words: A custom<br>
>> target - even without own commands - is not good for preventing its<br>
>> custom commands from being run when the custom target is visited.<br>
>><br>
>>> i.e., custom target depends on custom command that did nothing?<br>
>> The same holds for this kind of dependency, i.e. the visited custom<br>
>> target will be rebuilt regardless whether the prerequisite custom<br>
>> command did do something or not, or do you still talk about the<br>
>> custom-command-associated-with-custom-target dependency?<br>
>><br>
> Alright. Then, no way to get what i want with custom targets.<br>
><br>
> I am asking, as I try to improve behavior with UseJave.cmake::add_jar<br>
> (on stage::next) which creates a custom target.<br>
> E.g., after building the jar I want to copy the java archive into<br>
> another destination (not install).<br>
<br>
</div></div>OK, I see; in fact, this would be a good job for a POST_BUILD custom<br>
command associated with the custom target. Thus, as you can't prevent<br>
the custom command from being run on behalf of the custom target, you<br>
should set up the command to do nothing if there's actually nothing to<br>
do. E.g., you might use "${CMAKE_COMMAND} -E copy_if_different ..." to<br>
copy the updated-or-not-updated jar file, so the custom command is as<br>
cheap as possible, although it always runs when the custom target is<br>
examined. Moreover, "${CMAKE_COMMAND} -P ..." and the IF() command's<br>
EXISTS and IS_NEWER_THAN clauses possibly provide further approaches<br>
w.r.t. your concern.<br>
<br>
Regards,<br>
<font color="#888888"><br>
Michael<br>
</font><div><div></div><div class="h5"><br>
> As long as java support is on a weak basis (i.e., not built-in), this<br>
> won't change...<br>
><br>
> Thank you for your help!<br>
><br>
> Bye,<br>
> Oliver<br>
_______________________________________________<br>
Powered by <a href="http://www.kitware.com" target="_blank">www.kitware.com</a><br>
<br>
Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
<br>
Please keep messages on-topic and check the CMake FAQ at: <a href="http://www.cmake.org/Wiki/CMake_FAQ" target="_blank">http://www.cmake.org/Wiki/CMake_FAQ</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="http://www.cmake.org/mailman/listinfo/cmake" target="_blank">http://www.cmake.org/mailman/listinfo/cmake</a><br>
</div></div></blockquote></div><br><br>This is how I would do it:<br>
<br>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?<br>
<br>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...<br>
<br>If you have something that depends on a file, then it should nearly always be a custom command.<br><br>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.<br>
<br><br>HTH,<br>David<br><br>