Hello,
I have a custom build command which executes an internal resource compiler
and I am having trouble getting it to rebuild whenever one of the files
being packaged is changed. In time I will alter it to scan the input file
for dependencies and build a list automatically, but for now I am
The 3rd party libs should not be rebuilding if there are no source files
changing... We do this all the time around here, and I have not heard
anybody else complaining about this problem.
Is your project publicly available so that we may try to reproduce this
behavior here...?
On Fri, Apr 15,
So what's your problem? :)
seriously, which command do you use? You may right-click on your project and
choose rebuild only project.
On Apr 16, 2011 3:24 AM, Jesse Werner veee...@gmail.com wrote:
I have a visual studio 2010 solution that I create with cmake. I have
about
10 projects in the
I have a visual studio 2010 solution that I create with cmake. I have about
10 projects in the solution. Nine of these are open source libraries im
using. The 10th is obviously the project I am currently working on. When I
do a rebuild, it takes several minutes because it recompiles all the 3rd
Lezz Giles wrote:
I have a project set up that imports libraries, and I want to relink if
those imported libraries change;
For example, in a directory I have
hellow.c
libfred.a
CMakeLists.txt
where CMakeLists.txt contains:
Hugo Heden wrote:
Is there a reason for why CMake does not complain about the OP:s
suggestion, TARGET_LINK_LIBRARIES(hellow fred)?
In general, I would want CMake to be stricter and complain more, to
make it faster catching bugs like this . Is there a way (a command
line flag, a variable or
doesn't mention TARGET_LINK_LIBRARIES adding dependencies at all).
Lezz
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bill Hoffman
Sent: Wednesday, December 03, 2008 9:23 AM
To: cmake@cmake.org
Subject: Re: [CMake] Rebuild target when external library changes
Lezz Giles wrote:
One question, one suggestion:
If I do specify full paths, doesn't that mean that I'm forcing cmake to
use static linking? Doesn't this preclude one of the advantages of cmake
- that it's easy to switch from static to dynamic linking? (Not that I'm
complaining! I'm definitely
I have a project set up that imports libraries, and I want to relink if those
imported libraries change;
For example, in a directory I have
hellow.c
libfred.a
CMakeLists.txt
where CMakeLists.txt contains:
-
LINK_DIRECTORIES(.)
ADD_EXECUTABLE(hellow
Lezz Giles wrote:
I have a project set up that imports libraries, and I want to relink if
those imported libraries change;
For example, in a directory I have
hellow.c
libfred.a
CMakeLists.txt
where CMakeLists.txt contains:
-
Yes. me too. it's very annoying. If a cmakelists file is touched when I
build paraview (but individual projects are not actually changed), the
entire 120 odd project/targets need to be reloaded and its quicker to
just terminate the app and restart. For a while cmake did some sort of
macro
John Biddiscombe wrote:
Yes. me too. it's very annoying. If a cmakelists file is touched when I
build paraview (but individual projects are not actually changed), the
entire 120 odd project/targets need to be reloaded and its quicker to
just terminate the app and restart. For a while cmake did
Indeed, after upgrading to cmake 2.6.0 I don't have those problems anymore.
Thanks a lot!
David
Zitat von Bill Hoffman [EMAIL PROTECTED]:
John Biddiscombe wrote:
Yes. me too. it's very annoying. If a cmakelists file is touched
when I build paraview (but individual projects are not
Hi,
with Visual Studio 2008 I get a very annoying behaviour in connection
with cmake which I didn't experience with Visual Studio 2005. So it's
either the generator or VS itself.
The problem is, that whenever I Recompile a project of my
solution-file (which causes to build the Check
14 matches
Mail list logo