Re: [CMake] Multiple source directory scenario and cdt generator

On Sat, Nov 12, 2011 at 11:04 AM, Alexander Neundorf 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 like this. > > My g

Re: [CMake] Problem with LINK_DIRECTORIES

>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 > CMAKE_IMPORT_LI

Re: [CMake] Problem with LINK_DIRECTORIES

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 wrote: > > That's what I do sometimes. To make that easier, CMake gives some > convenience > variables for lib

Re: [CMake] Problem with LINK_DIRECTORIES

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 >

[CMake] Circular dependencies because of file names?

I have the following code: # -- DOXYGEN find_package(Doxygen) set(docsDir "${CMAKE_BINARY_DIR}/docs/") add_custom_command(OUTPUT ${docsDir} COMMAND ${CMAKE_COMMAND} "-E" "make_directory" ${docsDir} VERBATIM) add_custom_target("docs" COMMAND "${DOXYGEN_EXECUTABLE}" "${CMAKE_SOU

Re: [CMake] Adding a new language

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 language

Re: [CMake] Problem with LINK_DIRECTORIES

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 wrote: > On Mon, Nov 14, 2011 at 1:59 PM, Michael Hertling > wrote: >> >> On 11/14/2011 06:17 PM, Robert Dailey wrote:

Re: [CMake] Problem with LINK_DIRECTORIES

On Monday 14 November 2011, Robert Dailey wrote: > On Mon, Nov 14, 2011 at 1:59 PM, Michael Hertling wrote: > > 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 par

Re: [CMake] Problem with LINK_DIRECTORIES

On Mon, Nov 14, 2011 at 1:59 PM, Michael Hertling wrote: > 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 party librarie

Re: [CMake] Problem with LINK_DIRECTORIES

On 11/14/2011 06:17 PM, Robert Dailey wrote: > On Mon, Nov 14, 2011 at 11:00 AM, David Cole wrote: > >> On Mon, Nov 14, 2011 at 9:36 AM, Robert Dailey wrote: >>> On Mon, Nov 14, 2011 at 6:42 AM, Michael Wild wrote: Hi Arun Consider LINK_DIRECTORIES to be obsolete and to be avoide

[CMake] Libraries with custom build command

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

Re: [CMake] Adding a new language

> "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 > ar

Re: [CMake] Problem with LINK_DIRECTORIES

On 14 November 2011 17:17, Robert Dailey 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, it doesn't mak

Re: [CMake] Problem with LINK_DIRECTORIES

On Mon, Nov 14, 2011 at 11:00 AM, David Cole wrote: > On Mon, Nov 14, 2011 at 9:36 AM, Robert Dailey wrote: > > On Mon, Nov 14, 2011 at 6:42 AM, Michael Wild wrote: > >> > >> Hi Arun > >> Consider LINK_DIRECTORIES to be obsolete and to be avoided at all cost. > > > > I don't really agree with t

Re: [CMake] Problem with LINK_DIRECTORIES

On Mon, Nov 14, 2011 at 9:36 AM, Robert Dailey wrote: > On Mon, Nov 14, 2011 at 6:42 AM, Michael Wild 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 ab

Re: [CMake] CMAKE_RUNTIME_OUTPUT_DIRECTORY best practice for Windows and Visual Studio

On 13 November 2011 19:51, Niels Dekker - address until 2014 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 executables (e.g. test.exe) which links aga

Re: [CMake] CMake single-configuration makefiles

On 11/13/2011 11:30 PM, Eric Noulard wrote: > 2011/11/13 Robert Dailey : >> 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 >> configurat

Re: [CMake] Problem with LINK_DIRECTORIES

On 11/14/2011 03:36 PM, Robert Dailey wrote: > On Mon, Nov 14, 2011 at 6:42 AM, Michael Wild > 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 w

Re: [CMake] Problem with LINK_DIRECTORIES

On Mon, Nov 14, 2011 at 6:42 AM, Michael Wild 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 avoid it isn't

Re: [CMake] Problem with LINK_DIRECTORIES

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

[CMake] Problem with LINK_DIRECTORIES

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 iss

Re: [CMake] Workflow of a collaborative project in Visual Studio+CMake

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 >