On Thu, Jan 26, 2017 at 11:41:21 -0500, Paul Smith wrote:
> IMO the right place for managing relocatable builds is in the
> compiler/linker, not in the build tool.
This is about making the files CMake writes relocatable, not the
resulting binaries.
--Ben
--
Powered by www.kitware.com
Please
Sent: 26. januar 2017 14:18
> To: Bøe, Sebastian <sebastian@nordicsemi.no>
> Cc: ben.boec...@kitware.com; cmake-developers@cmake.org
> Subject: Re: [cmake-developers] Eclipse CDT Managed build
>
> On 01/26/2017 05:57 AM, Bøe, Sebastian wrote:
> >
> > I will investigate
cmake-developers@cmake.org
Subject: Re: [cmake-developers] Eclipse CDT Managed build
On 01/26/2017 05:57 AM, Bøe, Sebastian wrote:
> I will investigate relocatable builds, because in spite of this not
> being trivial, I think CMake still comes out as the best suited technology
> for my use
On 01/26/2017 05:57 AM, Bøe, Sebastian wrote:
> I will investigate relocatable builds, because in spite of this not being
> trivial, I think CMake still comes out as the best suited technology for my
> use-case.
We once had an option to produce relative paths in the build system
and it was a
as the best suited technology for my
use-case.
-Original Message-
From: Brad King [mailto:brad.k...@kitware.com]
Sent: 25. januar 2017 17:38
To: Bøe, Sebastian <sebastian@nordicsemi.no>
Cc: ben.boec...@kitware.com; cmake-developers@cmake.org
Subject: Re: [cmake-developers] Eclipse CDT M
On 2017 M01 25, Wed 11:38:06 CET Brad King wrote:
> On 01/25/2017 11:27 AM, Ben Boeckel wrote:
> > not be trivial to get CMake to generate relocatable builds.
>
> This is also an explicit non-goal of CMake.
>
> >> after CMake generation the project can be configured through the IDE UI.
>
> That
On 01/25/2017 11:27 AM, Ben Boeckel wrote:
> not be trivial to get CMake to generate relocatable builds.
This is also an explicit non-goal of CMake.
>> after CMake generation the project can be configured through the IDE UI.
That is likely not compatible with CMake's notion of maintaining
the
On Wed, Jan 25, 2017 at 15:45:33 +, Bøe, Sebastian wrote:
> Not modifying the CMakeListst.txt is acceptable for this use-case.
>
> But not being able to share, or relocate, the build tree is a problem.
>
> Would support for relocatable build trees need major changes throughout
> CMake, or is
-
From: Ben Boeckel [mailto:ben.boec...@kitware.com]
Sent: 25. januar 2017 16:31
To: Bøe, Sebastian <sebastian@nordicsemi.no>
Cc: cmake-developers@cmake.org
Subject: Re: [cmake-developers] Eclipse CDT Managed build
On Wed, Jan 25, 2017 at 14:51:26 +, Bøe, Sebastian wrote:
> But in
On Wed, Jan 25, 2017 at 14:51:26 +, Bøe, Sebastian wrote:
> But in this use-case CMake would only be run once and then the
> IDE project would take over project configuration for the rest
> of the application lifetime.
CMake does not generally create relocatable build trees, so you cannot
of temporarily doing simple project
configuration through the IDE UI.
-Original Message-
From: Ben Boeckel [mailto:ben.boec...@kitware.com]
Sent: 25. januar 2017 15:43
To: Bøe, Sebastian <sebastian@nordicsemi.no>
Cc: cmake-developers@cmake.org
Subject: Re: [cmake-developers] E
On Wed, Jan 25, 2017 at 14:31:32 +, Bøe, Sebastian wrote:
> I was wondering if anyone has given thought to if
> it is feasible to have generator support for Eclipse CDT
> Managed builds?
It would likely be possible, but I don't know of any work towards this
goal.
> My motivation for managed
Hi,
I was wondering if anyone has given thought to if
it is feasible to have generator support for Eclipse CDT
Managed builds?
My motivation for managed build's instead of external Makefile
builds, is that after CMake generation the project can be
configured through the IDE UI. Which is a useful
13 matches
Mail list logo