First off, I'd like to say thanks to whoever is responsible for the huge
improvements in Fortran support in cmake-1.8.0. I've got most of the hdf5
Fortran testing framework essentially running smoothly on win32 intel visual
fortran 11.x - no changes necessary to the default Fortran flags and
Joseph,
You can have a look at what I am doing in GDCM. I can build the C++
library and wrap the interface using SWIG in C#.
Ref:
http://gdcm.sourceforge.net/
What you really want to look at are the CMake files here:
http://gdcm.svn.sf.net/viewvc/gdcm/trunk/CMake/
or the bug report:
cmake -E tar xvf is implemented...
Does this happen with other tar files, or just that one?
On Tue, Nov 24, 2009 at 11:07 PM, Brian Davis bitmi...@gmail.com wrote:
So I found this thread below and tried the command at the promp (Win7):
cmake -E tar xvf
CMake Error: Problem with
Please do post your info here as well.
On Wed, Nov 25, 2009 at 5:01 AM, Filip Wänström filip.wanst...@tii.sewrote:
Just wanted to add an update: I have managed to create a stand alone
MacOSX OpenSceneGraph app that works. Basically it boils down to
scripting the install_name_tool to create
Works fine for me on my Mac. Can't help with Windows 7 (or rather,
6.1, but then the marketing guys at MS probably figured to round that
up to 7... ;-)) as I don't have access to it.
$ mkdir test
$ echo Hello World test/hello.txt
$ cmake -E tar cvf test.tar test
drwxr-xr-x mwildstaff
Hello,
I have a problem relating to ExterlalPackage
I have to project (main and lib in this example) that is placed in two
directories next to each other where main needs lib to be able to
link. I have created a set up so that the main procject uses
ExternalProject to compile lib. This works
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
If you'd read on, you would see that I first CREATE a tar file, then
EXTRACT it and then show that the contents have been restored.
Michael
On 25. Nov, 2009, at 14:56 , Brian J. Davis wrote:
In your example you use cvf. This creates a tar file which is not
what I want to do. I want to
2009/11/25 Eric Noulard eric.noul...@gmail.com:
Moreover would you try to replace the current CPackRPM.cmake with the
one I attach to this mail
and retry with the very same CMakeLists.txt.
For the list, the problem seems to be e regression
due to a Fedora specific bug fix!!
I did re-open
Rather than try to explain, have a look at this one I made earlier it
inherits stuff from the parent project, but you should see what’s going on.
http://gitorious.org/hdf5/hdf5-v18/blobs/master/fortran/CMakeLists.txt
scroll down until you see
Hi Alex,
Maybe I'm overlooking all kinds of side effects, but the problem is in
line 6 of CMakeFortranInformation.cmake, where get_filename_component()
is called with an incorrect number of arguments. This happens because
${CMAKE_Fortran_COMPILER} is empty. If I simply put quotes around
The downside of Option #2 is that Eclipse will end up putting
the .project and .cproject files in your source directory which some
folks did not like, which is why they wrote the Eclise CDT generator.
For me, Option #2 is worth the couple of downsides.
disclaimer I also wrote the Wiki
(I tried to create a Mantis bug, but Mantis won't let me log in, and
when I try to reset the password, I see This account is protected. You
are not allowed to access this until the account protection is lifted.
I tried creating a completely new account, and I see the same message
with that.)
Hi Russ
I can't claim to fully understand your explanation, but I tried your
steps on Mac OS X 10.6 and CMake-2.8 and I can reproduce this error.
Really, really weird stuff!
Bet it took you quite some time, effort and nerves to track this one
down...
Michael
On 25. Nov, 2009, at 17:35
Hi Michael,
Thanks for trying this out. It wasn't too hard to debug after I noticed
the discrepancy in the CMake output. The simple explanation of the bug
is that when CMake runs, it writes the CMAKE_C_COMPILER value out to two
different files:
CMakeCache.txt
On Wednesday 25 November 2009, Michael Jackson wrote:
The downside of Option #2 is that Eclipse will end up putting
the .project and .cproject files in your source directory which some
folks did not like, which is why they wrote the Eclise CDT generator.
Some folks being the cmake developers.
Hi
One Problem.
There's one file in my sources that produces a cxx file in a pre build step
(similar to qt_ui or moc, swig ...)
But the source file isn't a h,c,cxx, file. It's a .if file thus I caonnot put
this to the project source files without getting an error.
Ok, but step by step...
On Wednesday 25 November 2009, Marcel Loose wrote:
Hi Alex,
Maybe I'm overlooking all kinds of side effects, but the problem is in
line 6 of CMakeFortranInformation.cmake, where get_filename_component()
is called with an incorrect number of arguments. This happens because
On Wednesday 25 November 2009, Sören Freudiger wrote:
Hi
One Problem.
There's one file in my sources that produces a cxx file in a pre build step
(similar to qt_ui or moc, swig ...)
But the source file isn't a h,c,cxx, file. It's a .if file thus I caonnot
put this to the project source
Yes so I did find the string regexp functions and the following seems to be
working for me.
For example (in case anyone else sees this thread and finds it helpful)
SET( FILE_NAME openssl-0.9.8a.tar.gz )
STRING( REGEX REPLACE [.]gz FILE_NAME_NO_EXT ${FILE_NAME} )
STRING( REGEX REPLACE [.]tar
Done, see Note 0018597
Best regards,
Marcel Loose.
On Wed, 2009-11-25 at 19:16 +0100, Alexander Neundorf wrote:
On Wednesday 25 November 2009, Marcel Loose wrote:
Hi Alex,
Maybe I'm overlooking all kinds of side effects, but the problem is in
line 6 of CMakeFortranInformation.cmake,
21 matches
Mail list logo
