[CMake] call already made makefile

[Alan W. Irwin]

On 2010-11-05 22:50-0700 SK wrote:

> On Fri, Nov 5, 2010 at 1:04 PM, Alan W. Irwin <irwin at beluga.phys.uvic.ca> wrote:
>> I agree the above idea should work, but dropping add_custom_command
>> completely and moving the COMMAND to add_custom_target instead (and
>> dropping all file DEPENDS for the custom target) is even a simpler way
>> to insure COMMAND gets executed every time the custom target is
>> built.
>
> Yes it always runs, but there is no "output" from add_custom_target.

True.

> When the external makefile produces an output needed by some larger
> dependency chain, then add_custom_command is the only way.

You may be right for the general case.  However, note that since
OUTPUT is involved the dependency chain you are talking about must be a
file dependency chain that occurs as a result of a series of
add_custom_command or add_custom_target commands.  Note an important
limitation of such chains is those commands must appear in the same
CMakeLists.txt file.

Note also that according to my experiments your general conclusion
turns out not to be correct for the specific case of external
libraries.

To be specific, here are the two different scenarios we are discussing
for that case.

I.

add_custom_command(
   OUTPUT full_path_to_generated_library dummy
   COMMAND make
   WORKING_DIRECTORY full_path to where Makefile is located
   )

add_custom_target(
   extern_lib
   DEPENDS full_path_to_generated_library
   )

add_executable(myexecutable myexcutable.c)

target_link_libraries(myexecutable full_path_to_generated_library)

add_dependencies(myexecutable extern_lib)

II,

add_custom_target(
   extern_lib
   COMMAND make
   WORKING_DIRECTORY full_path to where Makefile is located
   )

add_executable(myexecutable myexcutable.c)

target_link_libraries(myexecutable full_path_to_generated_library)

add_dependencies(myexecutable extern_lib)

where the only difference between I and II is the
add_custom_command/add_custom_target pair of I is replaced with a
single add_custom_target with COMMAND specified in II.

My experiment consisted of touching the actual external library file
that is referred to for an existing project that used the
target_link_libraries command. That external library was built
completely separately (unlike the above two scenarios).  But the
result of touching that library was that my internal target (a library
in this case) got relinked.  So in that case, there seemed to be no
necessity at all that full_path_to_generated_library actually needed
to appear in an OUTPUT in order for the internal target to be
relinked. That is why I predict scenario II above should work with no
problems.

To explain my reasoning further, With II, every time one of the source
files of the externally generated library gets changed, then "make
myexecutable" should rebuild that library through the _target_
dependency between the myexecutable target and the extern_lib target.
Because that external library rebuild necessarily changes the file
full_path_to_generated_library, then myexecutable should be relinked
because (according to my experiements) target_link_libraries always
relinks whenever there is a change in the library file that is
referred to _regardless of the source of the change to that file_.

Of course, although the above logic seems compelling, it needs to be
verified by examples.  I am not in a good position to do that, but I
assume from your posts about the specific external library case you do
have an example of scenario I that does work properly for external
libraries or can soon put one together.  If you make the trivial
change to scenario II, does that example continue to work properly as
predicted by the above logic?

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________