[CMake] Fwd: ExternalProject, continuous integration and caching builds

Hi all, I faced exactly the same issue with Box Backup, and "solved" it by caching completely built packages in tarballs, replacing the ExternalProject with a different one that uses the cached package if it hasn't been invalidated (which we determine based on the CMakeLists.txt having changed).

Re: [CMake] ExternalProject, continuous integration and caching builds

> > CMake notices the downloaded tarball is up-to-date and > doesn't download it again, but it still extracts it again >From what I can tell, the 'check|download tarball' and 'extract tarball' commands are independent parts of the "download step": as long as the download step runs at all, it will

[CMake] Joining an OBJECT and a SHARED library

Hi, is there a way to "join" an the OBJECT library with a SHARED library it creates? The abclib and its component abc_tmp, all .c file have #include "foo.h": add_library(abc_tmp OBJECT z1. z2.c) # generate... add_library(abclib SHARED $ generated.c) Then adding the library foo, whi

Re: [CMake] Specify extra files for display in IDE

Hi, I tried to add interface sources to interface libraries with both, the CMake 3.11.18040201-MSVC_2 integration of Visual Studio (with Ninja), which I’m using most of the time, and the “Visual Studio 15 2017 Win64” generator of CMake 3.12.1: - The Visual Studio integration shows the t

Re: [CMake] ExternalProject, continuous integration and caching builds

Hello! You may try to perform some kind of "caching" actions yourself: store a checksum for the downloaded dependency archive and only build it if its checksum changes or the dependency with this checksum hasn't been already built. You may only store the checksum for the archive download link if i

Re: [CMake] ExternalProject, continuous integration and caching builds

Hello! You may try to perform some "caching" actions yourself: store some kind of a checksum for the archive with the downloaded sources and only build ExternalProject if the checksum changes or if there is no previously built ExternalProject with the same checksum. It is also possible to only sto

Re: [CMake] ExternalProject, continuous integration and caching builds

Le 05/09/2018 à 14:37, Antoine Pitrou a écrit : > >> When AppVeyor restores the cached directories and files, does it also >> preserve their timestamps? If not, that might explain why it always >> rebuilds. > > I do not know. I've found out this utility: > https://github.com/iboB/mtime_cache an

Re: [CMake] ExternalProject, continuous integration and caching builds

Le 05/09/2018 à 14:28, Craig Scott a écrit : > > > On Wed, Sep 5, 2018 at 9:56 PM, Antoine Pitrou > wrote: > > > Hello, > > On our project (Apache Arrow - https://arrow.apache.org/) we're using > CMake for the C++ source tree and have many external depe

Re: [CMake] ExternalProject, continuous integration and caching builds

On Wed, Sep 5, 2018 at 9:56 PM, Antoine Pitrou wrote: > > Hello, > > On our project (Apache Arrow - https://arrow.apache.org/) we're using > CMake for the C++ source tree and have many external dependencies > fetched using ExternalProject. In turn building those dependencies can > make up a sign

[CMake] ExternalProject, continuous integration and caching builds

Hello, On our project (Apache Arrow - https://arrow.apache.org/) we're using CMake for the C++ source tree and have many external dependencies fetched using ExternalProject. In turn building those dependencies can make up a significant portion of build times on CI services, especially AppVeyor.

Re: [CMake] Specify extra files for display in IDE

Le mer. 5 sept. 2018 à 11:00, Daniel Eiband a écrit : > Hi, > > > > I managed to solve the presentation of object libraries by renaming the > targets and hiding certain targets in folders. I think this solution is > acceptable. > > > > The issue with the display of header only libraries in IDEs,

Re: [CMake] Specify extra files for display in IDE

Hi, I managed to solve the presentation of object libraries by renaming the targets and hiding certain targets in folders. I think this solution is acceptable. The issue with the display of header only libraries in IDEs, which are implemented as interface libraries, is still unsolved. The add_l

Re: [CMake] cmake prebuilt binaries won't work if bin folder is renamed.

You will need to rename the directory containing bin; the share folder scripts is often very dependant on the bin (or vice versa) ... better to just keep like 'cmake' and then 'cmake-3.xx' directories containing the whole cmake package... On Tue, Sep 4, 2018 at 11:47 PM Vinitha wrote: > Hi, > I