[approach using package meta-data files to control build]
This approach minimizes the orchestrating effort and allows
developers to work on their part of an package without worrying
about unrelated projects.
Take a look at this thread:
Tyler Roscoe wrote:
Even if it were a policy, any project that tries to do this would get
the warning. Yes, it could temporarily avoid the warning by setting
the policy to OLD, but it should *still* be updated to the NEW
behavior! Again, policies are not used for choosing among desirable
Denis Scherbakov wrote:
Brad, could you please, ask someone who knows about this problem in detail
what is this more important feature and why it is not possible
to fix this bug?
Please report it here:
http://www.cmake.org/Bug
Could you suggest, how to prevent users from trying to compile
Will Dicharry wrote:
I spoke with Bill Hoffman at a conference last week, and he mentioned
that Kitware is currently working on a module to correctly find the
Fortran runtime libraries. I have written such a module, and if you are
interested (or haven't finished your own already), I'd like to
Will Dicharry wrote:
Thanks, it is issue ID 0009195. The attached module is
FindFortran.cmake. I didn't mention in my earlier message that the
module has also been tested on a Cray XT4 running CNL/PGI.
Thanks, I've assigned the issue to myself:
http://www.cmake.org/Bug/view.php?id=9195
Michael Schildt wrote:
Hello!
It been a while for this topic...
I would like to know if there are any (good) news on this issue. I have
exactly the mentioned problem using the ITK 3.14 source.
Do I have to make the suggested modification of the first post on this
topic to ALL the
Will Dicharry wrote:
The toolchain file looks like this (the project is actually mixed
C/Fortran code so there's some C/C++ stuff in the actual toolchain file,
but this simple toolchain with a simple Fortran exe reproduces the
problem):
set( CMAKE_SYSTEM_NAME AIX )
set(
Robert Bielik wrote:
Ok, apologies if this is already implemented, just haven't seen it.
When making Unix Makefiles, then link.txt script have archive files
(static libraries) listed in the
order they appear in the TARGET_LINK_LIBRARIES directive.
The GCC linker (LD) has the peculiarity that
Tyler Roscoe wrote:
On Wed, Jun 24, 2009 at 11:38:56AM -0400, Brad King wrote:
Flags can be passed to target_link_libraries too:
add_library(A STATIC a.c)
add_library(B STATIC b.c)
add_executable(main main.c)
target_link_libraries(main -Wl,--start-group A B -Wl,--end-group
Will Dicharry wrote:
It turns out that the problem is not the toolchain file, it's the flag.
Running the following reproduces the problem on both IBMs I have access
to:
$ FC=mpxlf90 FFLAGS=-qfixed=72 cmake ..
However,
$ FC=mpxlf90 FFLAGS=-q64 cmake ..
works just fine on both systems. How
Nathan Paul wrote:
Doesn't target_link_libraries only allow you to change the library used
for the configuration, not set the library path. Sure I could prepend
the correct path to the library, but it still doesn't change the library
path.
Specifying libraries by full path is the preferred
Bart Janssens wrote:
Hi all,
We're planning to move our project (K-3D) from SVN to Mercurial. Are
there any plans to support Mercurial in CTest? A search turned up
these results:
http://www.mail-archive.com/cmake@cmake.org/msg17597.html
http://public.kitware.com/Bug/view.php?id=7879
Thanks
Marcel Loose wrote:
Ah, must not have been the only one wondering ;-)
Do you, by any change, know if renames can also be done across
directories -- i.e. rename file dest-dir -- or does it only support
file-to-file and dir-to-dir rename?
It is just a wrapper around the posix 'rename' function.
Eric Noulard wrote:
If so, I still don't quite get the usage pattern in, e.g.,
CheckIncludeFile.cmake. What are they trying to check?
Better ask the author of this file :-)
This was a hack left from before the 'DEFINED' option was
available from the if() command. The code
if(VAR MATCHES
Will Dicharry wrote:
Mike Jackson wrote:
Can you post your module or attach it to a bug/feature request? I also
have a FindHDF5 module and I would like to compare the two.
Sorry about that, I meant to attach the module to the first email. It
is attached to this one.
After you two have
Dieter Oberkofler wrote:
This does sound very interesting but I'm not sure if I understand how this
might replace my need for a wrapper.
To better understand, it would be most helpful, if you could eventually post
a short CMakeLists.txt snipped on how to capture the output from a
compile/link
Pau Garcia i Quiles wrote:
Hello,
Is there anything like OPTION but which allows to select one value
from a limited list of values (a combobox). Something like:
OPTION( CRYPTOBACKEND Select a cryptography backend VALUES OpenSSL
LibTomCrypt LibDES DEFAULT OpenSSL )
There is in CMake HEAD
Ashwin Chandra wrote:
Notice the pdb file changed in case. I think what is happening is that
the compiler is generating the pdb file in all lower case on the first
build run and when doing a second build run, it somehow knows the file
is in lowercase now and it updates the build.make files
Frank Mertens wrote:
I started using cmake (2.6.3) under OpenBSD (4.5) and found it unwillingly to
link my software correctly.
The issue had been described some time ago:
http://www.cmake.org/pipermail/cmake/2006-November/011851.html.
I figured out that
Brad King wrote:
Frank Mertens wrote:
The solution was simple: cp NetBSD.cmake OpenBSD.cmake.
I think those two files can be kept safely identical.
Currently OpenBSD.cmake has this line:
SET_PROPERTY(GLOBAL PROPERTY FIND_LIBRARY_USE_OPENBSD_VERSIONING 1)
I've applied the commit below
John R. Cary wrote:
I am trying to build cmake on a Blue Gene P.
Configuration starts with
login1.surveyor$ ./bootstrap
-
CMake 2.6-4, Copyright (c) 2007 Kitware, Inc., Insight Consortium
[snip]
Bill Hoffman wrote:
So, it must be that the library is built with no soname. Brad will be
back in a few days, and should have a better idea of how to fix it.
This is probably the problem. You can confirm this by running
readelf -d /home/kchang/sandbox/thost/thostmduserapi.so |grep SONAME
John R. Cary wrote:
env CC=xlc_r CXX=xlC_r
[snip]
-- The C compiler identification is GNU
Be sure to create a fresh build tree when changing compilers.
CMake cached the 'cc' (gnu) compiler it found the first time
and did not pay attention to the environment later.
Arjen Markus wrote:
I do not think this is going to work: object files created with g77
and gfortran are not compatible as far as I know.
What constructs are they? F90/95 has one or two deleted features
but most compilers will simply accept them, perhaps grudgingly.
[snip]
How can this be
Will Dicharry wrote:
Sorry for the month of delay, but I've addressed Mike Jackson's concerns
below and I think I'm close to having the HDF5 find module ready for
submission.
Excellent. I have a few comments from quickly glancing at them, but
I don't have time for thorough testing. Overall
Will Dicharry wrote:
What is the convention for keeping a macro out of the public interface?
Leave it out of the documentation and name it with a '_hdf5_' prefix
(starting in '_').
-Brad
___
Powered by www.kitware.com
Visit other Kitware open-source
Will Dicharry wrote:
John R. Cary wrote:
I am a real newbie here (exploring cmake) so my words should be taken
with a grain of salt. But we find (in our current autotools
setup), that it is good to have a flag that tells one whether the hdf5
was
compiled with --enable-parallel.
I agree
John R. Cary wrote:
Brad King wrote:
John, how do autotools detect this?
hdf5par=`grep HAVE_PARALLEL 1 $HDF5_INCDIR/H5config.h`
I suppose there are other ways, but we have been doing this through
several versions of hdf5.
Great, thanks John.
Will, you should be able to use the file
Dominik Szczerba wrote:
I want to compile one file with fortran compiler (intel) and link with
the rest of my project. Will the latest cmake allow to fully cmakify
such scenario?
FYI, CMake HEAD from CVS has a whole bunch of new features for mixed
Fortran/C++ support. The main feature is that
Michael Wild wrote:
On 24. Aug, 2009, at 14:30, Brad King wrote:
FYI, CMake HEAD from CVS has a whole bunch of new features for mixed
Fortran/C++ support. The main feature is that CMake now automatically
detects the implicit language runtime libraries used by each language.
When a single
Will Dicharry wrote:
All,
I've committed the FindHDF5 and SelectLibraryConfigurations modules to
the CMake CVS repository.
Thanks for your input and feel free to contact me with questions
regarding the modules.
Great. Thanks for your contribution!
-Brad
Brad King wrote:
John R. Cary
venugopal gudimetla wrote:
I am using CMake 2.6.4 on Linux 64 bit platform. We are using absoft f95
compiler. I am trying to build cgns3.0 which uses CMake for building the
package.
FYI, to my knowledge no one has ever used CMake with that compiler.
We need to teach CMake about the compiler's
venugopal gudimetla wrote:
Thank you very much for your quick response.
BTW, Fortran support is greatly improved in CMake's development version.
If you can try the latest version from CVS HEAD, please do so.
Yeah I noticed too that for
some reason Cmakes is assuming f95 to be a GNU compiler.
Mathieu Malaterre wrote:
[ 4%] Built target cmsys
Linking C shared module libcmsysTestDynload.so
/usr/lib/gcc/powerpc64-suse-linux/4.1.2/../../../../lib/crt1.o:(.rodata+0x4):
undefined reference to `main'
What does make VERBOSE=1 say? Clearly this linker
line is missing the flag to make it
John R. Cary wrote:
BTW - should a 'CXX.cmake' file include *_C_FLAGS?
In principle no, but it works around some historical cruft
that hasn't been cleaned up yet.
Curious about how these work. I assume that cmake does
a mapping from the OS and compiler to a Platform file, but
then there are
venugopal gudimetla wrote:
Hi Brad,
This brings us back to
my question: does the compiler identify itself with any documented
preprocessor symbol?
I checked Absoft documentation and also asked Absoft support guys, there
doesn't seem to be a pre-processor macro which identifies itself.
Eric Noulard wrote:
Fair enough,
my tortuous mind was tracking the build tree yours
is tracking the source tree, this is obviously a
better choice.
My E3) case still remains, you really don't want to mess-up
an existing build tree with a unrelated source tree.
I know however that my
Robert Dailey wrote:
Hello,
I'm using the latest (as of now) CMake build from CVS head. I noticed
that when I specify a source file like so:
/Users/imac/work/redsword/projects/foobar/mysource.mm
XCode actually thinks it is here:
Robert Dailey wrote:
The goal here is to try to build Xcode projects for building iPhone
apps. My CMake logic for producing projects is rather complex, which is
why I am hesitant to post it here. But basically I'm taking the exact
path above and passing it into add_executable like so:
David Cole wrote:
Sounds like maybe you are using ${CMAKE_CURRENT_SOURCE_DIR} in a
function or macro. (defined at the top level, but called from a
lower level)...
That works just fine...evaluation of the variable is the location
of the current CMakeLists.txt file, not the file containing
Robert Dailey wrote:
My paths are correct. I'm passing in the correct absolute paths into
add_executable. I think that cmake is using the current cmake file
instead of using the one that the function call originated from. For
example, I have two CMake scripts:
Robert Dailey wrote:
I've attached a test project that reproduces this issue. At the root
test directory, create a new directory called 'build'. So you will
have test/build.
cd into test/build and run:
cmake -G Xcode ..
This will generate an xcode project for you. Open that, and
Robert Dailey wrote:
Great! Glad I could help. Let me know when this is fixed so I can
download a new nightly build. I'll try to keep up with that bug status
as well.
If you get an account in the bug tracker you can go to the issue and
choose monitor issue. Then you will get updates
Baron Roberts wrote:
Folks, I am generating Xcode 3.1 a project using cmake 2.6.2. I have noticed
that I am not able to connect the generated project to my Perforce SCM
system such that the files in the project are recognized as being in the
repository. While Xcode is able to access the
Hi Martin,
Thanks for trying the release candidate. It is helpful to get feedback
early in the release process.
Martin Apel wrote:
However I found a few quirks in the first rc:
1. I have quite a lot of Fortran files in one of our projects. We use
the Intel Fortran 11 compiler to compile
Andreas Pakulat wrote:
On 25.09.09 16:07:21, Bill Hoffman wrote:
I am happy to announce that CMake 2.8.0 has entered the beta stage! You
can find the source and binaries here: http://www.cmake.org/files/v2.8/.
I am sure I am leaving something out, but here is the list of changes
that I came
Mathieu Malaterre wrote:
On Fri, Sep 25, 2009 at 10:07 PM, Bill Hoffman bill.hoff...@kitware.com
wrote:
I am happy to announce that CMake 2.8.0 has entered the beta stage! You
can find the source and binaries here: http://www.cmake.org/files/v2.8/.
There is still one compilation issue
Mathieu Malaterre wrote:
/opt/ibmcmp/vacpp/9.0/bin/cc -DHAVE_GETHOSTBYNAME_R_5 -o
CMakeFiles/cmTryCompileExec.dir/CurlTests.c.o -c
/home/mmalater/Dashboards/My
Tests/CMakeXLC/Utilities/cmcurl/CMake/CurlTests.c
/home/mmalater/Dashboards/My
Mathieu Malaterre wrote:
The 32bits xlC is now perfectly clean, congrats !
Great!
A couple of warnings that's all:
http://www.cdash.org/CDash/viewBuildError.php?type=1buildid=439244
Warnings in system headers are always a pain. Can you please
investigate options to turn them off?
However,
Mathieu Malaterre wrote:
Are they linking to the right
one in the first place?
I do not understand the question... :(
My bad. For some reason I was thinking it was linking but failing
to locate the library it linked at runtime. In fact it is just
picking the wrong library and cannot link
Mathieu Malaterre wrote:
But since no other tests fails I would think discovery of 64bits libs
is working (I am guessing at least a test would fails). This looks
like just an issue in the findqt module.
However I do not understand what I need to do to fix
Modules/FindQt3.cmake, simply
Sean McBride wrote:
Hi all,
I've just tried building VTK with 2.8rc1 and it gives an error:
-- Check size of long
CMake Error at /Applications/CMake 2.8-0.app/Contents/share/cmake-2.8/
Modules/CheckTypeSize.cmake:102 (MESSAGE):
CHECK_TYPE_SIZE found different results, consider setting
Jason Slemons wrote:
actually he only gets the second error. I am using cmake/2.8.0-rc2. I’ve
attached the CMakeError.log. How can I get Cmake to suppress these two
flags? Strange enough this works under cmake 2.6.4(meaning these two
flags are not used).
The key error message is this:
The
Hi Jason,
I'm keeping this dicussion on-list so it goes in the archives.
I see two flag errors in the CMakeError.log file, one is for fpp and
the other is(buried, just near the end) for rdynamic. I also can add
this about my fortran compiler; it's called ftn and its actually a
wrapper
Jason Slemons wrote:
Hello Brad,
Is this a cross-compiling environment?
Yes it is, both are linux systems though. I'm mainly curious to see if it
will build for now though. Ill deal with testing the build later. Oh and I
noticed in CMakeSystem.cmake that it says:
Sebas wrote:
I use Intel Fortran y Microsoft C/C++ compilers.
Currently this is not a supported compiler combination.
Support for mixed C/C++/Fortran is new in CMake 2.8.
We've done very little work on mixed-vendor cases.
Please submit a feature request here:
http://www.cmake.org/Bug
-Brad
Mathieu Malaterre wrote:
Hi there,
I am trying some new functionalities in CMake, in particular:
http://www.cmake.org/Wiki/CMake_2.6_Notes#Packaging_and_Exporting
However using cmake 2.8, I get an error:
CMake Error at cmake_install.cmake:64 (FILE):
file INSTALL cannot find
Steven Wilson wrote:
Consider the following simple C++ file foo.cpp:
#include iostream
int main()
{
std::cout bar std::endl;
return 0;
}
Now consider the following CMakeLists.txt file for foo.cpp:
cmake_minimum_required(VERSION 2.6)
project(Bug)
Andrew Maclean wrote:
I guess the subject says it all. What is the status of using CMake,
Ctest and CDash with git?
CMake 2.8 comes with a CTest that can drive dashboards using git-based
work trees (plus hg and bzr). The ctest_update() command runs git pull
to update the work tree, and reports
Alan W. Irwin wrote:
The following CMake logic fragment illustrates the issue:
add_executable(plhershey-unicode-gen ${plhershey-unicode-gen_SRCS})
add_custom_command(
OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/plhershey-unicode.h
COMMAND plhershey-unicode-gen
Alan W. Irwin wrote:
cmake version 2.6-patch 4;
Unix Makefiles;
Linux (Debian stable with bootstrap build of CMake-2.6.4);
What's the easiest way to try the generator test here (for Unix
Makefiles)
so we are doing exactly the same test?
Get a CMake 2.6 source tree. Then run
$ cd
James Bigler wrote:
I noticed in some commit message to CMake a while ago that -fPIC was
removed from executable compilation.
Would anyone care to comment on why this is? I must admit I thought it
wouldn't hurt it to have it compiled with that flag.
It's unnecessary, and is actually a
Orion Poplawski wrote:
Trying to configure CGAL 3.5 with cmake 2.8.0 rc4 on Fedora and cmake is
segfaulting. Quick analysis shows that it's faulting here:
#1 cmMakefile::RaiseScope (this=value optimized out)
at /usr/src/debug/cmake-2.8.0-rc4/Source/cmMakefile.cxx:3392
3392
Bill Hoffman wrote:
Kelly (KT) Thompson wrote:
Hi,
I am trying to use Intel ifort on Linux to compile source code that
uses the extension .F95. By default, ifort will not compile files
with this extension. To allow the compilation, the name of the source
file must be preceded by -Tf
Steven Wilson wrote:
CMake is ignoring the LINK_FLAGS_CONFIG settings for
set_target_properties() when using the Xcode generator in the 2.8 branch
and the head branch.
It looks like the implementation is just plain missing from that
generator. Please submit a bug report here:
Mathieu Malaterre wrote:
Just wanted to say : great job on the find_package interface !
Thanks!
This is extremely convenient to use for package using cmake as build package.
All I had to do is configure a *Config.cmake and a
*ConfigVersion.cmake file. And then from the outside I can simply
James C. Sutherland wrote:
However, I just discovered that this is a deprecated feature, and that
install(EXPORT...)
should be used instead.
Good, it is much more modern and more powerful.
However, it is not clear to me how to incorporate dependencies when
using the install(EXPORT)
James C. Sutherland wrote:
The library I am building pulls in several other libraries (MPI, BLAS,
Boost, etc). I would like any down-stream apps that use my library to
automatically be able to include any appropriate header files and link
to appropriate third-party libraries that were
Kevin Burge wrote:
I have many built targets. When I do nmake install
FYI, you can skip the up-to-date check before install by using
nmake install\fast
it takes a long
time between each Built target... check (extremely long, compared to
using make on a Unix box). Is there any way to
Will Dicharry wrote:
Hi All,
This was asked a while ago at
http://www.cmake.org/pipermail/cmake/2009-January/026318.html, but it
doesn't look like there was a response to that question.
I have the same problem:
on 64 bit AIX, ar must be invoked with a -X 64 flag. Is there a way
to
James C. Sutherland wrote:
Thanks. To be clear, it only works if I use
set( ExprLib_LIBRARIES @TPL_LIBRARIES@ )
because otherwise I have no way of propagating the dependents of
ExprLib downstream. It is true that CMake will add the ExprLib
library as a target that can be used
Michael Wild wrote:
Looks like the scoping algorithm only overwrites these automatic
variables only if they are associated with actual arguments, otherwise
it just inherits them. Same thing happens if my_macro is a function.
Smells like bug to me ;-)
It's behaving exactly as documented.
Aslund wrote:
Hey everyone
I am trying to compile a program needed for my course at university. The
problem is that I get an error regarding linking to a library, as my
knowledge of CMake is limited and search for a solution didn't give
results, then I hope you can help me to find a
Tyler Roscoe wrote:
We then rebuilt Qt and told it to link dynamically against the system
libpng instead. That resolved the version mismatch problem, but now each
library in my product that links against Qt produces this warning:
CMake Warning at
Maik Beckmann wrote:
Oops, missed to cc to the mailing list
2009/11/16 Maik Beckmann beckmann.m...@googlemail.com:
2009/11/16 Bill Hoffman bill.hoff...@kitware.com:
But, that is not happening in my script. It is ending up on the correct
my.cdash.org LAPACK dashboard when I run this
Ben Medina wrote:
1. CMAKE_CFG_INTDIR is set to $(ConfigurationName), a macro which no
longer exists in VS 2010.
[snip]
2. The VS10 generator seems to no longer replace forward slashes with
back slashes in file paths, which breaks UNC paths in the project
[snip]
3. find_package (Qt4
Yannick Mortier wrote:
Hello!
We just tried out CMake 2.8.0 today and we found that our old CMake
build scripts don't work anymore.
One particular error was related to the handling of the current working
directory of the function
get_filename_component(FULLPATH ${SUBDIRECTORY} REALPATH)
Bill Hoffman wrote:
You want:
get_filename_component(MYPATH
[HKEY_LOCAL_MACHINE\\SOFTWARE\\7-Zip;Path] PATH)
The PATH option will strip off the last component of the path after lookup.
Use ABSOLUTE instead:
get_filename_component(MYPATH
[HKEY_LOCAL_MACHINE\\SOFTWARE\\7-Zip;Path]
Michael Jackson wrote:
So, there are a few of us quickly port the HDF5 1.8 code to CMake. I'm
thinking that we should put in an HDF5Config.cmake file for other
projects use.
Yes, it would be good to provide one of these.
What goes in one of those?
It should compute and set variables named
John Vines (CISD/CIV) wrote:
pgf90-Error-Unknown switch: -rdynamic
Due to some historic cruft this compiler is not supported on Linux right now.
In Modules/Platform/Linux.cmake comment out the line
SET(CMAKE_SHARED_LIBRARY_LINK_C_FLAGS -rdynamic)
This is on our TODO list for 2.8.x but we
Biddiscombe, John A. wrote:
However, for unknown reasons, when I use this code on the win32 machine
which is compiling the primary fortran projects happily, this happens
[snip]
The question is, why is/are the solution files being corrupted when
running in the CFortranInterface try compile
Hi Russell,
Thanks for tracking this down to such a specific set of conditions.
If you hadn't done that work up front it might have taken a while to
find this.
Russell Yanofsky wrote:
I think a safe and straightforward fix would be to make cmake use
SystemTools::CollapseFullPath for the path
Bill Hoffman wrote:
Bill Spotz wrote:
when the epetra dynamic library gets linked under the new cmake and
not the old. This could be problematic because it is using the
compiler /usr/bin/c++, which on my system is version 4.0.1 (although
the gfortran compiler is version 4.4.1).
So I have
Brad King wrote:
My guess is that CMake is generating a bad .vfproj file
It was generating a bad file in the case of per-source compiler definitions.
perhaps
due to the presence of both C and Fortran sources in one of the
detection project targets.
This was not the cause because
Hi Steve,
FYI, I've been a CMake core developer since 2001.
steve naroff wrote:
From my perspective, not being able to use relative paths just seems
'broken'. The reason for this limitation is totally unclear to someone
like me (who is an 'end user' of cmake). I'd love to hear a thoughtful
DONG Li wrote:
I am trying move my project from Linux to Mac. I have modified some
cmake files to successfully generate Makefile, but I'd like generate
xcodeproj file for use in Xcode. A few errors appeared, as following:
AFAIK the Xcode generator is totally untested with the Intel Fortran
Clinton Stimpson wrote:
It looks like a bug in the Xcode generator.
Here's an even simpler example:
project(test_xcode)
add_custom_command(OUTPUT ${CMAKE_BINARY_DIR}/test.h
COMMAND cp ${CMAKE_SOURCE_DIR}/test.h.in ${CMAKE_BINARY_DIR}/test.h
DEPENDS ${CMAKE_SOURCE_DIR}/test.h.in
Clinton Stimpson wrote:
If I specify the input (path to test.h.in) output (path to generated
test.h) for the CMake Rules build phase, the problem goes away.
Maybe we can put all inputs and all outputs in there for generated files
in that project? The script (makefile) it calls already has the
Eskandar Ensafi wrote:
When I use the Unix Makefile generator (or the NMake Makefile generator
under Windows), running “cmake --build bindir” does not produce color
output, whereas “cd bindir make” does. Is there a reason for this,
or have I stumbled upon a bug?
The color output
Hai Nguyen wrote:
I can't seem to get the combination of XCode and GCC 4.2 to be happy
with CMaka. I've tried several different ways to set the compiler
version. Setting the CMAKE_C/CXX_COMPILER doesn't seem to work. But if i
set the environment variabes, CMake comes back and tells me
Shepherd, Jason F wrote:
A follow on question: What if I don't want to require clapack,
but want to allow it if available. What is the correct way to
check for clapack or lapack?
The find_package() command has a QUIET option that could be used
to look for one and then the other without
Alan W. Irwin wrote:
Hi Brad and Alin:
Here is an example of the bug:
cat CMakeFiles/x02f95.dir/depend.make
# CMAKE generated file: DO NOT EDIT!
# Generated by Unix Makefiles Generator, CMake Version 2.8
f95/CMakeFiles/x02f95.dir/x02f.f90.o: /home/software/plplot
On 1/3/2010 2:44 PM, Alan W. Irwin wrote:
The PLplot test system assumes bash (either normal bash or win-bash) is
available and uses environment variables specified on the command line.
CMake does not assume this. We generate portable shell syntax.
To solve this issue, VERBATIM should
Johannes Felten wrote:
I took a look at the CMake 2.8.0 sourcecode and tracked it down to
Source/kwsys/ProcessUNIX.c in function kwsysProcessSetupOutputPipeFile I
believe.
I wonder why CMake sets the permissions explicitly to 644 here. Is this
a bug or done intentionally?
Nice find; it's a
the ENV lines up to
run before the inclusion.
-Brad
Brad King (2):
Recognize the PathScale C/C++/Fortran compilers
PathScale C/C++/Fortran Compiler Information
Modules/CMakeCCompilerId.c.in|3 ++
Modules/CMakeCXXCompilerId.cpp.in|3 ++
Modules
---
Modules/CMakeCCompilerId.c.in |3 +++
Modules/CMakeCXXCompilerId.cpp.in |3 +++
Modules/CMakeFortranCompilerId.F.in |2 ++
3 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/Modules/CMakeCCompilerId.c.in b/Modules/CMakeCCompilerId.c.in
index 6cd6437..5d004c7
K. Noel Belcourt wrote:
Brad King wrote:
Following this message is a patch series to support PathScale. Please
try it locally and send feedback to me. If it works I'll include it to
CMake upstream.
Yes, tested locally. Pathscale builds seems to work fine
Great. I've integrated
On 1/15/2010 5:58 PM, Alan W. Irwin wrote:
The PLplot project has been supporting some additional Fortran
compilers
What compilers?
FYI, the Compiler/* and Platform/* modules have been refactored
a bit in CVS HEAD CMake. The changes break compiler- and platform-
specific information down
Alan W. Irwin wrote:
messages for these files they deal with the following compilers/platforms.
* gfortran on Cygwin
* gfortran under MinGW
I think these work out of the box in 2.8.0. However, there has been more
development since that release (see bottom of message). They almost
Arjen Markus wrote:
I tried to do this, using the Compaq Visual Fortran compiler as a test
case, as I can do that rightaway, but I ran into some trouble:
Okay, I didn't expect this one to work yet.
The MinGW and Cygwin versions of gfortran should work though.
Please confirm this when you get a
301 - 400 of 15210 matches
Mail list logo
