On 2019-07-28 19:03+0300 Dave Milter wrote:

Hi,

I heard that ninja has great feature it allows build continue without
wainting full link.

So if you have library Lib and executable App,
source code of App may build in parallel with source code of Lib,
and sync only link stage. While other build systems force build of Lib,
and only then start build of any object files of App.

But is it possible to use this feature with cmake?

Here my cmake code to emulate bottleneck of our build:

```
cmake_minimum_required(VERSION 3.12 FATAL_ERROR)
project(imported)

set(EXTERN_LIB_FILE ${CMAKE_CURRENT_SOURCE_DIR}/extern_lib/libextern.so)
set(EXTERN_LIB_INCLUDES ${CMAKE_CURRENT_SOURCE_DIR}/extern_lib/gen)
add_custom_command(OUTPUT  ${EXTERN_LIB_FILE}
                  COMMAND sh ./lib_generator.sh
                  WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}/extern_lib)
add_custom_target(extern_lib_target DEPENDS ${EXTERN_LIB_FILE})
add_library(extern_lib SHARED IMPORTED GLOBAL)
add_dependencies(extern_lib extern_lib_target)

set_target_properties(extern_lib
   PROPERTIES
   IMPORTED_LOCATION ${EXTERN_LIB_FILE}
   INTERFACE_INCLUDE_DIRECTORIES ${EXTERN_LIB_INCLUDES})
add_executable(app main.cpp)
target_link_libraries(app extern_lib)
```

we use not C/C++ library as part of our source tree,
and it builds some time,
so I expect that ninja can run "main.cpp" -> main.o compilation during
"extern_lib" build,
but this is not happens.

Is cmake has problem with add_custom_command and ninja,
or the whole idea is wrong, and cmake + ninja can not work in this way,
and I should use some other project generator instead of cmake for this?

Hi Dave:

To help answer your question, I see no fundamental issues with your code above.

The

add_dependencies(extern_lib extern_lib_target)

command in your above code means that the external project that is
created by building the extern_lib_target target must be *entirely*
completed before the extern_lib target
is built.  Furthermore, the

target_link_libraries(app extern_lib)

command means extern_lib must be built before the app is linked which, of
course, is a complete necessity.

However, I don't see anything in your CMake code that demands that the
compilation of main.cpp must be delayed until extern_lib is built.  So
can you double-check that the bottleneck is not actually the
(necessary until external_lib is built) delay of linking of app rather
than some unneccessary delay in the compilation of main.cpp?

If the latter is really true, that appears to me to be a CMake bug
(although I cannot make the final judgement call on that since I am an
experienced CMake user rather than a CMake developer).  And if so, does that
same problem (unnecessary delay in compilation rather than linking)
occur for the following simplified case?

cmake_minimum_required(VERSION 3.12 FATAL_ERROR)
project(test_internal_library)

# Delay 10 seconds so that it is obvious if main.cpp compilation is
# being unnecessarily delayed.

# You should introduce boolean CMake logic here to
# use the equivalent (see
# 
<https://stackoverflow.com/questions/1672338/how-to-sleep-for-five-seconds-in-a-batch-file-cmd>)
# "timeout 10" command for the Windows case.
add_custom_target(delay
COMMAND sleep 10
)

add_library(intern_lib SHARED ${<list of source code files for that library>)

# Add a 10 second delay until intern_lib is built
add_dependency(intern_lib delay)
add_executable(app main.cpp)
target_link_libraries(app intern_lib)

Also, please organize both test cases as tarballs containing simple
examples (including a simplified lib_generator.sh for the first case,
a 10 second delay inserted in that case as well, and simplified source
code for library (e.g., containing one function to return the "hello,
world" string and a simplified app (a main routine to print out that
string) for both cases).  Such self-contained test projects make it
much more convenient for others to confirm the issue you have
discovered on the platforms they have access to.  For example, if you
supply such self-contained test cases, I would be happy to run both
test cases here on my Linux platform for both ninja and make.  (I have
had a lot of success with parallel builds for the make case on Linux
which is why I would like to also test make just in case it turns out
you have found a ninja-only CMake bug.)

Alan
__________________________
Alan W. Irwin

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.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
__________________________
--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Reply via email to