programs.
(As for get_file_component: In the PLplot project the PATH part of the full
path to the compiler is used to fine-tune the directories where the compiler
libraries are to be found.)
Regards,
Arjen
Arjen Markus
Sr. Adviseur/Onderzoeker
T
+31(0)88 335 8559
E
arjen.mar
Hi Brad, Alan,
See below.
> -Original Message-
> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
> Sent: Tuesday, February 13, 2018 11:55 PM
>
> In general, you get native packages from the mingw64 repository and
> POSIX-aware
> packages from the msys2 repository for this dual-n
Hi Alan,
The result is the same or very much the same.
Regards,
Arjen
From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Arjen Markus
Sent: Friday, February 09, 2018 11:30 AM
To: Alan W. Irwin
Cc: cmake@cmake.org
Subject: Re: [CMake] MinGW-w64/MSYS2 (or Cygwin) and NAG Fortran
Hi Alan,
> -Original Message-
> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
> Sent: Friday, February 09, 2018 11:27 AM
> To: Arjen Markus
>
> Is the issue that you used the "Unix Makefiles" generator rather than the
> "MSYS
> Makefiles&
Hi Alan,
> -Original Message-
> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
> Sent: Thursday, February 08, 2018 10:59 PM
> To: Arjen Markus
> Cc: cmake@cmake.org
> Subject: Re: [CMake] MinGW-w64/MSYS2 (or Cygwin) and NAG Fortran - how to
> combine?
>
&g
Hello,
In the PLplot project we are looking for a way to combine the MinGW-w64/MSYS2
platform (or Cygwin) with the NAG Fortran compiler. The reason for this is that
both MinGW-w64/MSYS2 and Cygwin come with a nice repository of libraries, some
of which we can use in the context of PLplot. The
SHARED_LIBRARY
"
-Wl,-o,
")
Nothing fanciful, but it definitely helps to get DLLs built with NAG Fortran
and the accompanying C compiler.
Kind regards,
Arjen Markus
DISCLAIMER: This message is intended exclusively for the addressee(s) and may
contain confidential and privileged
Hi,
Fortran submodules are contained in a file with the extension .smod instead of
.mod. At least for Intel Fortran. It may very well be that this feature is not
yet supported by CMake. Unfortunately I have not yet had the opportunity to run
into this problem ;).
Regards,
Arjen
> ---
> Exactly, that is the whole point of the standardized `ISO_C_BINDING` module
> and C interop being added to the Fortran 2003 standard. No more ugly guess
> work, hackery, etc.
> AFAIK, there is pretty good support for this among compiler vendors, so long
> as you have a recent release.
> Even
Hi Nikolaus,
I think the parser for Fortran sources indeed does not take care of such
conditionals (they are also compiler-dependent, COCO never really got off the
ground). A workaround might be to define a dummy module by that name.
As for the selection of the Fortran compiler, you might che
: Wednesday, February 11, 2015 4:30 PM
To: Arjen Markus
Cc: cmake@cmake.org
Subject: Re: [CMake] Unexpected use of "ld" on Windows
Hi,
On Wed, Feb 11, 2015 at 3:16 PM, Arjen Markus
mailto:arjen.mar...@deltares.nl>> wrote:
Hello,
I am trying to build the Fortran interface to NetCDF4 o
Hello,
I am trying to build the Fortran interface to NetCDF4 on Windows, using the
Intel Fortran compiler and "Nmake Makefiles" as the generator (see
http://www.unidata.ucar.edu/downloads/netcdf/index.jsp).
I had some trouble getting the first part to build, but that is solved (small
issues wi
Hello lode,
You can use:
nmake verbose=1
to have the commands printed.
Regards,
Arjen
> -Original Message-
> From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Lode Leroy
> Sent: Tuesday, January 13, 2015 2:02 PM
> To: cmake@cmake.org
> Subject: [CMake] cmake + vc12
Hi Brian,
as I understand it, it is an explicit limitation of Visual Studio that a VS
project can only contain
a single programming language. The solution to this would to split the sources
into separate lists and
build libraries from them.
An alternative might be to use the Nmake approach - th
On Fri, 31 May 2013 09:47:47 +
"Leek, Jim" wrote:
Oh, if there any cmake way to get the fortran link flags
I need to pass to g++? I know -lgfortran is all I need in
this case, but if there was a generic way to get cmake to
figure it out for me, that would be nice.
I am not aware of an
Hi Jim,
I do not quite know why this works fine on Linux, but the
issue is caused by the C++ part of the link step. As you
are using g++ to link all the C++ runtime libraries, you
need to tell it what Fortran runtime libraries to add.
Linking with gfortran automatically ensures all these
librarie
Hello,
I have installed a very recent version of Cygwin on
Windows 7
(64 bits) and the version of CMake that comes with it
(2.8.9-2). When I use this however to configure and build
projects that work fine
under Windows (various versions0, then I get either
configuration
problems or build prob
On Fri, 04 Jan 2013 09:09:58 -0500
Bill Hoffman wrote:
I suspect you might be right. I am thinking this is
MSYS messing with the command line somehow. Can you
build with nmake and a DOS shell? If so, can you then go
into that tree with the msys shell and try to build?
Victory!
Withi
On Fri, 04 Jan 2013 09:09:58 -0500
Bill Hoffman wrote:
I suspect you might be right. I am thinking this is
MSYS messing with the command line somehow. Can you
build with nmake and a DOS shell? If so, can you then go
into that tree with the msys shell and try to build?
When I use CMak
On Sun, 06 Jan 2013 11:08:37 +0100
Rolf Eike Beer wrote:
This will work as long as PYTHON_LIBRARIES contains only
one element.
The debug/optimized keywords apply only to the
immediately following library, so if you have a list of
libraries returned (currently unlikely AFAIK) it may
still
Hi Bill,
I will try that later and I will let you know the results.
Regards,
Arjen
On Fri, 04 Jan 2013 09:09:58 -0500
Bill Hoffman wrote:
On 1/4/2013 3:31 AM, Arjen Markus wrote:
Hi Bill, Alan,
just to make sure, I checked that there is an e-drive
and a directory temp on that drive
he default MSYS shell.
Regards,
Arjen
On Fri, 04 Jan 2013 09:31:37 +0100
"Arjen Markus" wrote:
Hi Bill, Alan,
just to make sure, I checked that there is an e-drive
and a directory temp on that drive. These settings are
the same as always when I use the MSVC/C++ or Intel
Fortran
Hi Bill, Alan,
just to make sure, I checked that there is an e-drive
and a directory temp on that drive. These settings are
the same as always when I use the MSVC/C++ or Intel
Fortran
compilers.
My guess is that the use of the forward slash is messing
up the argument parsing:
- cl uses both "
Hello,
here is some further information: Alan Irwin drew my
attention to the generator I was using, so instead of
"MSYS Makefiles" I tried it with "NMake Makefiles".
I did not need to specify the compiler, that was correctly
recognised, but nonetheless the configuration step failed,
see the attac
Hello,
I have used the example project (from the CMake tutorial)
to illustrate the problem.
See the attached files.
The command was:
cmake -G "MSYS Makefiles" ../src -DCMAKE_C_COMPILER=cl
-DCMAKE_CXX_COMPILER=cl -D DCMAKE_AR=cl
Regards,
Arjen
DISCLAIMER: This message is intended exclus
Hello,
I forgot to mention that the version of CMake I use is
2.8.10.2
Regards,
Arjen
On Fri, 28 Dec 2012 13:32:59 +0100
Arjen Markus wrote:
Hello,
I am trying to use the MinGW/MSYS environment on Windows
(XP)
together with the MS Visual C/C++ and Intel Fortran
compiler.
I need the
Hello,
I am trying to use the MinGW/MSYS environment on Windows (XP)
together with the MS Visual C/C++ and Intel Fortran compiler.
I need the MSYS environment because after building the programs
there is a whole bunch of tests that have to be run and the
MinGW/MSYS environment offers the tools fo
Hello,
for whatever it is worth, C-style preprocessor commands
are a non-standard feature. The Fortran standard itself
defines only the "INCLUDE" statement (or directive).
Perhaps you can solve this in a standard way by moving the
logic to the CMakeLists.txt files rather than relying
on (possibly
solution on internet which suggested to
install VB and Intel Fortran. I tried and now cmake is detecting the C,
CXX and Fortran compiler.
Thanks for the suggestion anyway.
regards,
Kedar
On Wed, Jan 11, 2012 at 1:24 PM, Arjen Markus <mailto:arjen.mar...@deltares.nl>> wrote:
Hi Kedar,
if CMake can find the Fortran compiler and the command
"gcc" works from that same environment/DOS-box, then I
see no particular reason why CMake should not be able to
find it. Are the messages still the same (except for
the Fortran part)?
Note that you should start in a completely clea
Hello Kedar,
can you start the compiler from a command prompt
(DOS-box)?
That is: does the command "gcc" work?
If not, then you will have to add the location of the
compiler to your path:
path=c:\MinGW\bin;%PATH%
This, however, should have been taken care of by the
installation procedure.
C
Hello Gour,
we support D in the PLplot project - http://plplot.sf.net
You can have a look there to see how that is done.
Regards,
Arjen
On 2011-11-24 12:45, Gour wrote:
On Sun, 07 Aug 2011 11:32:53 +0200
jonathan MERCIER
wrote:
So, i would to know if cmaked2 will go to cmake ?
I'm also c
Hello,
this weekend I had trouble downloading CMake. Not sure if it
the problem was on my side or if it was at www.cmake.org, but
each time I tried to download the setup for 2.8.6 (or indeed
the source code) I ended up on the page "public.kitware.com".
The problem has gone now and I have downloa
Hello luxInteg,
you are trying to set the Fortran compiler to gfortran then?
Why? Why not leave it to CMake to come up with whatever compiler
is suitable? That is part of the strength of tools like CMake.
Regards,
Arjen
On 2010-11-16 20:44, luxInteg wrote:
Greetings,
I am learning cmake.
I
Hello Eric,
On 2010-09-29 17:51, pellegrini wrote:
Hello everybody,
I would like to compile my project using intel fortran compiler on my
windows machine.
When running the following commands:
cmake -DCMAKE_Fortran_Compiler=ifort -G"NMake Makefiles"
nmake VERBOSE=1
I can see that nmake use
Hi Brad,
I am glad it was something this simple (even though with far-reaching
consequences)! It is not something I could have found out myself.
Regards,
Arjen
On 2010-09-28 16:18, Brad King wrote:
On 9/28/2010 6:35 AM, Arjen Markus wrote:
for the PLplot project (http://plplot.sf.net) I
Hello,
for the PLplot project (http://plplot.sf.net) I have tried to use
the Visual Studio 2008 generator in combination with Intel Fortran
(version 11.1). Generating the solution and the project files
works fine, but when I try to build it all, I get error messages
about various symbols being
Hello,
I think I found the answer: it is only when actually building the
program that the source files get scanned and therefore the depend.make
file gets filled. That, of course, does make sense.
Regards,
Arjen
On 2010-09-23 10:18, Arjen Markus wrote:
Hello,
I am trying to create CMake
Hello,
I am trying to create CMake-based build system for a program
that uses both C and Fortran source files. While expanding the
CMakeLists.txt files to include a custom build step for one
C header file, I stumbled on something I do not understand.
The makefiles generated from my first version
Hello,
Alan Irwin and me ran into a rather peculiar problem concerning the
use of the GNU compiler suite on Windows. Here is the set-up:
- Alan's free_eos project uses the LAPACK and BLAS libraries.
- I tested his build system under Windows and to do that I first
built BLAS and LAPACK from sour
Hi David,
I would say put the CMakeLists.txt files under version control.
This is what we do within the PLplot project and that is what I
generally see: generated files are not managed, as you can always
generate them again.
(For convenience you can put them in version control, for instance,
to
Hi David,
that depends on the generator you specify: CMake "simply" creates
makefiles or project files that you can then use to build the
program or programs. In the case of "Visual C++ 2008", you need
Visual Studio 2008 to load the project (solution) and build it.
Regards,
Arjen
On 2010-09-07
s,
Arjen
On 2010-03-26 22:20, Alan W. Irwin wrote:
On 2010-03-26 16:44-0400 Brad King wrote:
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 entir
Could not find cmake module
file:C:/plplot-5.9.5/CMakeFiles/CMakeCCompiler.cmake
CMake Error: CMAKE_C_COMPILER not set, after EnableLanguage
-- Configuring incomplete, errors occurred!
________
Any suggestions?
Thanks,
Vince
2010/3/18 Arjen Mar
Hi Vincenzo,
it looks like CMake regards your gcc compiler as being similar
to the MS Visual C/C++ compiler, as the options it gets are
typical for that compiler.
Could you check that gcc is the first compiler in the path?
...
Oh! Can you try running CMake with the option -G "MinGW Makefiles",
On Mon, 22 Feb 2010 14:28:05 -0500
Brad King wrote:
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 PLplo
On Mon, 22 Feb 2010 10:12:12 -0800 (PST)
"Alan W. Irwin" wrote:
On 2010-02-22 08:35-0500 Brad King wrote:
I cannot reproduce this. I have a simple project:
# CMakeLists.txt
cmake_minimum_required(VERSION 2.6)
project(Foo Fortran)
I don't have access to Cygwin myself, but as a
convenie
, Brad King wrote:
Arjen Markus wrote:
On Thu, 18 Feb 2010 16:21:33 -0800 (PST)
"Alan W. Irwin" 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 i
On Thu, 18 Feb 2010 16:21:33 -0800 (PST)
"Alan W. Irwin" 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 instead g77.
The output from the test is ambigu
Hi Brad,
adding set(CMAKE_INCLUDE_FLAG_C "-I ") (and, just to be sure, its C++
cousin) did the trick all right. I can now build PLplot's Fortran
bindings and examples using the Compaq Visual Fortran compiler.
The only thing that worries me is that this may have an impact on
the C compiler too, a
King wrote:
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 m
Hi Brad,
I created a new issue in the CMake tracker regarding the refactoring
of the file Windows-Compaq-Fortran.cmake, as you wil have seen.
I tried some further tests today and was rather astonished to see
it all fail ... with a message from the Compaq compiler that it
was passed a keyword to
On 2010-02-11 09:13, Michael Wild wrote:
You might want to take a look at setlocal/endlocal:
http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/batch.mspx?mfr=true
Oh, I had completely forgotten that those commands exist too. That might
be the solution, actually!
On 2010-02-11 01:20, David Cole wrote:
On Wed, Feb 10, 2010 at 7:16 PM, Alan W. Irwin
Would setting that environment variable from cmake affect subsequent
Windows
builds? I don't have any Windows development experience, but this
question
just came up on the PLplot list.
Hi Brad,
On 2010-02-02 13:38, Brad King wrote:
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 accept
n the
repository, but I guess "df.exe" is not used as the name for a
possible compiler.
Regards,
Arjen
On 2010-02-01 15:26, Brad King wrote:
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 p
Hi Brad,
great, I should have time tomorrow to report back.
Regards,
Arjen
On 2010-02-01 15:26, Brad King wrote:
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
Hi Brad,
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 as ambiguous). I can
Hi Brad,
I will try the new patch tomorrow.
I tried printing it as an ordinary variable or constant, but that did
not work: variable names are not allowed to start with an underscore.
Regards,
Arjen
On 2010-01-28 17:18, Brad King wrote:
Arjen Markus wrote:
Perhaps this means that
Hi Brad,
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?
So we conclude that the compiler provides no way to identify itself
using the preprocessor. This will need non-trivial work in CMake to
re
, indeed
_DF_VERSION_ and _VF_VERSION_.
I tried to set the flag -fpp to /fpp /D_DF_VERSION_=660 to
force the definition, but the compipler sees these flags
as a single flag and stops.
Regards,
Arjen
On 2010-01-28 14:53, Brad King wrote:
Arjen Markus wrote:
it does not work - I get a message that the
Hi Brad,
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)
Regards,
Arjen
On 2010-01-28 14:27, Brad King wrote:
Arjen Markus
Hi Brad,
see my answers below
On 2010-01-27 19:18, Brad King wrote:
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 n
Hi Brad,
Arjen, please try out each compiler of interest with CMake 2.8.0 and
with CMake from CVS HEAD. Remove all plplot language module files
to see how much works out of the box.
I tested the gfortran compiler under MinGW (directly, not via MSYS)
having removed the gfortran-specific platf
Hi Brad,
that was better. Installed gfortran now under MinGW (from TDM) and
removed the Fortran-specific files from PLplot, so that it should
recognise gfortran out-of-the-box.
This does not work, but it is a gfortran/gcc problem. I will need
to look into that.
Regards,
Arjen
On 2010-01-26
Hi Brad,
ah, had to work from memory - normally I rely on my hard disk's
memory :). Will try again.
Regards,
Arjen
On 2010-01-26 15:36, Brad King wrote:
Arjen Markus wrote:
this did not work! I checked out PLplot a-fresh, checked that there
are NO CMakeCache.txt files anywhere in the s
source tree, CMakeCache.txt
in there too etc.
I tried it twice to make sure I made no mistake.
I installed CMake 2.8 today on this laptop, to make sure I had an
up-to-date version.
Any ideas what on earth is causing this?
Regards,
Arjen
On 2010-01-26 15:02, Brad King wrote:
Arjen Markus wrote
Hi Brad,
On 2010-01-26 14:37, Brad King wrote:
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 gfo
Hi Brad,
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:
- I removed the files referring to that compiler from my version of the
PLplot repository
- CMake complained at first about f90 - the -o option is ambig
Hi Brad,
On 2010-01-25 23:27, Brad King wrote:
Arjen, please try out each compiler of interest with CMake 2.8.0 and
with CMake from CVS HEAD. Remove all plplot language module files
to see how much works out of the box.
I will try this out as soon as possible.
Regards,
Arjen
_
Hi Jed,
yes, I'd say so. I have seen, I think, three or four different schemes
over the years, so that is fairly manageable.
Regards,
Arjen
On 2010-01-22 10:15, Jed Brown wrote:
On Fri, 22 Jan 2010 10:05:19 +0100, Arjen Markus
wrote:
This would indeed not work on systems that d
On 2010-01-15 23:58, Alan W. Irwin wrote:
The PLplot project has been supporting some additional Fortran compilers
via
files in cmake/modules/Platform in our source tree where we use
set(CMAKE_MODULE_PATH ${PROJECT_SOURCE_DIR}/cmake/modules)
This CMake_MODULE_PATH approach requires that we put
On 2010-01-21 18:27, Mark Moll wrote:
On Jan 21, 2010, at 10:22 AM, Jed Brown wrote:
On Thu, 21 Jan 2010 09:17:22 -0600, Mark Moll wrote:
You *can* use the Fortran BLAS/LAPACK libraries with C/C++ code.
Yes, this is actually very common, but check_fortran_function_exists
works by trying to l
On 2009-11-20 16:11, John Vines (CISD/CIV) wrote:
I am trying to compile a simple fortran "Hello World!" program with the
Portland Group compilers (version 8.0) and am running in to a problems.
I am using with CMake (ver 2.8.0-rc5).
/opt/compiler/pgi/linux86-64/8.0/bin/pgf90
CMakeFil
Hi David,
this is PLplot-specific, has nothing (or at least very little) to do
with CMake. The problem is that the program that creates these driver
files needs a few DLLs and they are not yet in the DLL subdirectory.
Can you check with DependencyWalker or similar programs what DLLs
are missing?
Hi David,
you should start cmake in a clean directory - old stuff might get in the
way otherwise, as a lot of information is being cached.
Regards,
Arjen
On 2009-09-10 10:05, David Aldrich wrote:
Hi Bill and Alan
Thank you both very much for answering my question. I did indeed have an old ve
Hello James,
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.
Regards,
Arjen
On 2009-08-18 23:3
Hello Natalie,
the linkstep in your makefile tries to create a complete program
out of hello.o, but the main program is in test.o.
In the PLplot project (http://plplot.sf.net) we have a similar
configuration: different programming languages that need to
be combined. The approach we take is:
- cr
Hello Alin,
that _could_ be a good reason :), but why not try to
verify this manually:
- Small C main program calling a Fortran routine
- The Fortran routine in a library
- Link via the Fortran compiler
Some Fortran compilers will need to know that the main
program is not in Fortran, others do
Hello Alin,
why not try to make Fortran the main language? If the linking step
occurs via the Fortran compiler, then that should take care of the
Fortran runtime libraries. This strategy won't work if you have
C++ included in the mix, though - C++ requires the C++ compiler
to do the linking, if I
On 2009-04-17 10:02, Hendrik Sattler wrote:
Zitat von Arjen Markus :
With -G "MSYS Makefiles" I do get the proper setting for MSYS.
The find_library command still insists on using the MS Visual C/C++
versions of the libraries, though, so I need to use my workaround
still. But at least
:
Zitat von Arjen Markus :
With -G "MSYS Makefiles" I do get the proper setting for MSYS.
The find_library command still insists on using the MS Visual C/C++
versions of the libraries, though, so I need to use my workaround
still. But at least one point is solved.
What libraries do y
On 2009-04-16 12:41, Maik Beckmann wrote:
Arjen Markus schrieb am Donnerstag 16 April 2009 um 12:07:
On 2009-04-16 10:43, Maik Beckmann wrote:
MSYS has its own generator, so this should be
cmake -G "MSYS Makefiles"
Hm, could that be the problem? I noticed that CMake is indee
On 2009-04-16 10:43, Maik Beckmann wrote:
Arjen Markus schrieb am Donnerstag 16 April 2009 um 09:32:
Hello,
in the PLplot project I have run into a few problems with the MSYS
environment under Windows XP. The first one is that the CMake variable
MSYS does not get set properly - or else I am
Hello,
in the PLplot project I have run into a few problems with the MSYS
environment under Windows XP. The first one is that the CMake variable
MSYS does not get set properly - or else I am doing something wrong.
Here is what I do to work under MSYS:
- Start the rxvt console (via a shortcut cre
Isn't that a compiler flag? You would have to specify that
at compile time, not link time.
Regards,
Arjen
On 2009-04-01 01:33, James C. Sutherland wrote:
Alin,
Thank you for your patience. I now have this set via
set( CMAKE_EXE_LINKER_FLAGS "-mbig-endian" )
However, this does not seem to af
> Yes, I know. But my problem is not with the compiler itself, but with
> CMake. It seems to assume, that during scanning of dependency and module
> information,
> files with a suffix of ".f" don't have to be preprocessed, whereas files
> with ".F" are preprocessed. I am searching for a way to tell
>>
> You are right, that this is uncommon. But I'm trying to replace an
> existing "build system" for some thousands of files, which preprocesses
> all Fortran files, even those with ".f" suffix. Unfortunately this is
> something I can't change.
> I could use the approach you suggest, but I'd like
>> -Original Message-
>> OK, but we can't just apply the patch to CMake as it would break the
>> older version of Fortran. Is there a way to detect which version is
>> installed from the registry or something? I am glad you are working,
>> but to get a solution for everyone, we need to g
>> Hi,
>>
>
> The output with VS2008 is:
> --
> H:\Work\test_cmake_fortran_windows\build>cmake .. -G "Visual Studio 9
> 2008"
> -- Check for working Fortran compiler: C:/Program
> Files/intel/Compiler/11.0/066/fortran/Bin/IA32/ifort.exe
> -- Check
Bill Hoffman wrote:
George Neill wrote:
Bill,
On Mon, Oct 27, 2008 at 8:46 PM, Bill Hoffman
<[EMAIL PROTECTED]> wrote:
I have just checked in a module to help with the linking of Fortran
from C.
I would appreciate some feedback, and perhaps some testing with
different
Fortran compiler
> Am Dienstag, 23. September 2008 schrieb Arjen Markus:
>> I do not know what the changes in the code actually are, but one major
>> problem was that using the
>> word "use" in comments caused a false dependency. I do not know about
>> infinite loops though.
&g
Myers, Gary wrote:
I have been using the Fortran dependency generator named makedepf90
(Erik Edelmann - 2.8.8) for years now. Recently, we have encountered
a bug in this application (infinite loop within the parser). I
noticed that Fortran dependencies are generated in cmake with the use
of
Ingrid Kemgoum wrote:
hi,
the question might be stupid but i didn't find the answer on the net.
as in Linux, after running cmake on the cmake directory we do make to
compile and build targets,
i want to know if there is a command to compile and build targets on
Windows.
It depends a bit on w
> On 2008-06-25 16:32+0200 Bernd Schubert wrote:
>
>> No, it is really no problem to link fortran libraries and to call their
>> functions. It is onkly a bit nasty sometimes to write the proto types of
>> the
>> blas/lapack functions, since nobody seems to have created a complete set
>> of
>> these
> On Monday 23 June 2008 19:26:36 Mike Jackson wrote:
>> Could you list off the top of your head some of the tools that have
>> given you trouble? I have never run into the line ending issues yet
>> but I may in the future. I would be good to have an idea what tools
>> will NOT handle unix line end
>
> Regardless of the cause of this problem, with both g77 and gfortran I get
> the proper results (success if the function exists, failure if not) if I
> change
>
> external ${FUNCTION}
>
> ==>
>
> call ${FUNCTION}()
>
> within CheckFortranFunctionExists.cmake.
>
> Alin and Brad (and any other For
Allen Barnett wrote:
Hi: I have a project which consists of a C++ main and a set of FORTRAN
computational routines which I'm trying to build on windows XP. I'm
using visual studio 2008 (VC9) and the Intel FORTRAN compiler (10.1) on
IA32. I'm also using CMake 2.6 patch 0.
If I generate NMake Make
KSpam wrote:
HS,
On Thursday 22 May 2008 02:05:33 Hendrik Sattler wrote:
KSpam schrieb:
Using this add-in would require that I create a corresponding .slnenv
file for each .sln file generated by CMake. In my case, the contents of
the .slnenv files can be the same (I am just setting P
Brad King wrote:
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
1 - 100 of 156 matches
Mail list logo
