Hey all, just thought I would chime in and note that I very often write
code that I expect to run both on my robots hardware and on my development
machine in a simulator. In this case, I want the same target names and
everything -- I simply use two cmake build directories, and now there is
even
t a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index 5afaf7b..ad26f61 100644
--- a/Source/CMakeVersion.cmake
+++ b/Source/CMakeVersion.cmake
@@ -1,5 +1,5 @@
# CMake version number components.
set(CMake_VERSION_MAJOR 3)
set(CMake_VERSION_MINOR 13)
-set(CMake_VERSION_PATCH 20181218)
+set(CMake_VER
On Tue, Dec 18, 2018 at 4:41 PM Kyle Edwards
wrote:
> On Tue, 2018-12-18 at 16:12 -0500, frodak17 wrote:
>
> What about conflicting build types when building a host tool target vs the
> cross compiler target?
> For instance the host tool may (should?) be built as a release project
> (default
On Tue, 2018-12-18 at 16:12 -0500, frodak17 wrote:
> So it would be something like project( [TOOLCHAIN
> [LANGUAGES] [...]) where TOOLCHAIN
> and its supported languages can be repeated for each tool chain. i.e
> project(whatever TOOLCHAIN default LANGUAGES cpp TOOLCHAIN cross
> LANGUAGES c)
I
Dear Craig, Alan,
thanks so much for this hint! I did not write the initial XConfig.cmake
myself and so it slipped my attention. Now things are perfectly clear,
I'll extend the XConfig.cmake.in and add the configuration steps there.
All the best,
Mario
On 18.12.18 21:54, Craig Scott
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".
The branch, master has been updated
via f7947d90db0b5a452be1714ae8770c2ffa6352d3 (commit)
via
> How does this work with multiple languages and the project() command and
>> enable_language() commands?
>>
> Both project() and enable_language() could be extended with an optional
> TOOLCHAIN argument.
>
So it would be something like project( [TOOLCHAIN
[LANGUAGES] [...]) where TOOLCHAIN and
On Wed, Dec 19, 2018 at 5:36 AM Alan W. Irwin
wrote:
> On 2018-12-17 21:35+0100 Mario Emmenlauer wrote:
>
> >
> > Dear cmake team and user community,
> >
> > I'd kindly like to ask for advice on how to handle transitive
> > dependencies cleanly with "modern" cmake. I'm often plagued by this
> >
I did eventually find a solution where I set up an imported target with
IMPORTED_LOCATION and IMPORTED_LOCATION_DEBUG properties pointing to the object
files, and then linked in that target with target_link_libraries(). I admit I
wasn't completely sure if adding .obj/.o files to the link lines
On Tue, 2018-12-18 at 14:10 -0500, frodak17 wrote:
> How does this work with multiple languages and the project() command
> and enable_language() commands?
Both project() and enable_language() could be extended with an optional
TOOLCHAIN argument.
> For instance you want to use the host c++
How does this work with multiple languages and the project() command and
enable_language() commands?
For instance you want to use the host c++ compiler and a toolchain
specified compiler for c and c++.
When project() enables the c++ compiler it runs through a bunch of scripts
to find and test the
As far as I know this is a limitation of the MSVC project files, and
CMake errors out on that generator rather than try and build an
invalid project.
Have you tried do something where you have the Config and Release
objects as separate targets that always exist, but selectively
conditionally to
On 2018-12-17 21:35+0100 Mario Emmenlauer wrote:
Dear cmake team and user community,
I'd kindly like to ask for advice on how to handle transitive
dependencies cleanly with "modern" cmake. I'm often plagued by this
problem: I have a library X that optionally depends on library A.
When I build
On Tue, 2018-12-18 at 06:14 -0500, frodak17 wrote:
> What first cross my mind with '"utilities" needed for build' is when
> you have to build the cross-compiler in the first place before you
> build anything for the target.
> If so how do you handle verification of the tool-chain can build a
>
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".
The branch, master has been updated
via 89d0f720cbef3f675cc705d961830dc12e96f712 (commit)
via
On 17/12/2018 15:37, David Blaikie wrote:
On Sun, Dec 16, 2018, 4:24 PM Kris Thielemans
mailto:kris.f.thielem...@gmail.com> wrote:
I’ve just had a problem caused by an upgrade of my system files (in
this particular case: boost). Rebuilding our software didn’t
correctly rebuild
What first cross my mind with '"utilities" needed for build' is when you
have to build the cross-compiler in the first place before you build
anything for the target.
If so how do you handle verification of the tool-chain can build a working
executable or library?
Normally that is done at the time
Thanks David
It seems that a rebuild is the only way. We’ll add that to our instructions
then!
Kris
From: David Blaikie
Sent: 17 December 2018 15:37
To: Kris Thielemans
Cc: CMake Mail List
Subject: Re: [CMake] dependencies on system include files
If you're willing to run a
18 matches
Mail list logo
