<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
    <title></title>
  </head>
  <body text="#000000" bgcolor="#ffffff">
    Am 19.04.2011 16:10, schrieb David Cole:
    <blockquote
      cite="mid:BANLkTimGrM1=XQeOejzEN3+bqA2MGQO2yg@mail.gmail.com"
      type="cite">
      <div class="gmail_quote">On Mon, Apr 18, 2011 at 11:22 PM, Michael
        Hertling <span dir="ltr">&lt;<a moz-do-not-send="true"
            href="mailto:mhertling@online.de">mhertling@online.de</a>&gt;</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 class="h5">On 04/19/2011 02:17 AM, Oliver Buchtala
              wrote:<br>
              &gt; Am 18.04.2011 06:58, schrieb Michael Hertling:<br>
              &gt;&gt; On 04/16/2011 12:05 AM, Oliver Buchtala wrote:<br>
              &gt;&gt;&gt; Am 15.04.2011 23:48, schrieb Michael
              Hertling:<br>
              &gt;&gt;&gt;&gt; On 04/15/2011 11:22 PM, Oliver Buchtala
              wrote:<br>
              &gt;&gt;&gt;&gt;&gt; Hi,<br>
              &gt;&gt;&gt;&gt;&gt;<br>
              &gt;&gt;&gt;&gt;&gt; I observe that a custom command
              attached to a custom target as<br>
              &gt;&gt;&gt;&gt;&gt; POST-BUILD is launched on every
              build.<br>
              &gt;&gt;&gt;&gt;&gt; Is that true? or is it a
              misconfiguration on my side?<br>
              &gt;&gt;&gt;&gt;&gt;<br>
              &gt;&gt;&gt;&gt;&gt; Bye,<br>
              &gt;&gt;&gt;&gt;&gt; Oliver<br>
              &gt;&gt;&gt;&gt; A custom target is always out of date,
              i.e. it is always rebuilt when<br>
              &gt;&gt;&gt;&gt; it is visited - as a prerequisite of
              another target or due to the ALL<br>
              &gt;&gt;&gt;&gt; clause, e.g., and since the target has
              been rebuilt, each associated<br>
              &gt;&gt;&gt;&gt; POST_BUILD custom command is rerun. Thus,
              the behaviour you observed<br>
              &gt;&gt;&gt;&gt; is correct, expected and reasonable, IMO.<br>
              &gt;&gt;&gt;&gt;<br>
              &gt;&gt;&gt;&gt; Regards,<br>
              &gt;&gt;&gt;&gt;<br>
              &gt;&gt;&gt;&gt; Michael<br>
              &gt;&gt;&gt; Yep. That's reasonable.<br>
              &gt;&gt;&gt;<br>
              &gt;&gt;&gt; Do have a suggestion how to get around a
              rerun of the post-build?<br>
              &gt;&gt; Prevent the custom target from being visited,
              i.e. from being checked<br>
              &gt;&gt; if it's up to date since it will be found to be
              out of date, so the<br>
              &gt;&gt; immediately associated commands - if any - are
              run as well as the<br>
              &gt;&gt; associated POST_BUILD custom commands.<br>
              &gt;&gt;<br>
              &gt;&gt;&gt; Or how would you do a post-build after
              custom-target without being run<br>
              &gt;&gt;&gt; when custom-target actually did nothing,<br>
              &gt;&gt; What do you mean with a custom target that
              "actually did nothing"? Not<br>
              &gt;&gt; visited or no own commands? In the former case,
              the associated custom<br>
              &gt;&gt; commands are not run, of course, but in the
              latter case, it does not<br>
              &gt;&gt; matter if there are immediately associated
              commands or not since the<br>
              &gt;&gt; target will be considered as out of date and
              rebuilt-without-op, and<br>
              &gt;&gt; its POST_BUILD custom commands will be run. In
              other words: A custom<br>
              &gt;&gt; target - even without own commands - is not good
              for preventing its<br>
              &gt;&gt; custom commands from being run when the custom
              target is visited.<br>
              &gt;&gt;<br>
              &gt;&gt;&gt; i.e., custom target depends on custom command
              that did nothing?<br>
              &gt;&gt; The same holds for this kind of dependency, i.e.
              the visited custom<br>
              &gt;&gt; target will be rebuilt regardless whether the
              prerequisite custom<br>
              &gt;&gt; command did do something or not, or do you still
              talk about the<br>
              &gt;&gt; custom-command-associated-with-custom-target
              dependency?<br>
              &gt;&gt;<br>
              &gt; Alright. Then, no way to get what i want with custom
              targets.<br>
              &gt;<br>
              &gt; I am asking, as I try to improve behavior with
              UseJave.cmake::add_jar<br>
              &gt; (on stage::next) which creates a custom target.<br>
              &gt; E.g., after building the jar I want to copy the java
              archive into<br>
              &gt; 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 class="h5"><br>
              &gt; As long as java support is on a weak basis (i.e., not
              built-in), this<br>
              &gt; won't change...<br>
              &gt;<br>
              &gt; Thank you for your help!<br>
              &gt;<br>
              &gt; Bye,<br>
              &gt; Oliver<br>
              _______________________________________________<br>
              Powered by <a moz-do-not-send="true"
                href="http://www.kitware.com" target="_blank">www.kitware.com</a><br>
              <br>
              Visit other Kitware open-source projects at <a
                moz-do-not-send="true"
                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 moz-do-not-send="true"
                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 moz-do-not-send="true"
                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>
      <pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
Powered by <a class="moz-txt-link-abbreviated" href="http://www.kitware.com">www.kitware.com</a>

Visit other Kitware open-source projects at <a class="moz-txt-link-freetext" href="http://www.kitware.com/opensource/opensource.html">http://www.kitware.com/opensource/opensource.html</a>

Please keep messages on-topic and check the CMake FAQ at: <a class="moz-txt-link-freetext" href="http://www.cmake.org/Wiki/CMake_FAQ">http://www.cmake.org/Wiki/CMake_FAQ</a>

Follow this link to subscribe/unsubscribe:
<a class="moz-txt-link-freetext" href="http://www.cmake.org/mailman/listinfo/cmake">http://www.cmake.org/mailman/listinfo/cmake</a></pre>
    </blockquote>
    <br>
    Hi David,<br>
    <br>
    I will go for your suggested solution in that particular case.<br>
    <br>
    I was asking so eagerly to find out if there is some general way for
    improving UseJava::add_jar.<br>
    Using that together with POST_BUILD commands will never be like
    using POST_BUILDS on built-in targets like add_library.<br>
    <br>
    Bye,<br>
    Oliver<br>
    <br>
  </body>
</html>