[CMake] call already made makefile

[Michael Hertling]

On 11/05/2010 02:09 AM, Alan W. Irwin wrote:
> On 2010-11-04 16:29-0700 SK wrote:
> 
>> On Sat, Oct 30, 2010 at 8:31 AM, Alan W. Irwin
>> <irwin at beluga.phys.uvic.ca> wrote:
>>> On 2010-10-29 20:50-0700 mina adel wrote:
>>>
>>>>
>>>> Hi All
>>>>
>>>> I have an open source code that I use in my project. This open source code
>>>> already has Makefile coded for it.
>>>>
>>>> I want to use cmake so that before it compile my project it first call the
>>>> cmake of these open source code, which will compile it to .la library.
>>>
>>> ..make?
>>>>
>>>> Then using this library, it compile my code.
>>>
>>> I assume from the context you mean make rather than cmake above.
>>>
>>> To run make (or any command) at run-time, use the combination of
>>> add_custom_command and add_custom_target.  Basically,
>>> add_custom_command creates an OUTPUT file (say your library) at run
>>> time, and add_custom_target file-depends on that file and creates a
>>> CMake target corresponding to the custom command which you can add as
>>> a dependency of your application target.  This insures make will be run (if
>>> the library is not up to date) before your application is built.
>>>
>>
>> No, this does not work when the external command is a make process.
>> The problem is that the "output" of add_custom_command() is a target
>> with it's own dependencies.
> 
> I don't understand your remark since the OUTPUT of add_custom_command
> must refer to a file not a target, and there is a big distinction
> between those two concepts in CMake.  That's why I emphasize when
> a file is indicated and when a target is indicated below.
> 
>> The external make process must always run
>> in order catch dependencies that only the external make knows about.
>> The only way to make sure the make process always runs is to use
>> add_custom_target(), but alas, add_custom_target does allow us to
>> specify an output.
>>
>> See this thread from a few days ago: add_custom_command depends on
>> output from add_custom_target.
>>
>> As far as I know, there is no satisfactory way to do use external
>> makefiles with CMake.  I'm all ears if anyone has suggestions.
>>
> 
> In the past I have been able to use an external set of Makefiles with
> no problems. However, I eventually took my own advice and replaced
> that method with one that used cmake.  So I don't have any current
> good examples, and my remarks below are from memory. However, I think
> it should be completely straightforward to do what you like if you
> read the cmake documentation for add_custom_command and
> add_custom_target carefully.
> 
> Here is schematically what you have to do:
> 
> add_custom_command(
>    OUTPUT full_path_to_generated_library
>    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)
> 
> In sum, target_link_libraries tells how to link the executable file
> associated with the myexecutable target to the library _file_
> full_path_to_generated_library, add_dependencies makes sure the
> _custom target_ extern_lib is built before the _target_ myexecutable is
> built, and the _file_ DEPENDS of add_custom_target makes sure the
> custom make command is run every time there is an attempt to build the
> myexecutable (and therefore extern_lib) target.
> 
> Please check my memory of the correct way to do this by using the
> touch command.  For example, if you touch one of the source files for
> the external library, then I believe with the above scenario if you
> subsequently run "make myexecutable", then the custom make command
> should always be run (since it has no DEPENDS option), and therefore
> the external library will automatically be rebuilt (assuming those
> external Makefiles had done their dependencies properly), and
> myexecutable relinked.

AFAIK, this can be simplified by dropping the custom command:

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)

As the custom target is always out of date, make is invoked each time,
and due to ADD_DEPENDENCIES(), it is invoked before the executable is
examined for being out of date. If that results in a renewed external
library the executable gets relinked. Additionally, the question if a
custom command without DEPENDS clause does always run is avoided.

Regards,

Michael

> Of course, use "make VERBOSE=1" to follow exactly what commands are
> being run when testing file dependencies and associated target
> dependencies with the touch command.  Also, I believe it ultimately
> would be a good idea to replace all builds of external libraries with
> CMake-based builds since that gives you the most control of your
> library organization.
> 
> 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
> __________________________