Alan W. Irwin wrote:
On 2008-05-07 14:45-0400 Brad King wrote:
Variable expansion without quotes has *always*
removed empty items. It occurs before the foreach command even sees
them and is consistent across all commands. We should not change this.
I don't agree. For consistency sake
Markus Israelsson wrote:
Of course I forgot to add.
None of the libraries are static. They are all SHARED. That is why it
confuses me. I have always used visual studio dependencies to build them
in a certain order. Also the dependency in visual studio means that
library A that uses features
Pierre Habouzit wrote:
The last cmake version broke on arm because of cmsys/CPU.h that don't
know about this architecture.
What is the error message you get?
The target CPU architecture is not known.
?
Thanks,
-Brad
___
CMake mailing list
Pierre Habouzit wrote:
On Tue, May 13, 2008 at 01:59:13PM +, Brad King wrote:
Pierre Habouzit wrote:
The last cmake version broke on arm because of cmsys/CPU.h that don't
know about this architecture.
What is the error message you get?
The target CPU architecture is not known
Arjen Markus wrote:
It means that a combination of MSVC and g95 in one project is
impossible.
I think the problem is that the platform files for GNU and MSVC tools
are both getting loaded but they have been written assuming they are
always separate (which is the case in C-and C++-only
Maik Beckmann wrote:
Am Donnerstag 15 Mai 2008 20:45:09 schrieb Maik Beckmann:
I'll configure my gcc installation to use concepts-checks and I'll do some
testing on the code at my workspace (i.e. boost) just to see how common
this kind of STL abuse is.
Well, boost.python fails to compile
Server Levent Yilmaz wrote:
I have a simple fortran project and am having a problem during compiler
identification stage. Attached is my CMakeLists.txt and the CMakeError.log.
Just to give some more details, the problem takes place on login nodes
(regular linux system) of a supercomputer
Arjen Markus wrote:
Brad King wrote:
Arjen Markus wrote:
It means that a combination of MSVC and g95 in one project is
impossible.
I think the problem is that the platform files for GNU and MSVC tools
are both getting loaded but they have been written assuming they are
always separate
Server Levent Yilmaz wrote:
However the executables are invalid. The reason, which took me a while
to figure out, is the use of shared libraries, which as I mentioned, is
not allowed in the Catamount system. The front-end wrappers
unfortunately do not automatically detect a possible misuse and
Phil Pellouchoud wrote:
I noticed that the TARGET_LINK_LIBRARIES seems to add .obj instead of
.lib to link libraries without an extension. I went back to 2.4 and
everything works fine... When it adds the .obj, obviously the build fails
because it can't find the .obj (it should be looking for
Arjen Markus wrote:
Brad King wrote:
The difference in link line generation from CMake 2.4 is
documented here:
http://www.cmake.org/Wiki/CMake_2.6_Notes#Link_Line_Generation
This documentation is helpful, but it also mentions that there are
side effects and these are not described
Christian Ehrlicher wrote:
I understood the warning - I know that it is not mandatory. But how useful is
a warning when the only way to get rid of them is to disable it? I either
have to fix all places (including the system libs) or disable it and don't
care at all. That's stupid.
Adding
Emmanuel Blot wrote:
Hi,
I'm using CMake (2.6) to build several C and C++ projects.
I'd like to add another project which would be a pure Python project:
CMake would simply have to invoke Python script (which in turn generates
an output file based on two input files).
What would be the
Emmanuel Blot wrote:
Hi,
I'm using CMake to build two C-based projects
The first CMake project builds several static libraries (ARM elf / eCos)
The second CMake project builds several application which do link
against the static libraries produced within the first project.
However, both
Blezek, Daniel J., Ph.D. wrote:
I'd like to build and install Insight (though the toolkit is not
important) using GCC. Then I want to build applications using GCC, the
Intel compiler, and IBM's XLC compiler. All should be able to use the
GCC-build libraries. However, CMAKE prohibits this
Allan Odgaard wrote:
I have the following CMakeLists.txt file:
project(foo)
add_executable(foo MACOSX_BUNDLE main.cc)
add_custom_target(run_foo echo running foo DEPENDS foo)
This is what I get (Mac OS X Leopard, CMake 2.6.0 and 2.7 from CVS):
% make run_foo
Christian Ehrlicher wrote:
I don't know if it's the intended behaviour or not:
I create a file on build time with add_custom_command.
ADD_CUSTOM_COMMAND(OUTPUT ${CMAKE_BINARY_DIR}/my_source.cpp
COMMAND makeMySource ARGS ${CMAKE_BINARY_DIR}/my_source.cpp
)
and add it
Brad King wrote:
Christian Ehrlicher wrote:
add_executable(myExecutable ${CMAKE_BINARY_DIR}/my_source.cpp)
cmake does not complain when the file does not exist. For instance when I
forgot the add_custom_command() or misspelled the filename. Instead I get an
error from make.
I know
Bill Hoffman wrote:
Dave Milter wrote:
cmake version 2.4-patch 8
and it not regenerates ui_foo.hpp after uncomment foo2.cpp,
so it is regression, or previous (good for me behaviour) cause many bugs?
It is not a bug. It was a bug fix. If you changed a custom command in
2.4 the rule would
Dave Milter wrote:
On 6/3/08, Brad King [EMAIL PROTECTED] wrote:
If you can please try CMake HEAD from CVS to make sure it solves your
problem. We'll include the fix in a 2.6 patch release.
I tried, not sure how to see global repository history, cvs log works
not how svn log works, but I
PCJohn wrote:
Thanks. VERBATIM was the problem. After, removing it, the code works
perfectly. Thanks!
Anyway, I am a little bit puzzled with documentation, as it states:
In the future VERBATIM may be enabled by default. The only reason
it is an option is to preserve compatibility with
Benjamin Roy wrote:
Hello,
I used to build Matlab Mex files using this kind of CMake files, the
build was working Both on linux and Windows (only with visual studio,
because gnumex is no longer support for MinGW and Matlab R2008):
# SET MEX files extension
IF(UNIX)
IF(APPLE)
Fernando Cacciola wrote:
It seems that pgCC is not supported even in 2.6.
In that case it is just a matter of adding a pgcc.cmake file with the
appropiate settings right? or would the CMake binary itself need some
patch?
It is supported in 2.6. The Modules directory has files
Steven Van Ingelgem wrote:
I don't know why, but if I take the build command from cmake, and I
insert the static libraries in there, it works all right. So somehow
it's reverting itself to some other version of the static and/or dynamic
libraries.
The entire point of me reporting this in
Steven Van Ingelgem wrote:
I don't seem to be able to make it link correctly?
I do:
set_property(TARGET ${SUB_PROJECT} PROPERTY IMPORTED_LOCATION ${PTHREAD}
${RT} ${LIBC})
But it's still somehow linking wrongly :(...
What would be the correct line for this?
You've mis-read the example.
Steven Van Ingelgem wrote:
Another issue I just noticed... If you link to an add_library or so,
it will add all the target linked libraries of the original
add_library, which is rather incorrect imho because I don't want to
link every library to a 100M static library, that is only compiled in
Martin Apel wrote:
WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}
For VS this is the default working directory if no WORKING_DIRECTORY is
given.
This calls a perl script to generate a bunch of Fortran files as needed.
This script has to run in the output directory. I have
Alan W. Irwin wrote:
On 2008-06-27 16:15+0200 [EMAIL PROTECTED] wrote:
Hi List,
Today I started to port my Ada project (Windows, MinGW, Ada cmake
files from plplot) from cmake 2.4.7 to cmake 2.6.
Now I have the problem that cmake doesn't want to use gnatmake anymore
and says that gnatmake
Alan W. Irwin wrote:
The issue is that for 2.4.8, rpath is set appropriately for the Ada
executable
to find the Ada shared library that was built, but for 2.6.0, rpath is not
set at all. Note, I do nothing special with rpath for this simple test
project so it just has the default rpath
Jarl Lindrud wrote:
|
| So what do I need to do to pass a $ character through to Visual
Studio, without the quotes? I’m using cmake 2.6.0 .
|
Just $$. I had the same problem and googled it here:
http://marc.info/?l=cmakem=120043575105964w=2
- -Wojciech
I tried that and it doesn't
John Biddiscombe wrote:
Brad King wrote:
I don't know, but there have been a few dependency fixes since 2.4.8.
I'd rather not track down a bug we already fixed. Please try it.
I built paraview using cmake 2.6 patch 0, first using 64 bit IDs, then I
changed to 32bits anf built again
Andreas Pakulat wrote:
Hi,
I've just noticed that re-running cmake and changing -DCMAKE_CXX_FLAGS
doesn't work as one would expect. This claims to be rebuilding the
makefiles, however after running a make clean and make VERBOSE=1 I don't
see the flags being applied.
To make this clear,
On 3/1/2012 11:21 AM, Matthew Schuchard wrote:
In particular, I have noticed that CMake cannot do module dependency scanning
outside of the current directory/subdirectories.
For example, if /topdir/dir1/src/ has a Fortran file with a dependency on a
module built in /topdir/dir2/mod/, CMake
On 3/1/2012 2:38 PM, Matthew Schuchard wrote:
I did see those links on the bug report for Fortran 90 module dependency in
subdirectories,
but I am having some kind of XML schema error preventing me from viewing them
in Firefox.
To what bug report do you refer, and to what links?
If I
On 3/1/2012 3:50 PM, Matthew Schuchard wrote:
I must not understand your example case correctly. Please post
a sample source tree tarball to reproduce it with CMakeLists.txt
files and the Fortran90 sources.
Unfortunately, this software is also proprietary,
Perhaps you can construct a
On 3/2/2012 10:28 AM, Matthew Schuchard wrote:
That person also had an issue with one Fortran 90 file using a module built by
another Fortran 90
file in the same target and directory, and had the same error message from
gnumake as I did.
His solution was to manually add a dependency since in
On 3/13/2012 1:10 PM, Alexander Neundorf wrote:
One option for cmake 2.8.8 would be, instead of erroring out to consider the
package not found.
That's a nice use case for the new pkg_FOUND behavior we've discussed.
The package configuration file would have to cooperate with the cmake-
On 3/27/2012 6:07 PM, David Cole wrote:
On Tue, Mar 27, 2012 at 2:41 PM, Mourad Boufarguine wrote:
I'm not sure if this is the right place to give feedback about the rc.
I noticed a regression with MSVC 2010 generator. Using this CMake command :
add_executable(project header.h header.hpp
On 3/28/2012 12:28 PM, Mourad Boufarguine wrote:
What about the CMakeLists.txt file ?
Oops, I was too focused on the header file part of your report.
This should fix it:
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=01e979ac
Thanks,
-Brad
--
Powered by www.kitware.com
Visit other
On 4/3/2012 2:23 PM, Mike Clapper wrote:
I am trying to bootstrap CMake-2.8.7 to HP NonStop using the OSS
environment. The environment provided by OSS is very similar to Linux
and Unix. The underlying hardware is IA64.
Thanks for working on the port. We'll be happy to take fixes upstream.
On 4/3/2012 9:33 PM, Christoph Anton Mitterer wrote:
Actually what I'd prefer most if add_definitions (and perhaps even
include_directories) could be set in a per file context[0].
add_definitions is the original interface and uses -D in its syntax for
historical reasons. The earliest
On 4/12/2012 4:05 PM, Michael Jackson wrote:
Dredging this up from last year because it has become relevant again (for me).
Has this effort gone anywhere?
Support was added for Absoft on Linux and Mac as of CMake 2.8.5
but I never had time to do Windows support. There has been no
nightly
On Mon, Apr 23, 2012 at 4:45 AM, Jörg F. Unger
joergfun...@googlemail.com wrote:
Hi everyone,
I'm using windows 7 (64). I'm trying to determine the python installation
using cmake.
The problem is that cmake only exists as a 32 bit application. As a
consequence, it has only access to the 32
On 05/10/2012 03:25 AM, Petr Kmoch wrote:
we're using cmake to generate Intel Fortran .vfproj files and some of
my developers were asking why include directories in the project
always include X and X/config_name for every directory X specified
via include_directories(). Looking at cmake source
On 05/24/2012 12:22 PM, Justin Holewinski wrote:
I narrowed the problem down to Clang not having
Platform/Windows-Clang-{C,CXX}.cmake files.
There is an issue tracker entry for this:
http://www.cmake.org/Bug/view.php?id=13035
but it is in the backlog waiting for more feedback and a
On 05/25/2012 08:40 AM, Keith Gardner wrote:
it looks like Visual Studio was using its own compiler even though
I specified a different one with CMake.
The VS generator does not support compiler selection.
Prior to VS 10 each IDE version only worked with one
toolchain version, and that behavior
On Wed, Jun 6, 2012 at 10:29 AM, Bill Hoffman bill.hoff...@kitware.com wrote:
On 6/5/2012 12:09 PM, Peter Kümmel wrote:
On 05.06.2012 17:12, Dave Abrahams wrote:
But when I install cmake the traditional way it works. It looks like
CMake doesn't tolerate being installed in a path containing =.
On Fri, Jun 1, 2012 at 6:47 PM, Zaheer Chothia zaheer.chot...@gmail.com wrote:
Projects generated by the wizard within Visual Studio have the version set to
11.0, as was the case with Intel Fortran 11.x and 12.x. This issue is easy to
diagnose (see patch following this mail) and I have tested
On 06/07/2012 02:06 PM, Andreas Schuh wrote:
For example, the link
http://www.cmake.org/cmake/help/cmake-2-8-docs.html#command:find_package
is rewritten to http://www.cmake.org/cmake/help/v2.8.8/cmake.html
instead of
http://www.cmake.org/cmake/help/v2.8.8/cmake.html#command:find_package.
It
On 06/07/2012 04:22 PM, Andreas Schuh wrote:
I see. I am using Safari 5.1.7 on Mac OS X 10.6.8.
We changed the redirection from server-side to JavaScript.
Now it appears to work in all browsers. If JavaScript is
disabled the page falls back to a static link, but of course
that won't have the
On 06/11/2012 07:21 PM, Ben Medina wrote:
Has anyone tried the Visual Studio 2012 beta with CMake's Visual
Studio 11 generator? I've tried with several projects, and even a
simple project that just contains main.cpp has the same problem:
compiling a single file does not work. Instead, I get
On Mon, Jun 11, 2012 at 7:21 PM, Ben Medina ben.med...@gmail.com wrote:
Has anyone tried the Visual Studio 2012 beta with CMake's Visual Studio 11
generator?
I just installed the VS 2012 RC from MSDN:
Microsoft Visual Studio Professional 2012 RC Version 11.0.50522.1 RCREL
Microsoft .NET
On 06/12/2012 11:43 AM, Ben Medina wrote:
Thanks for checking. Full project builds work fine for me; it's just
individual file compilations in the IDE that fail.
Okay. My initial read of your original message made it sound like
you got the error for any project even if it is only one file.
On 06/12/2012 11:51 AM, Brad King wrote:
http://www.cmake.org/Bug/view.php?id=12570
The main change to address it is here:
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d931ce9f
I forgot to point out that this change is not in CMake 2.8.8
but will be in 2.8.9.
-Brad
--
Powered
On 06/12/2012 11:51 AM, Brad King wrote:
http://www.cmake.org/Bug/view.php?id=12570
The main change to address it is here:
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d931ce9f
The problem was known to occur for VS 10 but did not in the
VS 11 developer preview. Perhaps it has
On 06/12/2012 02:55 PM, Ben Medina wrote:
I've filed a bug with Microsoft:
https://connect.microsoft.com/VisualStudio/feedback/details/748640/cannot-compile-individual-files-if-project-contains-full-path-to-file
Fantastic, thanks!
-Brad
--
Powered by www.kitware.com
Visit other Kitware
On 06/12/2012 02:20 PM, Ben Medina wrote:
- Using the VS2010 generator, the project files have relative paths.
VS2012RC can load 2010 project files without modifying them. If I do
this, compilation of individual files is successful.
- Using the VS11 generator, the project files have absolute
On 06/19/2012 09:13 AM, Daniel Dekkers wrote:
Although with the VS2008 generator setting the HEADER_FILE_ONLY property
works to exclude the files from the build, in VS2010 no such luck.
Am I doing something wrong in the syntax? Or is it a known issue with
VS2010?
IIRC CMake 2.8.7 and earlier
On 06/19/2012 11:28 AM, Daniel Dekkers wrote:
We were already using 2.8.8. We tried the nightly build but still no effect.
It's not just the obj files, it's xml, ttf, png, ...
The VS2008 generator works fine, with the nightly build as well, but
VS2010,.. no excludes.
I just tried 2.8.8 and it
On 06/19/2012 04:27 PM, Daniel Dekkers wrote:
SET_TARGET_PROPERTIES(HeaderOnlyTest PROPERTIES RESOURCE ${RESOURCE_FILE})
Does removing this line fix it?
-Brad
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please
On 06/19/2012 04:27 PM, Daniel Dekkers wrote:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8)
PROJECT(HeaderOnlyTest)
SET(SOURCE_FILE main.c)
SET(RESOURCE_FILE test.xml)
SET_SOURCE_FILES_PROPERTIES(${RESOURCE_FILE} PROPERTIES HEADER_FILE_ONLY
TRUE)
ADD_EXECUTABLE(HeaderOnlyTest ${SOURCE_FILE}
On 7/2/2012 12:25 PM, Matthew Schuchard wrote:
The executable name does in fact have to match the name of the source file.
I could get into details, but the short summary is that gcc-gnat is a
very headache-inducing compiler with poorly conceived input/output file
behavior and arguments.
On 07/06/2012 07:46 AM, Matthew Schuchard wrote:
I thought the change had been to preserve prior TryCompiles for
debugging purposes.
Would it be too cynical to propose some OS #ifdefs above the code?
Although you mention file systems, so this an NTFS issue also?
We don't know what causes it.
On 07/11/2012 03:40 AM, Evgeni Golov wrote:
Dear cmake maintainers, could you please have a look at the bug (and
build log) and guess why 2.8.9 stopped building the libraries in the
mdrun target? Is it a bad cmake file or a regression in cmake?
It is a regression in CMake AFAICT. I bisected
On 07/11/2012 02:29 PM, Brad King wrote:
Try adding the flag
-DCMAKE_INSTALL_DEFAULT_COMPONENT_NAME=Unspecified
to the CMake configuration step to work around the problem.
Nevermind about this workaround. I had tested it with a leftover
build of a good version during git bisect
On 07/11/2012 02:55 PM, Brad King wrote:
This hunk:
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7ced0732#patch4
Seems to have reversed a previous fix:
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=43cad3e4
of a problem similar to what we observe here.
This should fix it:
http
On 8/17/2012 5:03 AM, Sumit Adhikari wrote:
I have particular problem with the cmake generated output file naming
conventions (like myfile.cpp.o, myfile.cpp.gcno, ).
Object file names are computed in a deterministic manner
based only on the source file name and location. The
object name
On 08/19/2012 01:15 AM, Thomas Nilsson wrote:
Cmake no longer defines WIN32 on Cygwin. That's alright. However, in the
message you get when ccmake-ing it says:
or set the minimum required version of CMake to 2.8.4 or higher
I added
cmake_minimum_required(VERSION 2.8.4)
On 09/20/2012 06:28 PM, Sean McBride wrote:
On Thu, 20 Sep 2012 16:16:19 -0600, David Gobbi said:
You sure? I'm pretty sure the 4.4 command line tools didn't need
Xcode.app either.
Could be. I'm still using XCode 3.2 on my own box. It's the people
working under me who are using newer
On 09/21/2012 12:36 PM, David Gobbi wrote:
Thanks, I just did a build of VTK under XCode 4.5 with cmake-next and
it no longer sets the CMAKE_OSX_SYSROOT to a non-existent
/Developer/SDKs/MacOSX10.7.sdk. And with my old XCode 3.2 system,
it _does_ find and use the existing MacOSX10.6.sdk. It
On 10/03/2012 07:57 PM, Dan Furlani wrote:
#ifndef CODEGEN
#include GeneratedFile.h
#endif
As you point out CMake does not actually preprocess the sources.
You can hide includes from it like this:
#ifndef CODEGEN
# define CODEGEN_GeneratedFile_h GeneratedFile.h
# include
On 10/04/2012 12:38 PM, Dan Furlani wrote:
Thanks for the response. I considered that, it would solve the
problem for the codegen, but then CMake wouldn't be aware of the
(legitimate) dependency when it builds the program code.
If you hide it behind a function-like macro then you can use
the
On 10/09/2012 01:59 AM, James Bigler wrote:
On Mon, Oct 8, 2012 at 10:40 PM, James Bigler jamesbig...@gmail.com
mailto:jamesbig...@gmail.com wrote:
In my project I need to manually link against a special version of libstdc++
add_library(a SHARED a.cpp)
set_target_properties(a
On 10/10/2012 06:11 AM, Arindam Mukherjee wrote:
Here are the files.
The first line of this file is missing the leading '#':
$ head -1 cmake_aix/CMakeFiles/CompilerIdC/CMakeCCompilerId.c
ifdef __cplusplus
That means you've hit the issue reported here:
On 10/08/2012 05:30 PM, Matthew Woehlke wrote:
When I write a simple program using OpenMP, with a CMakeLists.txt like:
find_package(OpenMP REQUIRED)
add_definitions(${OpenMP_CXX_FLAGS})
add_executable(foo foo.cpp)
The value of OpenMP_CXX_FLAGS is CXX flags, not definitions. Try:
On 10/10/2012 02:27 PM, Arindam Mukherjee wrote:
On Wed, Oct 10, 2012 at 8:51 PM, Brad King brad.k...@kitware.com wrote:
$ head -1 cmake_aix/CMakeFiles/CompilerIdC/CMakeCCompilerId.c
ifdef __cplusplus
http://www.cmake.org/Bug/view.php?id=13149
http://cmake.org/gitweb?p=cmake.git
On 10/26/2012 09:43 AM, Leif Walsh wrote:
This is exactly what I wanted, and the results were incredible.
Thanks for testing. I've merged it to our 'next' branch in Git:
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ed976313
We still need to add a test before it can be merged for
On 10/26/2012 10:39 AM, Leif Walsh wrote:
Sure thing. Can you let me know where to find an example test? I'll pattern
match one over the weekend.
Most CMake tests just verify that binaries build correctly.
The Tests/BuildDepends test is the only one that actually
tests rebuild behavior. It
On 11/04/2012 07:59 PM, Bradley Giesbrecht wrote:
The problem is in commit e7e613e. Patching Darwin.cmake back to revision
43b74793 solves the problem.
The breakage is here:
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e7e613efbf1da45a2a9e51d11a4022589d79c642
Thanks for tracking it
On 11/05/2012 08:31 PM, Matthew Brett wrote:
Linking CXX executable shiboken
ld: framework not found QtCore
collect2: ld returned 1 exit status
make[2]: *** [generator/shiboken] Error 1
make[1]: *** [generator/CMakeFiles/shiboken.dir/all] Error 2
make: *** [all] Error 2
I get no such
On 11/06/2012 01:37 PM, Matthew Brett wrote:
I've attached the diff of the configs.
The diff for generator/CMakeFiles/shiboken.dir/link.txt shows
identical link lines except that 2.8.10 adds
-isysroot /Developer/SDKs/MacOSX10.6.sdk
to honor the CMAKE_OSX_SYSROOT. The change was here:
On 11/06/2012 03:29 PM, Matthew Brett wrote:
$ ls /Library/Frameworks | grep Qt
Qt3Support.framework
QtCore.framework
Okay.
$ ls -al /Developer/SDKs/MacOSX10.6.sdk/Library/Frameworks/
total 8
drwxr-xr-x 4 root wheel 136 Jul 13 21:21 .
drwxr-xr-t 3 root wheel 102 Feb 14 2011 ..
On 11/07/2012 03:14 PM, Matthew Brett wrote:
http://bugs.python.org/issue14018
Great, that is exactly this issue.
- I guess that explains it... Hum, how frustrating to have to worry
about the bad symlink.
Yes. You'll have to fix them locally. Thanks for reporting back.
-Brad
--
Powered
On 11/07/2012 03:41 PM, Matthew Brett wrote:
I was probably thinking of the problem in the same way as you are,
which is: how can I make sure that the build works or fails gracefully
for someone else if they have the same problem?
I'm not interested in spending much time trying to make the
On 11/07/2012 04:13 PM, Matthew Brett wrote:
We can warn about it though. Try adding something like this to the end
of CMake's Modules/Platform/Darwin.cmake:
if(IS_DIRECTORY ${CMAKE_OSX_SYSROOT}/Library/Frameworks AND
IS_SYMLINK ${CMAKE_OSX_SYSROOT}/Library/Frameworks/Frameworks)
On 10/26/2012 11:22 AM, Leif Walsh wrote:
On Oct 26, 2012, at 11:13, Brad King brad.k...@kitware.com wrote:
On 10/26/2012 10:39 AM, Leif Walsh wrote:
Sure thing. Can you let me know where to find an example test? I'll pattern
match one over the weekend.
Most CMake tests just verify
On 12/11/2012 04:20 PM, Ilias Miroslav wrote:
I appreciate your efforts resulting into the introduction of
the CMAKE_[C|CXX]_COMPILER_VERSION variables
Thanks.
However, I would need also the CMAKE_Fortran_COMPILER_VERSION variable.
It was not left out by accident. It cannot be computed
On 01/03/2013 04:33 PM, Bin Chen wrote:
clang: error: no such file or directory:
'/Users/bchen/share/temp/cmake-obj-lib/b-xcode/Debug/liba.a'
clang: error: no such file or directory:
'/Users/bchen/share/temp/cmake-obj-lib/b-xcode/Debug/libb.a'
Xcode does not seem to recognize targets that
On 01/13/2013 09:37 PM, Asmodehn Shade wrote:
bash-3.2$ xcodebuild Tutorial.xcodeproj/
=== BUILD AGGREGATE TARGET ZERO_CHECK OF PROJECT Tutorial WITH THE
DEFAULT CONFIGURATION (Debug) ===
Check dependencies
unsupported build action 'Tutorial.xcodeproj'
The
On 02/03/2013 12:54 PM, terje loe wrote:
set_target_properties(MyTarget PROPERTIES PLATFORM_TOOLSET v120_CTP_Nov2012)
I don't know if this is the correct way to do it, but if it is it would
be cool if it was implemented.. or some other solution.
There are similar feature requests in the
On 02/12/2013 08:15 AM, Petr Kmoch wrote:
project(Top) # No Fortran here
[snip]
My real setup doesn't really allow me to enable Fortran in the
toplevel project; is there a way to make this work without that?
CMake simply doesn't support this case right now. The language
initialization stores
On 11/05/2012 05:48 PM, Todd Greer wrote:
in parallel, these targets sometimes seem to collide, yielding an error like
this:
CUSTOMBUILD : CMake error : Cannot restore timestamp
outdir\CMakeFiles\generate.stamp
FYI, I've fixed this in upstream CMake here:
VS: Replace generation
On 2/26/2013 2:52 PM, Jean-Christophe Fillion-Robin wrote:
+1 to add these into CTest :) What would be the argument against it ?
Not every project wants every submodule checked out all the time.
A major use case for them is to have an umbrella project with many
submodules and the developer may
On 02/27/2013 12:36 AM, NoRulez wrote:
I think for the --tags option it is the same, isn't it?
How can I set such option for the checkout/update command?
The --tags option belongs to git fetch and extra flags can
be added for that by setting CTEST_GIT_UPDATE_OPTIONS before
calling
On 02/28/2013 02:38 AM, NoRulez wrote:
But if I set the option:
set(CTEST_GIT_UPDATE_OPTIONS --tags)
Then I get the following error message:
Update command failed: C:/Program Files/Git/cmd/git.cmd fetch --tags
Isn't that the command you want? Perhaps it really fails.
Try running it by hand
On 02/28/2013 11:11 AM, NoRulez wrote:
I've attached the two log files, can you take a look on it?
After running git fetch CMake reads .git/FETCH_HEAD to determine
what branch is intended for merge (just as pull does). This is the
same as git pull --tags failing. You need to specify the remote
On 03/11/2013 06:41 AM, Julien Bigot wrote:
add_custom_command(OUTPUT ${CMAKE_BINARY_DIR}/gen.f90
COMMAND bash ARGS ${CMAKE_SOURCE_DIR}/gen.f90.sh
${CMAKE_BINARY_DIR}/gen.f90
MAIN_DEPENDENCY ${CMAKE_SOURCE_DIR}/gen.f90.sh
VERBATIM
)
add_library(mylib STATIC usegen.f90
On 03/14/2013 12:43 AM, James Bigler wrote:
I'm not sure what the expected behavior is supposed to be
IMPORTED_LINK_DEPENDENT_LIBRARIES is not about transitive linking.
That is IMPORTED_LINK_INTERFACE_LIBRARIES.
The former is only for implementation dependencies of a shared
library that are not
On 03/14/2013 10:47 AM, Matthew Woehlke wrote:
This is now pushed to stage/fix-java-jar-depends. If someone
knowledgeable could have a look, that would be much appreciated.
Andreas, Nicholas?
Thanks,
-Brad
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
On 03/17/2013 09:14 AM, Nicolas Desprès wrote:
He said that the project is not broken by the new patches.
Great, thanks for taking the time to report back!
-Brad
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
501 - 600 of 15210 matches
Mail list logo
