Review/cleanup about drishti HOT 8 CLOSED

list(APPEND CMAKE_MODULE_PATH "${CMAKE_CURRENT_LIST_DIR}/cmake/Modules")
... 
include(CheckPlatforms)
check_platforms()

I think this may conflict when used as a subproject added by add_subdirectory. If parent project add module CheckPlatforms we will use it too. We can do include("cmake/Modules/CheckPlatforms.cmake") explicity here or add a prefix to all modules like include(DrishtiCheckPlatforms)/drishti_check_platforms. This is similar to OpenCV: https://github.com/opencv/opencv/tree/5f30a0a076e57c412509becd1fb618170cbfa179/cmake.

@headupinclouds I can rename modules, sounds good?

from drishti.

Same for the cache/option variables. E.g. BUILD_DOCUMENTATION -> DRISHTI_BUILD_DOCUMENTATION.

from drishti.

👍

from drishti.

Try Travis directory cache

I've tried this feature on Gatherer with Android toolchain (which takes a lot of time and HDD size because of SDK/NDK). It doesn't help much. Actually it makes things worse.

Timing for build without Travis cache (total 507 seconds):

Note: install-ci-dependencies.py install latest CMake/Ninja/Android NDK for build.

Timing for build with Travis cache (total 1176 seconds):

Overview:

• we have all archives downloaded now and ready for use, so install-ci-dependencies.py time dropped from 12 to 6 seconds (not worth discussion),
• Gatherer build changed unsignificantly as expected
• Hunter build (well, downloading of binaries) dropped by 65%

Overhead of using cache is unbelievably large. In fact the job for packing such archive (the job when there is no cache and we have to prepare it) takes less time then using it :) This is caused by the next facts:

• cache size is 6GB
• we are downloading 6GB archive of data
• we are unpacking 6GB archive of data
• after build is finished we are checking that unpacked stuff was not changed by current build. This is needed in case we want to upload new version of cache.

I got contradictory feelings here. From one side Hunter is pretty optimal since archives with binaries downloaded from GitHub (I guess it's the same S3 infrastructures as Travis) and unpacked - same job that Travis doing with cache but splitted into several steps. From the other side we got no more instruments for decreasing build time significantly. The next step is a use of custom CI infrastructure.

One more thing: maintanance of a Travis cache is a problem of user, e.g. when we do update SHA1 of HunterGate we need to delete cache manually otherwise we will pack two root directories: one with old SHA1 and one with new SHA1.

from drishti.

Hunter build (well, downloading of binaries) dropped by 65%

But is still 100+ seconds which is strange since it should just generate project and check stamps. I have noticed that it do print endless QT_ROOT messages. I guess this is because of Qt components dependencies: if one component of Qt depends on another we will load hunter.cmake of dependency, then check that all dependent dependencies installed and so on. I guess Qt components graph is not optimal and some edges can be removed (A depends on B and C, B depends on C => A-C dependency can be removed). Also I can think of improvement of Hunter.

from drishti.

This one seems to be somewhat legacy? Do we still need this one open?

from drishti.

RPATH, options, build-all.sh, etc. seems valid. I can take a look.

from drishti.

Closing in favor of new targeted issues.

from drishti.