On 11/12/2011 01:39 PM, David Cole wrote:
For reference, the bug Mike refers to is this one:
http://public.kitware.com/Bug/view.php?id=11258
I always use the manual technique of shutting down VS, running CMake,
and then re-opening VS. It's really not that bad, once you get used to
it.
Hi,
For a static library target, I used TARGET_LINK_LIBRARIES and LINK_DIRECTORIES
to link with a third party library. As we can see that in cmake, this linking
information is propagated and used only in an executable/shared library target
which depends on the former static library. But the
On 11/14/2011 11:46 AM, Arunmozhi wrote:
Hi,
For a static library target, I used TARGET_LINK_LIBRARIES and
LINK_DIRECTORIES to link with a third party library. As we can see that
in cmake, this linking information is propagated and used only in an
executable/shared library target which
On Mon, Nov 14, 2011 at 6:42 AM, Michael Wild them...@gmail.com wrote:
Hi Arun
Consider LINK_DIRECTORIES to be obsolete and to be avoided at all cost.
I don't really agree with this advice. There are circumstances where
link_directories() is absolutely necessary, so advocating to completely
On 11/14/2011 03:36 PM, Robert Dailey wrote:
On Mon, Nov 14, 2011 at 6:42 AM, Michael Wild them...@gmail.com
mailto:them...@gmail.com wrote:
Hi Arun
Consider LINK_DIRECTORIES to be obsolete and to be avoided at all cost.
I don't really agree with this advice. There are
On 11/13/2011 11:30 PM, Eric Noulard wrote:
2011/11/13 Robert Dailey rcdai...@gmail.com:
I understand that currently Makefiles generated by CMake are
single-configuration by-design. In other words, you can't issue a debug or
release command to make, you have to regenerate for a different
On 13 November 2011 19:51, Niels Dekker - address until 2014
niels_dekker_address_until_2...@xs4all.nl wrote:
Mateusz Loskot wrote:
On Windows, I use Visual Studio for development, so I have
CMake-generated .sln with projects. loaded into the IDE. I build.
Then, I'd like to run one of
On Mon, Nov 14, 2011 at 9:36 AM, Robert Dailey rcdai...@gmail.com wrote:
On Mon, Nov 14, 2011 at 6:42 AM, Michael Wild them...@gmail.com wrote:
Hi Arun
Consider LINK_DIRECTORIES to be obsolete and to be avoided at all cost.
I don't really agree with this advice. There are circumstances where
On Mon, Nov 14, 2011 at 11:00 AM, David Cole david.c...@kitware.com wrote:
On Mon, Nov 14, 2011 at 9:36 AM, Robert Dailey rcdai...@gmail.com wrote:
On Mon, Nov 14, 2011 at 6:42 AM, Michael Wild them...@gmail.com wrote:
Hi Arun
Consider LINK_DIRECTORIES to be obsolete and to be avoided at
On 14 November 2011 17:17, Robert Dailey rcdai...@gmail.com wrote:
So basically all third party libraries we use are not installed
individually, instead we have a server on our intranet that contains
precompiled versions of all libraries in a specific and consistent
hierarchy. For this reason,
If the -c option is given, specify the name of the
object file produced for the next source file that appears on the
command line.
So if the help says that -o is supposed to do something sensible when used
with -c but it doesn't, I'd suggest to file a bug. Note that the order of
arguments
What is the recommended way to define libraries with custom build commands?
This trick seems to be the only way:
if(NOT EXISTS ${CMAKE_CURRENT_BINARY_DIR}/dummy.cpp)
file(WRITE ${CMAKE_CURRENT_BINARY_DIR}/dummy.cpp)
endif()
add_library(foo dummy.cpp)
add_custom_command(TARGET foo POST_BUILD
On 11/14/2011 06:17 PM, Robert Dailey wrote:
On Mon, Nov 14, 2011 at 11:00 AM, David Cole david.c...@kitware.com wrote:
On Mon, Nov 14, 2011 at 9:36 AM, Robert Dailey rcdai...@gmail.com wrote:
On Mon, Nov 14, 2011 at 6:42 AM, Michael Wild them...@gmail.com wrote:
Hi Arun
Consider
On Mon, Nov 14, 2011 at 1:59 PM, Michael Hertling mhertl...@online.dewrote:
On 11/14/2011 06:17 PM, Robert Dailey wrote:
Well maybe you can tell me I'm doing this wrong then, but based on how I
am
currently setting up my third party libraries, it is required.
So basically all third
On Monday 14 November 2011, Robert Dailey wrote:
On Mon, Nov 14, 2011 at 1:59 PM, Michael Hertling
mhertl...@online.dewrote:
On 11/14/2011 06:17 PM, Robert Dailey wrote:
Well maybe you can tell me I'm doing this wrong then, but based on how
I
am
currently setting up my third
If you already know where all the libraries are, please just use the
full paths to those libraries, and do not use find_library.
On Mon, Nov 14, 2011 at 3:15 PM, Robert Dailey rcdai...@gmail.com wrote:
On Mon, Nov 14, 2011 at 1:59 PM, Michael Hertling mhertl...@online.de
wrote:
On 11/14/2011
On 2011-11-14 13:30-0500 Stefan Monnier wrote:
I'd still like to know how to explain to cmake that the command produces
2 files, but at least I can get rid of my hack.
That (assuming just a simple object file is produced by compilation)
is one of several general limitations with CMake
That's what I do sometimes. To make that easier, CMake gives some convenience
variables for library prefixes and suffixes if you are on multiple platforms.
Clint
On Monday, November 14, 2011 01:20:29 pm David Cole wrote:
If you already know where all the libraries are, please just use the
What is the difference between CMAKE_LINK_LIBRARY_SUFFIX and
CMAKE_IMPORT_LIBRARY_SUFFIX? Which should I use?
-
Robert Dailey
On Mon, Nov 14, 2011 at 2:49 PM, Clinton Stimpson clin...@elemtech.comwrote:
That's what I do sometimes. To make that easier, CMake gives some
convenience
From the Modules/Platform/* files, it looks like the only difference between
the
two is when using CYGWIN or MinGW. I'm not sure which to use.
Clint
On Monday, November 14, 2011 01:51:49 pm Robert Dailey wrote:
What is the difference between CMAKE_LINK_LIBRARY_SUFFIX and
On Sat, Nov 12, 2011 at 11:04 AM, Alexander Neundorf
a.neundorf-w...@gmx.net wrote:
Ok. So two things:
* please give current cmake master a try, it has several improvements.
* please create a ticket in the cmake bug tracker for this, improved source-
project generator for Eclipse, or something
On 11/12/2011 3:53 PM, David Cole wrote:
And, in my opinion, if there are multiple possible causes of the
problem then we should enumerate them in a message to the user,
just as you've done here in this email back to me. And we should try
to put them in the order of likelihood, so when they
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=12578
==
Reported By:Jean-Christophe Houde
Assigned To:
On Monday 14 November 2011, Brad King wrote:
On 11/12/2011 3:53 PM, David Cole wrote:
And, in my opinion, if there are multiple possible causes of the
problem then we should enumerate them in a message to the user,
just as you've done here in this email back to me. And we should try
Bill,
I think the current incarnation of regexps in CMake should be kept for
compatibility reasons.
Adding PCRE is not difficult, just time consuming. The implementation I'd
do would be an additional abstraction layer:
- For the current BRE implementation, it would be a 1:1 call match
- For the
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=12579
==
Reported By:Dan Kegel
Assigned To:
On 11/14/2011 6:08 PM, Pau Garcia i Quiles wrote:
Bill,
I think the current incarnation of regexps in CMake should be kept for
compatibility reasons.
Yes, of course.
Adding PCRE is not difficult, just time consuming. The implementation
I'd do would be an additional abstraction layer:
- For
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, next has been updated
via 324f819fecfda80a014da2bf82d82b662d0226d1 (commit)
via
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, next has been updated
via 98094a28c599c9d9faa13bb38a9989be7bcabefa (commit)
via
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, next has been updated
via c10dedab552492299476ec1b9428c36581ac62b5 (commit)
via
30 matches
Mail list logo
