Hello,Tx for the idea !That would work to "boostrap" the build but I'm not very fond of it due to it's "static" nature : it would run only once during the initial cmake run.We extract versionning information from git tags : in our current (slow) build system, a git update can trigger a "rpm"
experiment with ExternalProject.
David
Le 26 janvier 2017 16:05:47 GMT+00:00, Michael Ellery <mellery...@gmail.com> a
écrit :
>
>> On Jan 26, 2017, at 1:23 AM, David Jobet <david.jo...@free.fr> wrote:
>>
>> Hello,
>>
>> suppose I want to use protobuf and integrate i
s even
>configured. The project with all the ExternalProject calls is typically
>called a superbuild, and effectively becomes an optional convenience to
>building your own project.
>
>On Thu, Jan 26, 2017 at 3:23 AM, David Jobet <david.jo...@free.fr>
>wrote:
>
>> Hello,
Hello,
I actually gave it a try : it works fine so long versions are hardcoded
somewhere in the CMakeLists.txt and it make things really simpler.
But it does not work when version is extracted from git repository.
I came to realize I can extract this version number at build time (using
Hello,
suppose I want to use protobuf and integrate it in my project with
externalproject_add. (actually, I just have precompiled binaries and libs +
header files, I don't have the full sources)
Once the project has been 'built' (actually, installed by a custom rpm-like
tool to a shared path),
Hello,I'm working on a project where some of our libs depend on custom build of some external libraries.Those external libraries are managed through a repository manager similar to rpm (redhat package manager) which allows us to retrieve pre-compiled versions with related header files. (similar to
05:11:46 GMT+01:00, Dvir Yitzchaki
<dvir.yitzch...@ceva-dsp.com> a écrit :
>target_link_libraries(B INTERFACE A)
>
>Regards,
>Dvir
>
>From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of David Jobet
>Sent: Wednesday, April 5, 2017 18:34
>To: cmake@cmake.org
>Su
Hello,
Let's say I build some external libs A and B with B depending on A.
B and A do not use cmake, so I build them and install them in a 3rdparty
directory. I now have access to includes and libs.
I then create some cmake file to describe those libs so I can use them in my
project :
irst email : that will properly pull any transitive include or libs but
that won't make sure that link order is preserved.
Please help.
David
Le 7 avril 2017 15:27:23 GMT+01:00, David Jobet <david.jo...@free.fr> a écrit :
>INTERFACE_LINK_LIBRARIES won't work since it won't pull out include
&
orted libs ?
With regards,
David
PS : as to why I had to have 2 stages (A_imported and A), this is because I
wanted to add an alias which is not possible on an imported target
Le 7 avril 2017 12:32:52 GMT+01:00, David Jobet <david.jo...@free.fr> a écrit :
>Well not quite.
>I tried that, but
te:
>
> On 2018 M08 23, Thu 12:50:14 CEST David Jobet wrote:
> > Hello,
> >
> > I'm trying to port an existing project from premake to cmake.
> > I'm trying to avoid modifying the source files while doing so.
> >
> > Right now, we have several libraries (r
Hello,
I'm trying to port an existing project from premake to cmake.
I'm trying to avoid modifying the source files while doing so.
Right now, we have several libraries (read in different directories) using
proto files with imports between them.
All imports are made relative to the root of the
bllvm/icc/include
So if -isystem are searched last, then if there's a way to tweak
INTERFACE_INCLUDE_DIRECTORIES to use -I instead of -isystem that would
also work.
David
On Fri, Oct 12, 2018 at 9:02 AM Craig Scott wrote:
>
>
>
> On Fri, Oct 12, 2018 at 6:42 PM David Jobet wrote:
>&g
Hello,
we embed in our source a copy of an ICC build of LLVM, that we import :
add_library(global_llvm_external STATIC IMPORTED)
set_property(TARGET global_llvm_external APPEND PROPERTY
INTERFACE_INCLUDE_DIRECTORIES ${CMAKE_CURRENT_SOURCE_DIR}/icc/include)
set_property(TARGET
!
David
Le 25 septembre 2018 21:15:54 GMT+01:00, Alexander Neundorf
a écrit :
>On 2018 M09 25, Tue 16:53:27 CEST David Jobet wrote:
>> > What I do have a problem is rerunning protoc automatically on
>proto-files
>> > which import proto files that have been modified
Hello,
I had a similar issue lately and wanted to "pack" several static libs
into a dynamic one. (Not even talking about an INTERFACE lib since I
really wanted that .so)
I made it work with 3 different solutions, none of them being "clean"
from my point of view.
1- OBJECT libs on sub projects :
static lib which combines all
> the objs I want.
>
> But currently I still have problems of further combining third party static
> libraries into the final generated static single_static_lib. Can anybody
> provide a solution for this?
>
> Thank you very much.
>
> Ke
>
ll
just list the imports recursively.
I will add that as DEPENDS to the add_custom_command.
David
On Thu, Aug 23, 2018 at 9:36 PM Alexander Neundorf wrote:
>
> On 2018 M08 23, Thu 12:50:14 CEST David Jobet wrote:
> > Hello,
> >
> > I'm trying to port an existing project from prema
Hello,
in order to speed up our link step, I wanted to experiment with split dwarf.
See http://www.productive-cpp.com/improving-cpp-builds-with-split-dwarf/
Adding the compilation flag is easy, but I'm stumbling on the installation step.
In our current mode, we redirect the STRIP step to extract
FATAL_ERROR)
include_guard(GLOBAL)
project(common CXX)
add_library(common common.cc)
add_library(common::lib ALIAS common)
target_include_directories(common PUBLIC ${PROJECT_SOURCE_DIR})
install(
FILES common.py
DESTINATION site-packages
)
On Tue, Feb 5, 2019 at 10:05 AM David Jobet wrote:
>
>
Hello,
at work, we have a mono-repo with multiple applications/libs (dozens).
The build phase is ok, but I'm not sure about the release process.
When we release, we release one application at a time.
(CMAKE_SKIP_INSTALL_ALL_DEPENDENCY is true)
In order to speed up releases, we always perform an
21 matches
Mail list logo
