Arjen Markus wrote:
I did it this way just now too, but I found out that the intermediate
files are stored in the directory containing the CMakeLists.txt file!
Somehow a CMakeCache.txt file must have ended up in your source tree.
Once an in-source build is done it is impossible to do
Arjen Markus wrote:
this did not work! I checked out PLplot a-fresh, checked that there
are NO CMakeCache.txt files anywhere in the source tree, used a
fresh DOS-box to start the batch file in a directory separate from
the source directory and tried again.
The result: a CMakeFiles
Michael Wild wrote:
On 26. Jan, 2010, at 21:28 , Guillaume Duhamel wrote:
On the other hand, I've found out about the ExternalProject module in the
CMake documentation, could it be used to create a native-only CMake
sub-project?
Yes.
What I would really like is some way to have all
Brad King wrote:
As a first step, we can add Compaq to CMakeFortranCompilerId.F.in.
What is the preprocessor macro that identifies it?
I'd like to teach CMake upstream to recognize the Compaq Fortran
compiler even if we do not provide platform files for it yet.
CMake already recognizes
Arjen Markus wrote:
it does not work - I get a message that the Fortran compiler
identification is unknown. Does CMake run the compiler with the
/fpp option? If not, then that is the cause (without there is
no particular macro defined)
In CMakeDetermineFortranCompiler.cmake we list the
Arjen Markus wrote:
the program is compiled and linked without a problem. But
it writes:
INFO:compiler[]
INFO:platform[Windows]
I have examined the preprocessed source code and re-read the
online documentation: all the macros defined in the table I
looked at are available to the
Arjen Markus wrote:
Perhaps this means that _DF_VERSION_ is available only as a Fortran
language symbol.
It would look that way, but what use would it have then?
Perhaps it can be used in regular (runtime) IF tests? Of course other
compilers won't define it, so it's useful only in
Guillaume Duhamel wrote:
file(MAKE_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/c68k)
execute_process(COMMAND cmake ${CMAKE_CURRENT_SOURCE_DIR}/c68k
WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/c68k)
add_custom_target(c68kinc COMMAND cmake --build
${CMAKE_CURRENT_BINARY_DIR}/c68k)
It does
Arjen Markus wrote:
On 2010-01-28 17:18, Brad King wrote:
Thanks. Undo the previous patch and try the one below instead.
I applied the patch and it all worked fine. That is, CMake now
recognises the compiler but does not test it with the correct
compile flags (-o being reported
Arjen Markus wrote:
Hi Brad,
I just tested the patch - Compaq Visual Fortran is recognised,
but not accepted - and added the Windows-f90.cmake file from the
PLplot project to CMake's Modules\Platform directory. Now the
compiler is accepted as well.
The Windows-f90.cmake name is the old
Theodore Papadopoulo wrote:
I'm attaching (for comments) a modified FortranCInterface.cmake that
basically has two modes. If a fortran and
a C compiler are available, it works as it does currently except for teo
things:
- Error messages when C or Fortran compiler is missing should be much
Erwin Coumans wrote:
Hi,
How can we specify the actual directory where the executable ends up in
MSVC, without any messing around by adding 'Debug' or Release'?
I tried the following lines:
SET( CMAKE_RUNTIME_OUTPUT_DIRECTORY ${BULLET_PHYSICS_SOURCE_DIR})
SET(
Arjen Markus wrote:
f90.exe /compile_only -IF:\plplot-svn\plplot\bindings\f77\strutils.f
Compaq Visual Fortran has an option /include or /I or -I but also an
option /iface:keyword or -IF:keyword.
In this particular constellation it is interpreting the options in the
wrong manner!
Markus Duft wrote:
cmakes implementation of how child processes are handled doesn't work
reliably on multicore interix. it seems that every other SIGCHLD is lost
Is this a known problem on that platform, independent of CMake?
The ProcessUNIX.c implementation is for POSIX platforms, which
Markus Duft wrote:
Brad King wrote:
Can you print out the state of signal masks?
how can i do that? i'm not really into that topic that much :) but i'll
read some man pages to figure it out.
Look at sigprocmask docs.
it seems that i'm not hit by the select problem, as there is already
Alan W. Irwin wrote:
Could CMAKE_MODULE_PATH be treated as a colon-separate list of paths that are
searched one after another? That would solve the common modules issue for us.
It is already a list:
set(CMAKE_MODULE_PATH /some/path /some/other/path)
list(APPEND CMAKE_MODULE_PATH
On Interix we cannot rely on SIGCHLD because it is only sometimes
delivered. Our SIGCHLD handler wakes up any current select() call to
check if its child terminated, but the handler itself does not care
about any child. Therefore we can use the same handler with SIGALRM to
poll at regular
Alan W. Irwin wrote:
On 2010-02-18 08:14-0500 Brad King wrote:
Alan W. Irwin wrote:
Could CMAKE_MODULE_PATH be treated as a colon-separate list of paths
that are
searched one after another? That would solve the common modules
issue for us.
It is already a list:
set(CMAKE_MODULE_PATH
On 2/18/2010 8:38 PM, Samuel E. Henley wrote:
I have a new warning warning: -fPIC ignored for target (all code is
position independent) Under Windows - Mingw
CMAKE_SHARED_LIBRARY_C_FLAGS and CMAKE_SHARED_LIBRARY_CXX_FLAGS has to
be cleared of -fPIC, -fIPC is not used with gcc in Windows.
This
Arjen Markus wrote:
On Thu, 18 Feb 2010 16:21:33 -0800 (PST)
Alan W. Irwin ir...@beluga.phys.uvic.ca wrote:
I have a lot more CMake-2.8.1-RC3 testing to do myself ...
I have come across a nasty little error:
Under Cygwin it turns out that CMake 2.8.1rc3 is not
recognising gfortran, but
Hi Folks,
Kitware has moved to distributed version control for CMake in order to
better engage our growing community of developers and users. It will
enhance our process for accepting patches and help give credit to all
contributors.
We've chosen Git to implement this move. Details appear
Brad King wrote:
Kitware has moved to distributed version control for CMake in order to
better engage our growing community of developers and users. It will
enhance our process for accepting patches and help give credit to all
contributors.
For those following or contributing to the CDash
Alexander Neundorf wrote:
On Monday 22 February 2010, Brad King wrote:
Hi Folks,
Kitware has moved to distributed version control for CMake in order to
better engage our growing community of developers and users.
cvs diff still works here. How long will this still be available (read-only
Marcus D. Hanwell wrote:
How long is the rebase only, linear history policy likely to remain?
Currently this is undetermined. We wanted to get the conversion done
with minimal change in workflow for now. Once we've settled in to
using pure Git we can consider more advanced usage.
-Brad
Michael Jackson wrote:
Not associated with the author but I did find the following book/site
very useful when I switched to Git.
http://progit.org/book/
The book is open source, Ie, you can download a pdf of the book and
all the sources to the book are up on github.
There is now a link
On 2/22/2010 1:12 PM, Alan W. Irwin wrote:
I don't have access to Cygwin myself, but as a convenience for more Cygwin
testing by you and Arjen, I put together a simple test project that detects
Fortran identically to how it is done in PLplot
Thanks. I still get this:
-- The Fortran
Alexander Neundorf wrote:
Hi,
it seems the IAR C/C++ compiler for AVR cannot generate executables, but only
object files, and the linker has to be called explcitely on the generated
object files:
ftp://ftp.iar.se/WWWfiles/avr32/guides/ocavr32.pdf
Which says:
iccavr32 myfile.c
xlink
Markus Duft wrote:
the patch is ok as-is now. it fixes my issues on multi-core interix.
Great. Thanks for testing. I'll include it in CMake upstream as
soon as we have finished transitioning to the new Git repository
I announced yesterday and open it for publishing.
in combination with my
Philip Schwartz wrote:
Currently when setting CMP0015 to old, the warnings are still displayed.
As the policy is only a warning policy at this time there is no breakage
of the configure step other then a lot of unneeded warnings.
Use cmake_policy(GET) to check the policy value right before the
PG wrote:
I am using cmake 2.8 on linux (ubuntu 9.10 karmic), and found that with
policy CMP0003, libraries with full path provided shouldn't produce
linker search paths entry.
I made sure this policy is active by adding a
CMAKE_POLICY(SET CMP0003 NEW)
even though I used
Alexander Neundorf wrote:
This sees the variable is already in the cache, but without meta info and
adds
it using AddCacheDefinition().
After this call, makefile-GetDefinition(FOO) returns an empty string,
before this call it still returns foo.
It's not the empty string in find_program()'s
Alexander Neundorf wrote:
On Wednesday 03 March 2010, Brad King wrote:
http://www.cmake.org/Bug/view.php?id=9008
Should I add this testcase to #9008 ?
Yes, please.
-Brad
___
Powered by www.kitware.com
Visit other Kitware open-source projects
Teach compiler identification to support values such as
export CC='gcc -g -O2'
by separating the arguments on spaces. We already do this for the
values of CFLAGS, CXXFLAGS, and FFLAGS.
---
Hi Alan,
The standard way to do the set and forget approach with environment
variables is
export
Michael Wild wrote:
Won't that fail for compiler-installations with spaces in the path
(admittedly a bad idea, but on Windows probably not that unlikely)?
By the time the new code is reached we've already split the arguments
from the compiler itself. This is done in
Michael Wild wrote:
On 15. Mar, 2010, at 14:37 , Brad King wrote:
using the PROGRAM/PROGRAM_ARGS option of get_filename_component()
which already accounts for spaces in the path. It uses an algorithm
similar to what the Windows command prompt does. It works backwards
from the end and tries
Simmons, Aaron wrote:
Am I missing something? The code is below...
Top-level CMakeLists.txt:
cmake_minimum_required(VERSION 2.8)
project(test)
set(src ${CMAKE_CURRENT_SOURCE_DIR}/subdir/test.c)
add_subdirectory(subdir)
get_source_file_property(
Simmons, Aaron wrote:
Lots of these subfolders have per-source flags/args
Is there some other way to go about doing this?
Generally per-source flags should be reserved for tweaking and
workarounds such as using -O0 to disable buggy optimizations.
Their Makefile and VS project file
Brad King wrote:
Simmons, Aaron wrote:
Lots of these subfolders have per-source flags/args
Is there some other way to go about doing this?
Generally per-source flags should be reserved for tweaking and
workarounds such as using -O0 to disable buggy optimizations.
Their Makefile and VS
Simmons, Aaron wrote:
You have to send in a flag that tells it what audio api to use on which OS.
We rarely create source files that depend on definitions from the command line
to function (which is one reason per-source flags are not solid in CMake).
Instead we use configure_file() to put
Dean Inglis wrote:
Here is a bit more after some testing.
I tried compiling against the stable ITK release
(InsightToolkit-3.16.0) with CMake 2.8 and
get the same error. I removed CMake 2.8 and
installed CMake 2.6, did a clean config and build
of all sources and now the error no longer
david.k...@l-3com.com wrote:
One thing you can do with one directory full of .exe and .dll files is
to copy it somewhere else—to an arbitrary directory on another computer,
Perhaps the install() command is better for that.
-Brad
___
Powered by
Bill Hoffman wrote:
Alan W. Irwin wrote:
It has been reported (by Arjen Markus) that the MinGW issue
is because something in that case overwrites CMAKE_SOURCE_DIR
There is only one line in the entire source tree that ever sets
that variable. It's in Source/cmMakefile.cxx:
Arjen Markus wrote:
Hi Alan,
I have no time today to really dig into the output, but while
CMAKE_HOMEDIRECTORY points to the right directory, the outcome is
the same: the wrong information file gets loaded.
I will send the detailed output from cmake --trace in a separate
mail ( 0.5 MB).
Tyler Roscoe wrote:
On Fri, Mar 26, 2010 at 05:20:21PM -0500, Richard Wackerbarth wrote:
Now that the setup scripting is more complex, I'm trying to use your
cmake_common.cmake script for my CMake submissions. Tracking changes
to that script would be much easier for me if you have it published
Verweij, Arjen wrote:
Will 2.8.x clear this flag on Linux when the compiler is pgf90?
Yes, 2.8.1 has full support for PGI. Some platform info file
refactoring was done to avoid setting GNU-specific flags in
platform-wide files.
-Brad
___
Powered by
david.k...@l-3com.com wrote:
I very much sympathize with your aversion to re-introducing all this
fine-grained control
Okay, your argument presents sufficient motivation to consider this
extra control for build trees. See below (Moving forward...).
The command-line-and-templates alternative
david.k...@l-3com.com wrote:
(1) AFAIK the target.idb file can be anywhere so long as it is in
the same place every time the linker runs. Correct? Therefore we
can hide it away in the target.dir/ directory in the build tree.
Sounds good. That's where the .obj files go, right?
Yes.
(2)
Erwin Coumans wrote:
Like many, I want to distribute projectfiles, without forcing users to
install cmake to build my library.
This feature will never be supported by CMake upstream developers.
It is not a design goal for us. There are *many* things that CMake
does during the build process
Michael Wild wrote:
the dependency should prevent anything bad from happening.
Dependencies in the actual Makefile are not meaningful. It is
a front-end that launches a make process for driving the build
through CMakeFiles/Makefile2 which has the real inter-target
dependencies. Each target in
aaron_wri...@selinc.com wrote:
This builds ok the first time, but then change the generated.txt.in
and run the build twice and the second time you'll see Using
generated.txt again, which I don't want to see. I've tried VS 2008 and
NMake, using CMake 2.8 and 2.8.1.
I was able to reproduce
elizabeta petreska wrote:
I am using Visual Studio 2010 generator and cmake 2.8.1
The example code you show, does work with Visual Studio 2005 generator
and visual studio 2008 generator , but does not work with Visual Studio
2010 generator, i.e
If I touch the
elizabeta petreska wrote:
I add custom build step manually through VS10 dialog for the following
cmake code , and it works as it should. But if I run this through cmake
( not manually ) it does not work:
Interesting. We'll have to compare the manually-generated project file
with the
On 4/30/2010 10:52 AM, elizabeta petreska wrote:
Thank you for looking this
I am sending you two projects in the attachment, one manually generated
and one with cmake.
Okay, I think I found the problem. It is an interesting
interaction between old and new features. The file names
Tyler Roscoe wrote:
On Fri, Apr 30, 2010 at 12:03:12PM -0400, Brad King wrote:
Unfortunately this can't be fixed upstream without breaking the
legacy extension-finding feature.
Isn't this what CMake policies are for? Or is the offending code buried
in some dark corner where policies won't
Hi Michael,
Thank you for your detailed input on this topic.
FYI, I'm the original designer/implementer of find_package, find-module
support, and package configuration file support. Much like the rest of
CMake, it was created as needed. There was no monolithic design stage,
so there is some
Rene Salmon wrote:
xlc_r -O3 -qhot CMakeFiles/fd3ptr.dir/fd3ptr.c.o -o fd3ptr -rdynamic
xlc_r: 1501-216 (W) command option -dynamic is not recognized - passed to ld
/usr/bin/ld: unrecognized option '-dynamic'
/usr/bin/ld: use the --help option for usage information
Basically cmake is
Rene Salmon wrote:
cmake version 2.8.1
[snip]
Yes. It is xlc on Linux.
Prior to 2.8.1 CMake had a bug that led to use of -rdynamic with xlc
on Linux. Are you sure that the ccmake that you're running is 2.8.1?
I am doing and out of source build. Something like this.
Rene Salmon wrote:
Ahhh.. That is the problem cmake is not detecting the correct compiler ID.
hpci6001t(salmr0)139:rm -rf build/
hpci6001t(salmr0)140:mkdir build
hpci6001t(salmr0)141:cd build
/gpfs01/vol0/salmr0/mspain/fd/build
hpci6001t(salmr0)142:cmake ..
-- The C compiler
Rene Salmon wrote:
The above seems to somewhat work with ccmake as I can do a configure and
then a generate. I guess it does not work with cmake. How do I pick
compilers using the CMakeLists.txt file rather than setting environment
variables.
FYI, CMake is designed to let users choose their
Richard Wackerbarth wrote:
See RogueResearch6 and Chameleon00.NFSNet.
Both of these machines are reporting errors for some time.
This should fix the Architecture test:
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4d653fb4
It was actually passing but the regex to know that was not
Alexandru Ciobanu wrote:
You are right. The patch does not do the right thing.
I just observed that it also completely removes the
preinstall rule for excluded directories.
So make install insde those dirs will fail because there
is no preinstall.
Alexander Neundorf wrote:
I guess the
Philip Lowman wrote:
Neal Meyer wrote:
Is there any particular reasoning why for a shared library project the
.dll file is created in the LibraryOutputPath rather then the
ExecutableOutputPath. The Import library(.lib) should be placed in
the LibraryOutputPath, but it doesn't make any sense
Christian Ehrlicher wrote:
Hi,
I currently can't compile kdebase/konqueror because the paths exceeds
the max path length:
D:\kde-msvc\tmp\kdebase-beta3-3.94.1.20071011\work\kdebase\apps\konqueror\sidebar\trees\konq_sidebartreetoplevelitem.cpp
: fatal error C1083: Datei (vom Compiler
Hi Josh,
Thanks for your contributions!
Joshua Jensen wrote:
My version of CMake with the following changes can be found at:
svn co svn://svn.luaplus.org/CMake/patches/All CMake
Most notably is the support in TARGET_LINK_LIBRARIES for multiple configs.
I just downloaded this version. Most
Gerhard Grimm wrote:
Having searched for and read previous posts regarding this issue (June 2006), it looks
like ExceptionHandling=2 is only understood by Visual Studio 2005, but not by
.NET 2003.
Fixed in CVS CMake:
/cvsroot/CMake/CMake/Source/cmGlobalVisualStudio7Generator.cxx,v --
Gerhard Grimm wrote:
Hello there,
while testing the CVS version of CMake (2.5-20071116), I stumbled across
another problem:
The Visual Studio .NET 2003 generator does not honour the HEADER_FILE_ONLY
property
when set to TRUE for .cpp files - in CMake 2.4.7 those files were excluded
Bryan O'Sullivan wrote:
I have two sibling directories. In one of them, a binary is built, and
in the other, that binary is packaged up using a custom command. Is
there a way in the DEPENDS clause to express this dependency?
There are two levels of dependencies: file and target. File-level
Alan W. Irwin wrote:
So just keeping narrowly focussed on that fragment there is only one ALL
custom target and ADD_DEPENDENCIES would not help since it only works on
targets. Thus, I doubt there is anything locally wrong with dependencies
there. It is possible some other dependency is
Alan W. Irwin wrote:
So the rule seems to be that parallel builds do not work if there are two
or more separate custom targets that file depend directly or indirectly
(via
some custom command file dependency chain) on the same output files.
Another way of summarizing these results is that
Rodolfo Lima wrote:
Hi, I'd like to mention bug #6137 in bug tracker, where I've written a
patch to cmake (both 2.4 and 2.5-cvs) where I add a target property
(SOURCES) to get the sources assigned to a target.
Thanks, we're looking at the patch. We typically have constructed the
set of source
Alan W. Irwin wrote:
I am struggling with understanding the recursive make system that
CMake normally employs
CMake employs a 2-level make recursion system that is independent of the
directory structure. The first level never builds anything...it just
evaluates target-level dependencies with
Alan W. Irwin wrote:
Well, it turns out I had to add four different target dependencies to the
CMake-based PLplot build system to get rid of the parallel build problems I
was having on my Core Duo box. One of them was pretty subtle so I
missed it
for my first review of the dependencies.
Alan W. Irwin wrote:
So let me rephrase the question. Are the CMake developers happy with the
present state of the dependencies system or are you considering some major
changes there because of such issues as the difficulties in getting
parallel
builds to work properly for projects like
Bill Hoffman wrote:
Maik Beckmann wrote:
Hello CMake people
I pushed myself during the last weekends to get more familiar with
CMakes codebase. Not for fun only ;), but make me smart enough to
sketch an approach for handling fortrans module dependencies.
Bill, Brad, Alex ... it would be
Felix Obenhuber wrote:
Dear CMake developer and users,
I've encountered some probs with a an issue whitch already raised last
year in the a post [1].
Mingw32-make (5.1.3) minds about a too long linker line. The project
makes use of CMake for Makefile Generation, that's why I tend to ask
Felix Obenhuber wrote:
On Do, 2007-12-20 at 12:12 -0500, Brad King wrote:
Felix Obenhuber wrote:
CMake uses a link script approach to avoid placing the entire link
line in the makefile. It is enabled on certain generators (including
MinGW) and used for linking libraries but has not been yet
Felix Obenhuber wrote:
On Fr, 2007-12-21 at 10:41 +0100, Felix Obenhuber wrote:
Done. The Id is: 6192 [1]
Thanks Brad for fixing! Works like a charm!
No problem. It actually cleaned up the implementation used for library
linking too.
-Brad
___
Gonzalo Garramuño wrote:
Brad King wrote:
CMake uses a link script approach to avoid placing the entire link
line in the makefile. It is enabled on certain generators (including
MinGW) and used for linking libraries but has not been yet needed for
executables. Is the target for which
Rodolfo Schulz de Lima wrote:
Bill Hoffman wrote:
Something like this:
find_package(bar REQUIRED)
add_executable(foo foo.cxx)
target_link_libraries(foo bar)
This would be GREAT! What is the status on this one? Is it ready waiting
for testing or you are still developing it? I could use
Andreas Pakulat wrote:
On 20.01.08 17:11:17, Rodolfo Lima wrote:
Andreas Pakulat escreveu:
Naah, _boost_XXX is internal and not exposed. I rather have a
Boost_MINIMUM_VERSION. That would also allow to use REQUIRED and a more
verbose message saying wether the version is wrong or a needed lib
Andreas Pakulat wrote:
Anyway, the latest cvs version from cmake (update 2 hours ago) produces
the following entries in KDELibsDependencies.cmake. This file is
generated using the export_library_dependecies() command:
SET(kdecore_LIB_DEPENDS
Andreas Pakulat wrote:
Also I noticed that the linker line doesn't contain an option that gives
gcc the kde4 library dir to search for kde libs. This is another thing
which broke things for me here, i.e. ld complains that -lsolid cannot be
found (as you can see below there's a solid entry in the
Andreas Pakulat wrote:
Ok, I'll inform kde-buildsystem as this will probably need some time to
be fixed...
Thanks. Hopefully they can get it in a 4.0.1 patch release or something.
The linking implementation is going through an overhaul so there have been
more changes since your original
Steven Van Ingelgem wrote:
The problem in fact is in cmcommand.h @ line 67: InvokeInitialPass
Here there is done the pass through ExpandArguments, which removes
the knowledge of the quoted/unquoted nature of the arguments... Before
is known if it's VERBATIM or not...
I think this is a deep
Andreas Pakulat wrote:
Hi,
I can't build strigi with CMake CVS on one of my machines. It always
fails with the following when linking anything against strigi's
libstreams. On the same machine there's no problem when I use cmake
2.4.8
Linking CXX executable oletest
cd
Bill Hoffman wrote:
Steven Van Ingelgem wrote:
Personally I would expect it to find /usr/lib/libaspell.so.15, not a
directory... (on my system /usr/lib/aspell is a dir)
OK, read the email too quick. I think I know what is causing this. I
will work on a fix...
The find_library command
Fernando Cacciola wrote:
XXXConfig.cmake should be generated by the cmake script that configures
the library and it should contain the settings specific to that
configuration (such as source and binary folders, detected third party
dependencies, needed flags, etc)
Correct.
FindXXX.cmake
Yannick Cote wrote:
Hi,
visiting http://www.cmake.org/Wiki/CMake_Cross_Compiling, I discovered
a way to tell cmake not to test the C cross-compiler.
However the source tree has changed recently and including
CMakeForceCompiler will not work anymore.
CMake Error: Do not include the
Gonzalo Garramuño wrote:
Andreas Pakulat wrote:
On 04.03.08 10:51:10, Gonzalo Garramuño wrote:
Alexander Neundorf wrote:
Brad just documented this a few days ago:
http://www.cmake.org/pipermail/cmake-commits/2008-February/00.html
This is a pretty horrible and drastic change with no
Filipe Sousa wrote:
Philip Lowman wrote:
Filipe Sousa wrote:
I have been using EXECUTABLE_OUTPUT_PATH but I recently found that
CMAKE_RUNTIME_OUTPUT_DIRECTORY can do the same. Is
EXECUTABLE_OUTPUT_PATH going to be deprecated in 2.6?
Does CMAKE_RUNTIME_OUTPUT_DIRECTORY affect where .EXE
David Cole wrote:
With this declarative style script, the inner ctest run via
CTEST_COMMAND will use the CVSCOMMAND cache entry... CTEST_CVS_COMMAND
is used when you use the CTEST_UPDATE() command within a command-based
script (as opposed to a declarative script). Try adding:
Eric Noulard wrote:
2008/3/28, Mathieu Malaterre [EMAIL PROTECTED]:
I'll recompile cmake 2.6.0 and check if recompilation fix the issue.
Setting
CMAKE_BACKWARDS_COMPATIBILITY:STRING=2.4
did the trick.
Shouldn't you use CMAKE_POLICY instead
of CMAKE_BACKWARDS_COMPATIBILITY
Mathieu Malaterre wrote:
I'd like to reiterate my request for the attached patch. CMake 2.6.0
has become even more picky about the choice of compiler and now
completely delete the cache during a make rebuild_cache stage.
Step to reproduce:
- debian oldstable (where all package are build gcc
Hendrik Sattler wrote:
The C compiler test fails because CMake insists on createing
testCCompiler.c.r30 and there doesn't seem to be way to tell it to not
include the source file name extension (here: .c) into the object file
name.
It's undocumented because I didn't anticipate anyone would
Hendrik Sattler wrote:
I am not sure what the Compiler info is about, as it fails for this
compiler.
Minor though, just looks strange.
That's detecting the compiler ABI information like sizeof(void*). I've
updated the message to read ... compiler ABI info.
-Brad
Bill Hoffman wrote:
Hendrik Sattler wrote:
Zitat von Alexander Neundorf [EMAIL PROTECTED]:
This is the ABI test. It is not special for cross compiling, but it
would be
nice if it would work.
We need to see the error message.
I found out why: yet another bug in the compiler front-end. It
Philip Lowman wrote:
I noticed testing tonight with CMake 2.6.0 RC9 that MODULE_LIBRARY
targets (i.e. DLL plugins under Windows) are NOT copied to the
RUNTIME_OUTPUT_DIRECTORY. Is this a bug?
I thought the impetus for the CMAKE_RUNTIME_OUTPUT_DIRECTORY feature was
to get all DLLs dumped
George Neill wrote:
Bill,
Seems like RC10 handles quotes differently regarding ADD_DEFINITIONS,
e.g. in 2.4 patch 6
ADD_DEFINITIONS(
-DSOME_VALUE=\\value\\
)
in 2.6 RC 10
ADD_DEFINITIONS(
-DSOME_VALUE=value
)
Is this expected?
Yes, according to new CMake Policy
Hendrik Sattler wrote:
Hendrik Sattler schrieb:
I must correct myself. It works with:
- Windows, NMake Makefiles, Cmake-2.6 RC-9
- Linux, Unix Makefiles, CMake-CVS (RC-5 does not work)
It does not work with:
- Cygwin, Unix Makefiles, Cmake-2.6 RC-10
I just tried 2.6.0rc10 on Cygwin with
Vitor Vasconcelos Araujo Silva wrote:
With this, I have missing symbols for all calls to Qt functions. Of
course, if I add:
–lQtCore –lQtGui –lQtXml
To my linking line, everything links ok.
This problem does not occurs on Linux with gcc, but only with MinGW.
My point is, am
401 - 500 of 15210 matches
Mail list logo
