Because that doesn't retain the dependencies that do the linking the first time
around. It's also messy and non-portable.
Sent from my iPhone
On Oct 25, 2012, at 21:52, Doug wrote:
> I can't see why you couldn't use set(CMAKE_SKIP_RPATH ON) and post
> build copy your library to a path that's
I can't see why you couldn't use set(CMAKE_SKIP_RPATH ON) and post
build copy your library to a path that's on your linker path; have
your tests setup to use the system copy of the library instead of the
local copy.
~
Doug.
On Sat, Aug 4, 2012 at 2:41 AM, Leif Walsh wrote:
> This is sort of the
Is there anything that would convince kitware that the behavior I describe is
worth pursuing, even as a non-default option? I'd implement it myself but your
code is foreign to me and I bet someone at kitware knows the exact line that
needs to change to enable this.
The reason I'm pushing so ha
On 10/25/2012 1:17 PM, Leif Walsh wrote:
Yes, but this is a very rare thing to do. And the "failure" result is
just that the problem would be discovered at test time instead of link
time.
What's being proposed here is a massive optimization for the common case
(changing code in a library and no
Matthew Woehlke writes:
> I'm not sure that's correct behavior. What if the modification to the
> .cpp file was to remove the definition of a function declared in a
> header? Now your executable that was using that function will crash when
> you try to run it due to a missing symbol. If you h
On 2012-10-24 10:35, DavidAllen wrote:
I am currently looking at replacing my unix makefile (linux+gmake,
solaris+make/gmake) and Windows VS projects, with cmake.
For the makefiles I get gcc to output dependency files based on header file
usage, using gcc options -MM -MF -MP -MT.
This has worke
David,
I have had some build time success by adopting the ninja generator. It's got
some dependency issues but it's workable, and though it doesn't solve the
relinking issue, it does make builds generally a lot faster.
Sent from my iPhone
On Oct 24, 2012, at 10:35, DavidAllen wrote:
> I agr
I agree with Leif Walsh
I am currently looking at replacing my unix makefile (linux+gmake,
solaris+make/gmake) and Windows VS projects, with cmake.
For the makefiles I get gcc to output dependency files based on header file
usage, using gcc options -MM -MF -MP -MT.
This has worked really wel
On 3 Aug, 2012, at 4:44 PM, Andreas Pakulat wrote:
>
> Actually no, adding new public API, changing existing API in
> compatible ways are things you can do with a shared library which
> needs relinking.
Not without changing the header files, which forces recompilation. As the
author of a share
Hi,
On Fri, Aug 3, 2012 at 8:41 PM, Leif Walsh wrote:
> This is sort of the point of shared libs though, you can update them without
> relinking everything on your system, unless you're doing something really
> brain-damaged.
Actually no, adding new public API, changing existing API in
compati
This is sort of the point of shared libs though, you can update them without
relinking everything on your system, unless you're doing something really
brain-damaged.
Is there any way I, as someone who knows my libraries are sane, can prevent
this extra work and just resort to a "make clean" if
On Friday 20 July 2012, Andreas Naumann wrote:
> If you are using the Makefile system, then the libraries are newer than
> your tests, so your tests seems to need an update.
>
> And sometimes programs need relinking, where should the build system
> now, if you really need the relinking?
Yes, e.g.
If you are using the Makefile system, then the libraries are newer than
your tests, so your tests seems to need an update.
And sometimes programs need relinking, where should the build system
now, if you really need the relinking?
Am 20.07.2012 14:08, schrieb Leif Walsh:
Why, if I make a sm
Why, if I make a small change to my shared library, does cmake relink all of my
tests to it? It's a shared library, isn't the point that it doesn't need
relinking? Seems like a big waste of time. Can I suppress this in any way?
Sent from my iPhone
--
Powered by www.kitware.com
Visit other Kit
14 matches
Mail list logo
