On 3/21/2011 9:42 AM, Valeriy Bykov wrote:
I'm trying to link with static library which I've found using FIND_LIBRARY:
MESSAGE (${LPTHREAD}) prints /home/vbykov/svn/builddeps/glibc/lib/libpthread.a
Further I do the next:
ADD_EXECUTABLE (test_atomic_lock test_atomic_lock.c)
On 3/21/2011 10:12 AM, Valeriy Bykov wrote:
I'm using CMake version 2.8.4. Furthermore I use custom ToolChain but I
don't think it is important.
... /home/vbykov/svn/builddeps/glibc/lib/libpthread.a
It may be important actually. Is this path to libpthread.a in the
implicit library search
On 03/22/2011 05:27 AM, Valeriy Bykov wrote:
I want to build all the project statically using certain version of glibc,
gcc and all other libs I need. They are situated in the folder builddeps
which I can simply checkout on any host and pass it's path to CMake.
The easiest way to ensure a
On 03/10/2011 09:46 AM, Brad King wrote:
This is clearly a bug. Both ccmake and cmake-gui should clear the list of
manually-specified variables of entries used on *any* configure step.
This is now fixed upstream:
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a4335a62
-Brad
On 03/29/2011 05:19 AM, Rolf Eike Beer wrote:
The basic idea is: any symbols from those private libraries are, well,
private. The user only ever sees the symbols from the public library. In
fact he _can't_ even link to the private libraries on Windows as we never
install the .lib files. And
On 03/29/2011 02:28 AM, J Decker wrote:
This ends up building a command line that looks like
(On c:)
cd L:\games\spring\cont\base make_gamedata_arch.bat ...
since the current drive is the C drive, this doesn't change the drive,
it only changes the drive on L:, so you'd have to
On 03/29/2011 11:53 AM, Tim Gallagher wrote:
Hi,
We ran into an issue using CMake with our fortran project. We have
constructions such as:
...
#ifdef OPTION1
USE Module1
#else
USE Module2
#endif
...
It's not actually finding modules as dependencies. Any thoughts?
Are those
:
Am Dienstag, 29. März 2011, 09:41:36 schrieb Brad King:
CMake running in an outside application needs to know these private runtime
dependencies. It needs them ensure that the application link line is
generated such that the linker can find the transitive dependencies (e.g.
-rpath-link
On 03/29/2011 06:05 PM, Tim Gallagher wrote:
I checked the variable and the correct module file is there but it's not
being built in the correct order.
This feature is expected to work. Can you reproduce the issue in a
sample test project and send me a tarball off-list, please?
Thanks,
-Brad
On 04/05/2011 12:22 PM, Clinton Stimpson wrote:
I'm looking at bug #11884
http://public.kitware.com/Bug/view.php?id=11884
And I've noticed there is a problem with depending on generated headers
across
directories but not within the same directory.
For example:
# section A
On 03/29/2011 09:54 AM, Brad King wrote:
The fix in this case is in Source/cmLocalUnixMakefileGenerator3.cxx
in the CreateCDCommand method. Try changing the two appearances of
cmd = cd
in the Windows case to
cmd = cd /d
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b5676134
On 04/13/2011 02:44 PM, Jean-Christophe Fillion-Robin wrote:
Is there a solution to find a library having a revision number ?
You can specify the actual library file name libgfortran.so.3.
However, you shouldn't need to find implicit compiler runtime libraries.
Are you trying to mix C++ and
On 04/13/2011 03:37 PM, Jean-Christophe Fillion-Robin wrote:
1) I have a project XYZ that linked against VTK static which also linked
GnuR shared
[snip]
/usr/bin/ld: /home/jchris/Projects/R-2.11.1/lib64/R/lib/libRlapack.so:
error: undefined reference to '_gfortran_concat_string'
Doesn't
On 04/26/2011 03:41 AM, Michael Wild wrote:
Seems like MSVC (I'm using 9.0) is messing with the standard streams...
I put up a simple test project that only calls dumpbin.exe /? in a
execute_process call. Funny thing is, that if configured from CMake-Gui
or command line, the output is captured
On 04/29/2011 05:46 AM, J.S. van Bethlehem wrote:
Am I trying do something that is not possible (I think not, given that
the manual explicitly states that OUTPUT_* and ERROR_* may be the same
and that results will be merged)
It is not possible to do with *_FILE right now simply because
On 05/11/2011 05:22 PM, Daniel Blezek wrote:
the detach code does not seem to be tested
It is built as a test in KWSys under CMake but is not run automatically.
I don't remember why, but I can run the test by hand and it passes:
$ ./kwsysTestProcess 8
Output on stdout before test 8.
Output
On 05/16/2011 04:41 AM, Dick Munroe wrote:
The reason for all this was that I need Intel Fortran Composer XE 11.x
support for VS 8 2005. Here's the patch that gets it for me:
[snip]
+ // Version 12 actually uses 11.0 in project files!.
+ if (intelVersion == 12.0)
+ {
+
On 5/23/2011 2:15 PM, sind...@gmail.com wrote:
I have the below directory structure for Fortran code which has very
basic dependencies, I am not able to get CMake to recognize the
dependencies automatically without me explicitly having to specify it
using add_dependencies or
On 05/25/2011 08:18 AM, sind...@gmail.com wrote:
I also like your suggestion of having all source files in one directory
They don't actually have to be in one directory. You only need to name
them from one directory. For example:
add_executable(myMain
exe/mymain.f90
lib1/lib1.f90
On 05/28/2011 12:33 PM, Thomas Roß wrote:
set( CMAKE_RUNTIME_OUTPUT_DIRECTORY ${PROJECT_BINARY_DIR}/bin CACHE PATH )
to have all my executables in one place
This doesn't need to be in the cache. You can just set() it in the top level.
used set_target_properties( plugin PROPERTIES
On 06/05/2011 05:02 AM, Quintus wrote:
I'm working on a git-versioned project that I'd like to display it's
version number for development versions like this:
1.2.3-dev (commit abc1234 on devel, 12/4/10)
FYI, consider using git describe for versions.
CMake's FindGit module seems to be quite
On 06/11/2011 02:08 AM, Campbell Barton wrote:
To follow up on this, I tested this on a test project and found the
problem was in my own macro which wasn't initializing an include list.
So only the set(CMAKE_INCLUDE_SYSTEM_FLAG_C -isystem ) remains
which should be fixed in CMake but is easy
On 06/17/2011 04:59 PM, Eric Noulard wrote:
OK I have the same behavior on my box using your example.
I did open a bug report:
http://public.kitware.com/Bug/view.php?id=12284
I posted an explanation here:
http://www.cmake.org/Bug/view.php?id=12284#c26931
CPack recursively collects all
On 06/27/2011 02:39 PM, Raphael Münster wrote:
enable_language (Fortran)
set(CMAKE_Fortran_COMPILER mpif90)
Set the compiler variable *before* enabling the language. The enable_language
command does a whole bunch of introspection of the compiler.
-Brad
On 06/27/2011 02:39 PM, Raphael Münster wrote:
# name of the project
PROJECT(Q2P1)
enable_language (Fortran)
Languages can also be specified in the project command:
project(Q2P1 C CXX Fortran)
I invoke cmake like this CC=mpicc CXX=mpic++ cmake
-DCMAKE_Fortran_COMPILER=mpif90
FYI, you
On 07/25/2011 07:56 AM, Dave Abrahams wrote:
on Mon Jul 25 2011, Daniel Pfeifer purplekarrot-AT-gmail.com wrote:
Hey,
is there an update on this topic?
Well, I asked
Does cmake use response files when generating command-lines for windows
compilers that support them?
to which
On 07/13/2011 12:10 PM, Alexander Neundorf wrote:
When I talked last time with Brad such a feature was still on his TODO, and
is
there since at least 2007 already, but still more or less at the bottom of
the
list.
It's more of a wish I had time to do this ;)
add_library(foo ${fooSrcs})
On 07/25/2011 12:00 PM, Daniel Pfeifer wrote:
what is your opinion on the $ syntax I originally proposed?
This would not require creating virtual targets for header only libraries.
The implementation is just doing delayed variable evaluation and
is not a true generator expression in the same
On 07/25/2011 03:11 PM, Dave Abrahams wrote:
Yes, CMake does support response file generation in a few cases.
It uses them to pass long object file lists to linkers. Since
CMake 2.8.5 it also uses them for include directory lists with
GNU tools on Windows.
That makes it sound like it's not
On 07/25/2011 02:17 PM, Daniel Pfeifer wrote:
Does it also handle circular dependencies?
Since we were doing the module breakdown ourselves we could define
modules to avoid circular dependencies. We separated implementation
dependencies from test dependencies so that library and test modules
On 07/25/2011 11:01 PM, Dave Abrahams wrote:
on Mon Jul 25 2011, Brad King brad.king-AT-kitware.com wrote:
That makes it sound like it's not going to help us with long include
directory lists with non-GNU tools. Is that right?
When generating VS IDE project files...
I'm not asking about
On 8/3/2011 11:41 AM, Alexander Neundorf wrote:
On Tuesday 02 August 2011, Hendrik Sattler wrote:
If you use cmake 2.8.5, you can use GNUInstalldirs.cmake and let the user
specify the multiarch directory to install in (or solve it once in that
cmake module).
You mean having the user adjust
On 7/21/2011 1:07 PM, Marco Corvo wrote:
Hi all,
I'm trying to use a new feature of releases 2.8.4/5, that is the possibility
to define dependencies for IMPORTED targets and when I run cmake I get a
SIGSEV signal. Trying to get some more info with Valgrind I found that:
I can reproduce this
On 8/4/2011 3:29 PM, Brad King wrote:
This was a dumb mistake on my part. I will fix it. Meanwhile you can
avoid the crash by not making an imported target depend on a target
that does not exist.
Fixed to ignore dangling dependencies instead of crashing:
http://cmake.org/gitweb?p=cmake.git
On 9/25/2011 8:54 PM, Albert Chin wrote:
It is listed as static because cmake always uses a
path/to/libmodman.sl when invoking the linker.
CMake prior to 2.6 always used the -L and -l split. That led to endless
problems with search path ordering, static v. shared searches, etc. that
made it
On 9/30/2011 1:15 PM, John R. Cary wrote:
When I build the definitions from the dependency are missing
from the .mod file:
[snip]
So something later in the cmake build seems to be removing
these definitions.
Perhaps another target compiles the/a source file producing the same
.mod file but
On 10/25/2011 5:00 AM, Eric Noulard wrote:
2011/10/25 Phil Smithp...@voltage.com:
# Specify the cross-compilers
SET(CMAKE_C_COMPILER regina.exe cc.rex dcc.exe)
SET(CMAKE_CXX_COMPILER regina.exe cc.rex dcxx.exe)
I think CMAKE_[C|CXX]_COMPILER vars are supposed to contain
a command not
On 10/21/2011 7:32 PM, Adam Somers wrote:
Sorry if this is not the correct list to post questions.
Please direct me to the proper place if so.
This is the correct place.
The resulting linker flag is:
-Framework My Framework
This of course is incorrect and will cause gcc to try to link
On 12/15/2011 2:56 PM, Vladimir Panteleev wrote:
This patch fixes a crash which occurs when SystemTools::GetPath attempts
to process an empty environment variable.
Applied, thanks:
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c544545c
FYI, the reason you don't show up as an author is
On 1/9/2012 3:44 PM, Mitchell, John A wrote:
add_executable(demo_cf_pointer demo_cf_pointer.F90)
target_link_libraries(demo_cf_pointer I_Fortran -lstdc++)
CMake prefers to use the C++ compiler to link when any C++ is involved.
Some toolchains use a prelinker step that actually runs the C++
On 1/3/2012 1:29 PM, Phil Smith wrote:
If I comment out line 29 in CMakeDetermineCompilerId.cmake, it works with my
old toolchain file
[snip]
So -- why are semicolons being inserted?
The change was discussed here:
http://www.cmake.org/pipermail/cmake/2010-March/035810.html
On October 24, 2011 6:08 PM Bill Hoffman wrote:
So, right at the end it is doing this:
C:/Program Files (x86)/CMake
2.8/share/cmake-2.8/Modules/CMakeDetermineCompilerId.cmake(96):
EXECUTE_PROCESS(COMMAND ${CMAKE_${lang}_COMPILER}
${CMAKE_${lang}_COMPILER_ID_ARG1}
On 1/20/2012 4:37 PM, Phil Smith wrote:
I'm confused because neither of your examples has the semicolon,
I was asking which one you need, so neither option has semicolons.
but what we need is:
regina.exe cc.rex dcc.exe CMakeCCompilerId.c
Okay.
But it sounds like you're saying that
On 1/21/2012 12:24 PM, Phil Smith wrote:
GOOD
C:/Program Files/Regina/regina.exe cc.rex dcc.exe CMakeCCompilerId.c
-- arg=[C:/Program Files/Regina/regina.exe]
-- arg=[cc.rex dcc.exe]
-- arg=[CMakeCCompilerId.c]
[snip]
BAD
c:/Program Files/Regina/regina.exe cc.rex;dcc.exe
On 1/25/2012 9:06 AM, Phil Smith wrote:
Just to be clear: that doesn't mean CMake is right -- it's not passing all
the arguments it should. How to move this forward?
IMO the change to CMake that exposed this was correct. The ARG1
has always been a literal string placed in command shells
On 1/25/2012 10:53 AM, Phil Smith wrote:
We've also provided other approaches elsewhere in this thread to
avoid the problem altogether by setting up your toolchain file to
skip compiler id detection.
OK, I'm willing to do that, but I can't figure out how to do so.
Actually the previous
On 1/25/2012 1:50 PM, Phil Smith wrote:
Ok, that *maybe* gets me further. CMakeDetermineASM_DIGNUSCompiler.cmake (in
Modules\) is:
SET(ASM_DIALECT _DIGNUS)
SET(CMAKE_ASM${ASM_DIALECT}_COMPILER_INIT asmit.bat)
INCLUDE(CMakeDetermineASMCompiler)
SET(ASM_DIALECT)
and that gets invoked several
On 1/27/2012 12:41 PM, Schuchard, Matthew wrote:
Contrary to the CMake FAQ, but consistent with what I have been
reading elsewhere, it does not seem possible for me with CMake 2.8.6
to add a generated file as a dependency to a target
I have done something similar to the following:
On 1/28/2012 11:36 AM, g...@novadsp.com wrote:
Is it possible to get CMake to process/search for an alternative
default filename to CMakeLists.txt?
Not currently. We're not fundamentally opposed to the idea, but it may
be tricky to get the interface right. Should the alternate name be used
On 1/31/2012 10:55 AM, Nicolas Desprès wrote:
All these considerations are important but maybe we could just do
first the easy path which is: add a -f option which change the default
name every where, for all sub-directories, try_compile, etc...
I'm willing to entertain patches but I really
On 2/1/2012 2:05 PM, Roland Schulz wrote:
what is the recommended Generator to compile on Windows with ICC on the shell?
If I try to use the Visual Studio 2010 (or 2008) generator
There is an open issue tracker entry requesting direct .icproj file generation:
On 2/10/2012 3:15 AM, Matt Fair wrote:
I'd like to be able to pipe cmake output and still have the ansi color
codes when the output is not TTY, is there a way to do this?
Not currently. The isatty test is hard-coded here:
Denis Barbier wrote:
Hello cmake maintainers,
vtk 5.4.2-7 FTBFS on ia64
https://buildd.debian.org/fetch.cgi?pkg=vtk;ver=5.4.2-7;arch=ia64;stamp=1275000467
In this version, local FindJNI.cmake had been dropped and replaced by
a dependency on cmake = 2.8.1-3
Configuration did not
Jed Brown wrote:
There is still the issue that module files don't get rebuild if they are
deleted,
make[2]: *** No rule to make target `include/petscmat.mod', needed by
`CMakeFiles/petscdm.dir/src/dm/f90-mod/petscdmmod.F.o'. Stop.
make[1]: *** [CMakeFiles/petscdm.dir/all] Error 2
I
Michael Hertling wrote:
On 06/14/2010 12:09 PM, Biddiscombe, John A. wrote:
I've modified the project so that it generates an hdf5-config.cmake
file, which checks for If(NOT target blah blah) and then loads the
hdf5-targets.cmake file.
[snip]
To make things more convenient, would it be
j s wrote:
So if I remove /opt/local/bin from my path, but use /opt/local/bin/cmake
(Macports) to build, it will work.
The compiler found is /usr/bin/gcc when /opt/local/bin/ is not in my
path. In our group we typically symlink /opt/local/bin to gcc-mp-4.3,
which may be causing the
j s wrote:
Brad King wrote:
From the CMakeOutput.log you sent it looks like the compiler
/opt/local/bin/gcc
is used while checking for the macros. Please run the build
with make VERBOSE=1 to see the full compiler command line
that fails at build time. Post it.
Files attached
[snip
Marcus Sindermann wrote:
Now we want to use update 65 of the Fortran compiler. This update
enforces Visual Studio to use the Intel Fortran xilink for linking
Fortran projects.
CMake just generates the .vfproj file and then VS is responsible for
the actual build. If the Fortran plugin is
Andreas Mohr wrote:
On Fri, Jun 25, 2010 at 08:23:06AM -0400, cmake-requ...@cmake.org wrote:
So is there any way in cmake to enforce Visual Studio to use link.exe
instead of xilink.exe?
grep -i LINK /usr/share/cmake-2.8/Modules/Platform/*|less
yields a ton of link-related CMake variables
James Amundson wrote:
This bug is a favorite of mine. It has been reported on the mailing list
before. It is also in the bug tracker:
http://public.kitware.com/Bug/view.php?id=10312nbn=1#bugnotes
In each case a patch has been given to solve the problem. Nothing has
happened, however.
The
Brad King wrote:
Can you modify the project file through the IDE by hand to chose the
linker you want?
s/chose/choose/
To be more clear, if it is possible to modify the project in the IDE
by hand to change the linker, then we can teach CMake to generate the
project file accordingly
Alexander Neundorf wrote:
On Wednesday 23 June 2010, Todd Gamblin wrote:
3a. First, using this setup, FindMPI fails because the last library it
needs is in /bgsys/drivers/ppcfloor/runtime/SPI, not
/bgsys/drivers/ppcfloor/runtime/SPI/lib. CMAKE_FIND_ROOT_PATH seems to
assume that its
Andreas Pakulat wrote:
On 26.06.10 13:26:29, Andreas Pakulat wrote:
Ping? Any further ideas on this? Could someone at least point me to the
source code in cmake that decides wether to add RPATH_REMOVE or
RPATH_REPLACE to the cmake_install.cmake file?
Look at
Todd Gamblin wrote:
So it's *probably* safe to set your CMAKE_FIND_ROOT_PATH to
/bgsys/drivers/ppcfloor, but technically it's outside your
definition above.
[snip]
Thinking about this some more, maybe you just don't *need* a
find root on BG/P ... You can get all the system information
you
Todd Gamblin wrote:
CMake cross-compile support is assuming that there is only
one (or maybe a few) directories where target software might be
installed.
I view this as CMAKE_FIND_ROOT_PATH helping for platforms whose SDKs
are organized that way. If there is no root and all the target
library
Look for a C/C++ compiler pair from known toolchains on some platforms.
This makes it less likely that mismatched compilers will be found.
Check only if the environment variables CC and CXX are both empty.
---
Todd Gamblin wrote:
1. Bootstrap script doesn't seem to work quite right on the
Cyril, Andrew,
On 6/9/2010 4:00 AM, Giraudon Cyril wrote:
I use Visual Studio Express 9 2008 and ifort 11.1 under Windows XP.
When I try to generate the fortran binding of a project a No
FortranCInterface mangling known for mysub message (reported hereafter)
is printed.
It seems CMake
On 07/03/2010 12:18 AM, Todd Gamblin wrote:
This patch works on dawndev (BG/P FEN) at LLNL.
Great, thanks for testing. I've published it to 'next':
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2ad2c2d7
-Brad
___
Powered by www.kitware.com
On 7/7/2010 7:45 AM, Marcel Loose wrote:
My pragmatic question is: is there a different way to check whether a
target has already been defined, or not.
Try this:
get_target_property(mytarget_exists mytarget TYPE)
if(mytarget_exists)
message(YES)
else()
message(NO)
endif()
The
On 07/08/2010 11:00 AM, John Cary wrote:
Concerning projects that I have no control
over, like hdf5 or trilinos, for our group
to be able to reinstall, I would like cmake
to install everything with g+w.
I see at http://www.cmake.org/cmake/help/cmake2.6docs.html
how the project can install
On 07/12/2010 07:51 AM, Verweij, Arjen wrote:
We’re finding incremental builds to be slow, because the F90 source
seems to be privy to a processing step known as “cmake_copy_f90_mod”.
While cmake and the compiler race through C/CXX/Fortran(77) source, this
is not the case for F90. What does
On 07/12/2010 01:12 PM, Verweij, Arjen wrote:
As a follow-up: redefining CMAKE_Fortran_LINK_EXECUTABLE to not include
FLAGS gets rid of the CMAKE_Fortran_FLAGS.. but perhaps other (useful)
stuff as well? As a sidetrack I’m starting to wonder what the purpose of
CMAKE_LANG_FLAGS is. The book
On 07/12/2010 01:25 PM, Verweij, Arjen wrote:
Can you comment on what other stuff ends up in FLAGS?
Looking at the implementation I see it gets architecture flags on
the Mac (-arch and -isysroot), which is consistent with the -m64
type flags I mentioned before. However it looks to me like
On 07/12/2010 01:23 PM, Verweij, Arjen wrote:
Cmake_copy_f90_mod gets called every time I type make for (as far as
can tell) every F90 file that provides a module. So for instance I
change a comment in my main.f, the compile and linktime for the
executable (4000 ish files) NOT including the
On 07/12/2010 02:47 PM, Verweij, Arjen wrote:
I will take a looksie and recompile cmake with your suggested fix.
The patch was more of a starting point for discussion among developers.
I think the same problem occurs for shared libraries too, but I see
evidence that it was done on purpose:
On 07/12/2010 03:06 PM, Verweij, Arjen wrote:
That bit of code is #IFDEF'ed for __APPLE__. I doubt it is causing the
problem on AIX.
That code is not the cause of the problem, just something that
might be broken by your workaround to the problem. AFAIK there
is nothing that will be broken on
On 07/12/2010 04:16 PM, Michael Hertling wrote:
In GCC's documentation, one can read:
-shared
Produce a shared object which can then be linked with other objects
to form an executable. Not all systems support this option. For
predictable results, you must also specify the same
On 07/13/2010 07:34 AM, Verweij, Arjen wrote:
Sent Brad source code to reproduce the bahaviour.
[snip]
I have figured out that the time spent is not lost in
cmake_copy_f90_mod, but in a make directive right before:
/usr1/people/maddev/util/bin/make -f CMakeFiles/mytest.dir/build.make
On 07/18/2010 09:10 PM, John Cary wrote:
Thanks for your help with this. I did
INCLUDE(FortranCInterface), but I did not
see in CMakeCache.txt any variables that
might contain the fortran libs needed by
the C/C++ linkers (e.g., libgfortran).
Did I miss something?
The FortranCInterface
On 07/19/2010 09:37 AM, John Cary wrote:
So this is very cool.
Thanks!
Somehow it is not quite working for me. My project is entirely
C++ with C and C++ libraries
All the magic I just described is for projects that mix Fortran
and C++ themselves. It will not handle this case because the
On 07/19/2010 11:46 AM, John R. Cary wrote:
So the lapack libraries are actually needed as a dependency of
Trilinos, another C++ library, which does the calling of the
symbols, and it must get those right, because if I add them to
the link line, then all links and runs.
Now I happen to know
On 07/20/2010 09:45 AM, Theodore Papadopoulo wrote:
On 07/19/2010 08:43 PM, Brad King wrote:
Note that if you use the *shared* libblas.so and liblapack.so then
you do not need to list the implementation dependencies explicitly.
This may not be true everywhere or forever...
Actually
On 07/21/2010 10:32 AM, Verweij, Arjen wrote:
Is it normal for generators to be this picky?
The generators are testing and inspecting the toolchain.
Something is not building as expected so it reports the
problem up front rather than waiting for some subtle
error when building the main project.
On 07/22/2010 09:43 AM, Mathieu Malaterre wrote:
Hi there,
I am trying to build ITK from a toplevel directory, my application
is setup simply like this:
$ cat CMakeLists.txt
project(MySuperApp)
find_package(VTK REQUIRED)
message(${VTK_VERSION})
add_subdirectory(ITK) # contains the
On 07/27/2010 06:48 PM, Russell Harmon wrote:
We're looking to use cmake on a project which has some dependencies
which are not properly picked up by cmake's dependency scanner. I'm not
looking to fix the scanner, because I feel the scanner is fundamentally
broken:
Yes, it certainly has some
On 08/04/2010 09:57 AM, Dave Semeraro wrote:
I am building projects on an AIX system and I want the contents of the
link.txt file to not include the -blibpath information at the end. I have
tried all combinations of the CMAKE_SKIP_RPATH and other rpath related
commands and can not get rid
On 08/04/2010 10:25 AM, Adolfo Rodríguez Tsouroukdissian wrote:
I'm writing a package config file foo-config.cmake, and I'm providing
version checking via the foo-config-version.cmake. Everything works
fine, but I've noticed that when version checking fails, the reported
error message is
On 08/04/2010 11:03 AM, Adolfo Rodríguez Tsouroukdissian wrote:
The foo-config.cmake file is located OK, and:
find_package(Foo REQUIRED NO_MODULE)
works as expected.
Sorry, I mis-read your message. The find_package call example clears it up.
Now, if I do:
find_package(Foo 6.6.6
On 08/04/2010 11:30 AM, Brad King wrote:
find_package(Foo 6.6.6 REQUIRED NO_MODULE)
and 6.6.6 is a non-valid version (i.e., PACKAGE_VERSION_COMPATIBLE is
set to FALSE in foo-config-version.cmake), then I get the error message
that foo-config.cmake is not found, instead of something related
On 08/06/2010 11:26 AM, Verweij, Arjen wrote:
I can execute the linkline manually and it seems to link fine.
How can I debug what's going on?
[snip]
-- The Fortran compiler identification is unknown
This is the first problem which may cause the others. CMake does not
recognize the compiler as
On 08/06/2010 03:12 PM, Verweij, Arjen wrote:
it does get recognized as Intel.
[snip]
-- The Fortran compiler identification is Intel
Good.
I started again, and included the manual link line. The rsp file exists
and contains CMakeFiles/cmTryCompileExec.dir/testFortranCompiler.f.obj,
the tmp
On 08/06/2010 04:22 PM, Verweij, Arjen wrote:
I did it is below the cmake error in the previous email. No error just a
prompt
And no noticeable difference to me.
Your previous message did
E:\cmake28\bin\cmake.exe -E vs_link_exe
E:\PROGRA~1\Intel\Compiler\Fortran\9.1\em64t\bin\ifort.exe
On 08/07/2010 03:52 AM, Verweij, Arjen wrote:
Apparently it breaks because of /INCREMENTAL:YES --
Interesting. It works for ifort 11.1. So does
ifort /incremental:yes myfile.f
ICE for any file with ifort 9.1?
Can I just turn this off in Windows-ifort.cmake or is this
symptomatic of
On 08/09/2010 12:39 PM, Verweij, Arjen wrote:
Both link rules for static libraries however do not contain
${CMAKE_START_TEMP_FILE} or ${CMAKE_END_TEMP_FILE} yet one platform I end
up with objects1.rsp but on the other the lists of objects are passed as
arguments to lib. Is there some implicit
On 08/05/2010 05:33 PM, Andreas Pakulat wrote:
Sure, this is the plugin that breaks:
http://gitorious.org/kdevelop/kdevplatform/blobs/master/plugins/reviewboard/CMakeLists.txt
Do you have KDE4_ENABLE_FINAL enabled?
-Brad
___
Powered by
On 08/10/2010 05:29 AM, Verweij, Arjen wrote:
The objects1.rsp file is generated by CMake during configuration. The
start/end temp file syntax tells NMake to use response files at build
time.
Why is this scheme only used for shared libs and not static libs?
For static libs it works
On 08/10/2010 09:13 AM, Andreas Pakulat wrote:
On 10.08.10 09:04:34, Brad King wrote:
On 08/05/2010 05:33 PM, Andreas Pakulat wrote:
Sure, this is the plugin that breaks:
http://gitorious.org/kdevelop/kdevplatform/blobs/master/plugins/reviewboard/CMakeLists.txt
Do you have KDE4_ENABLE_FINAL
Pakulat wrote:
On 11.08.10 11:08:22, Brad King wrote:
Please send me (off list) the whole CMakeFiles directory
Here you go, I did:
cmake -DCMAKE_INSTALL_PREFIX=$HOME/kdevelop-split ../
copy builddir_after_cmake
make -j3, waited for it to fail due to not-generated ui-header
copy
On 08/11/2010 07:04 PM, Andreas Pakulat wrote:
On 11.08.10 16:07:21, Brad King wrote:
This is what causes the header to be generated before dependencies
are scanned (as you observed in the quote above). I do not think
anything in the kdereviewboard target can compile before the above
steps
On 8/12/2010 8:36 PM, J Decker wrote:
cmake -G MinGW Makefiles /test
The path /test is not a valid full path on windows.
That syntax is used by many tools for command line options.
If I use a backslash instead:
cmake -G MinGW Makefiles \test
I get
CMake Error: The source directory
1 - 100 of 15210 matches
Mail list logo
