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

[Michael Hertling]

On 04/20/2011 08:16 AM, Oliver Buchtala wrote:
> 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
>>
>> 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
> 
> Hi David,
> 
> I will go for your suggested solution in that particular case.

AFAICS, this solution is not bullet-proof. To make it work, you must
ensure that the, say, CopyJarFiles target is examined after the, say,
UpdateJarFiles target. Otherwise, the former possibly runs first, the
associated custom commands find the jar files up to date and will do
nothing, and subsequently, the UpdateJarFiles target renews the jar
files, so the copies aren't up to date. I.e., you need at least an

ADD_DEPENDENCIES(CopyJarFiles UpdateJarFiles)

but even with this, someone could say "make UpdateJarFiles", so the
CopyJarFiles target is not examined at all because it is a dependent
target but no prerequisite one. If I understand correctly, you would
like to have the jar files copied right after they have been renewed,
so a POST_BUILD custom command attached to the custom target defined
by add_jar() does suit perfectly, IMO.

Besides, you might combine the two approaches: Define a command-less
custom target, i.e. CopyJarFiles, with an associated custom command in
the way David suggested but without the ALL clause, and attach a custom
command to add_jar()'s custom target with a COMMAND like the following:

${CMAKE_COMMAND} --build ${CMAKE_BINARY_DIR} --target CopyJarFiles

In this manner, the CopyJarFiles target will always be visited after
the add_jar()'s custom target, i.e. the jar files are copied unless
they are up to date due to CopyJarFiles' associated custom commands
and their dependencies. So, you'll have a robust *and* inexpensive
solution.

Regards,

Michael

> 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