[cmake-developers] Need some pointers on learning the code

[Robert Dailey]

I think your idea coupled with OUTPUT and DEPENDS generator
expressions would be the perfect combination and solve this problem
beautifully.

The 2 main problems with POST_BUILD are:
1) if multiple targets depend on "z", then "z" is copied multiple times.
2) Other dependencies (other than "z") may cause "foo" to be rebuilt,
which would redundantly cause the copy operation to occur.

Another awesome setup would be a 3rd type of custom target,
automatically generated from IMPORTED targets. This would, in effect,
automatically configure a dependency on the source location of the
imported DLL, and generate the expected output location. There could
be another flag to specify that an IMPORT target should generate a
custom target. Only issue here is this can get out of hand quickly,
since I have over 100 DLLs combined and I don't want another 100
projects in my solution just for this. Would be much neater to have 1
custom target handling 100 files.

On Mon, May 13, 2013 at 2:01 PM, Brad King <brad.king at kitware.com> wrote:
> On 05/13/2013 02:48 PM, Robert Dailey wrote:
>> Interesting, I must have overlooked your comment on that issue. Will
>> this also work for add_custom_command using the OUTPUT/DEPENDS/COMMAND
>> arguments? I don't copy using a post build event, I create a custom
>> target instead and attach the custom commands to it. I do it this way
>> so that if the source DLLs change, the custom target will be smart
>> enough to copy changed DLLs.
>
> In the proposed approach the files will copy every time "foo" links,
> and "foo" will re-link whenever the "z" library for the current
> config changes.
>
> In general though it does not hook up the dependencies directly.
> You'll still need to look at adding generator expressions to
> OUTPUT and DEPENDS for that.  Note that to handle different
> names per-config you can do something like
>
>  $<$<CONFIG:Debug>:debug>$<$<NOT:$<CONFIG:Debug>>:release>
>
> -Brad