Re: [CMake] Testing with multiple Fortran compilers

[Arjen Markus]

Hi William,



The compiler is not determined via this line - that merely retrieves the name 
component from the full path to the actual compiler executable. CMake uses a 
number of methods, if I may express it that way, to determine which compiler 
(Fortran or otherwise to use). One of them is the FC environment variable. If 
that is not set, it searches through a list of possible compiler commands.



As for CMakeCache.txt and the like: it is best to start a build in a clean 
directory. Left-overs from a previous build may confuse the configuration and 
actual building of the program or 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...@deltares.nl




[Logo]<http://www.deltares.com/>

 www.deltares.com<http://www.deltares.com/>

Postbus 177
2600 MH Delft

[Deltares Twitter]
<http://www.twitter.com/deltares>

[Deltares LinkedIn]<http://www.linkedin.com/company/217430>

[Deltares Facebook]<https://www.facebook.com/pages/Deltares/154189334634001>



[Think before printing]Please consider the environment before printing this 
email


> -Original Message-
> From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of William Clodius
> Sent: Friday, April 13, 2018 4:34 AM
> To: cmake@cmake.org
> Subject: [CMake] Testing with multiple Fortran compilers
>
> I have been using CMake with gfortran for a number of years, and now want test
> my code with ifort. I want to switch easily switch between compilers. My
> CMakeLists.txt file is based on the fortran example from make.org an appears 
> to
> have most of the infrastructure needed, but I don't understand how the line
>
> get_filename_component (Fortran_COMPILER_NAME
> ${CMAKE_Fortran_COMPILER} NAME)
>
> determines the Fortran compiler to be used. Does it examine the FC system
> variable? Does it require the full pathname to the compiler executable? Do I 
> have to
> delete the CMakeCache.txt, Makefile, and cmake_install.cmake each time I 
> change
> compilers?
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake

DISCLAIMER: This message is intended exclusively for the addressee(s) and may 
contain confidential and privileged information. If you are not the intended 
recipient please notify the sender immediately and destroy this message. 
Unauthorized use, disclosure or copying of this message is strictly prohibited. 
The foundation 'Stichting Deltares', which has its seat at Delft, The 
Netherlands, Commercial Registration Number 41146461, is not liable in any way 
whatsoever for consequences and/or damages resulting from the improper, 
incomplete and untimely dispatch, receipt and/or content of this e-mail.
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] MinGW-w64/MSYS2 (or Cygwin) and NAG Fortran - how to combine?

[Arjen Markus]

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-natured platform, and cmake 
> is
> one of those rare beasts that has a package in each repo.
>
Yes, I have both - one in $PREFIX/mingw64/bin and one in $PREFIX/usr/bin. The 
latter is the MSYS2 version.

> @Arjen: to answer Brad's questions you should modify our top-level 
> CMakeLists.txt
> to also report CMAKE_HOST_SYSTEM_NAME (just in case that is not the same
> as CMAKE_SYSTEM_NAME which we already report there).  >


The MinGW version of Cmake reports Windows for both variables and the MSYS2 
version reports MSYS.

I set CC and FC to x64cc and nagfor respectively before invoking CMake (either 
version), so that the proper tools are used. However, the problem is that 
sometimes the configuration fails, sometimes the build fails. There is very 
little information about what is going wrong. Or there is a lot I simply fail 
to find the wanted needle in that haystack.

I have also had a situation where the Freetype library was recognised but the 
build failed on a bunch of unresolved externals.

Further complication: my trial licence for NAG Fortran ends today :(.

So, the exercise up to now has brought us a nice way to use NAG Fortran in its 
native environment, but without the benefit of installed packages under 
MinGW-w64/MSYS2.

The number of combinations to try is also rather big, I am afraid. That would 
require a lot more trial and error, if no pruning is possible.

Regards,

Arjen

DISCLAIMER: This message is intended exclusively for the addressee(s) and may 
contain confidential and privileged information. If you are not the intended 
recipient please notify the sender immediately and destroy this message. 
Unauthorized use, disclosure or copying of this message is strictly prohibited. 
The foundation 'Stichting Deltares', which has its seat at Delft, The 
Netherlands, Commercial Registration Number 41146461, is not liable in any way 
whatsoever for consequences and/or damages resulting from the improper, 
incomplete and untimely dispatch, receipt and/or content of this e-mail.
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] MinGW-w64/MSYS2 (or Cygwin) and NAG Fortran - how to combine?

[Arjen Markus]

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 - how to 
combine?


>
Hm, you may be right - I will try that today (left-over from a previous attempt 
:)).

DISCLAIMER: This message is intended exclusively for the addressee(s) and may 
contain confidential and privileged information. If you are not the intended 
recipient please notify the sender immediately and destroy this message. 
Unauthorized use, disclosure or copying of this message is strictly prohibited. 
The foundation 'Stichting Deltares', which has its seat at Delft, The 
Netherlands, Commercial Registration Number 41146461, is not liable in any way 
whatsoever for consequences and/or damages resulting from the improper, 
incomplete and untimely dispatch, receipt and/or content of this e-mail.
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] MinGW-w64/MSYS2 (or Cygwin) and NAG Fortran - how to combine?

[Arjen Markus]

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" generator for the MinGW-w64/MSYS2 test?  I believe you have found
> both generators work pretty well for this platform, but in order to use your
> "Windows-NAG-Fortran.cmake" platform file, you may find that the "MSYS
> Makefiles" generator is the one you
> *must* use.
>
Hm, you may be right - I will try that today (left-over from a previous attempt 
:)).

Regards,

Arjen

DISCLAIMER: This message is intended exclusively for the addressee(s) and may 
contain confidential and privileged information. If you are not the intended 
recipient please notify the sender immediately and destroy this message. 
Unauthorized use, disclosure or copying of this message is strictly prohibited. 
The foundation 'Stichting Deltares', which has its seat at Delft, The 
Netherlands, Commercial Registration Number 41146461, is not liable in any way 
whatsoever for consequences and/or damages resulting from the improper, 
incomplete and untimely dispatch, receipt and/or content of this e-mail.
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] MinGW-w64/MSYS2 (or Cygwin) and NAG Fortran - how to combine?

[Arjen Markus]

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?
>
> On 2018-02-08 19:33- Arjen Markus wrote:
>
> > So: Is it possible to instruct CMake to use the NAG-Fortran specific
> settings [for the Cygwin and MinGW-w64/MSYS2 platforms] and if so, how do I do
> that?
>
> Hi Arjen:
>
> I think you should be guided by what goes on for gfortran. For that compiler, 
> the
> relevant Platform files are called CYGWIN-GNU-Fortran.cmake and Windows-
> GNU-Fortran.cmake Platform files for the Cygwin, and MinGW-w64/MSYS2
> platforms.  Furthermore, in all the existing nagfor cases (Linux and Darwin), 
> you
> derive the nagfor-related name from the gfortran related name by replacing 
> GNU-
> Fortran by NAG-Fortran. Therefore, I suggest you try the names CYGWIN-NAG-
> Fortran.cmake and Windows-NAG-Fortran.cmake for the two separate Platform
> files you are trying to create for the Cygwin and
> MinGW-w64/MSYS2 platforms.
>
I have a Platform file "Windows-NAG-Fortran.cmake" and that is used correctly 
if I start the NAG Fortran environment (using the MinGW Makefiles generator), 
but if I try the same with MinGWw-w64/MSYS2, this file is clearly ignored - I 
see the compiler fail on a typical GCC flag for creating shared libraries (the 
Platform file I added takes care of that in the NAG Fortran environment and 
therefore the build succeeds).

My guess is that the environment is determined in an early stage and then 
GNU/GCC has already been selected. But not all is lost - I realised that I may 
be able to get around this by expanding the PATH with the MinGW-w64/MSYS2 
specific directories. I have not tried that yet.

Though I am still interested in other solutions ;).

Regards,

Arjen





DISCLAIMER: This message is intended exclusively for the addressee(s) and may 
contain confidential and privileged information. If you are not the intended 
recipient please notify the sender immediately and destroy this message. 
Unauthorized use, disclosure or copying of this message is strictly prohibited. 
The foundation 'Stichting Deltares', which has its seat at Delft, The 
Netherlands, Commercial Registration Number 41146461, is not liable in any way 
whatsoever for consequences and/or damages resulting from the improper, 
incomplete and untimely dispatch, receipt and/or content of this e-mail.
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

[CMake] MinGW-w64/MSYS2 (or Cygwin) and NAG Fortran - how to combine?

[Arjen Markus]

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 NAG Fortran compiler is a 
very nice, strict, compiler that is available for both Windows and Linux (and 
possibly other platforms as well). I know in principle how to combine NAG 
Fortran with the GCC tools, so this part of the combination is not the problem.



The problem is rather this:

If I start a console with MinGW-w64/MSYS2 or Cygwin I get an environment where 
all the libraries that I want can be found, but that environment is identified 
by CMake as "MinGW" or "Cygwin", so that the NAG Fortran specific settings are 
ignored.



(I store them in a file MinGW-NAG-Fortran.cmake, in analogy with all the other 
such files - a file Windows-NAG-Fortran.cmake does do the job for the "bare" 
Windows platform.)



The NAG Fortran compiler is selected, just like I want, instead of the gfortran 
compiler, as I define FC to be "nagfor" and I have expanded the PATH to include 
all the stuff for NAG Fortran.



But the crucial part is that CMake uses the settings for the GNU compilers.



So: Is it possible to instruct CMake to use the NAG-Fortran specific settings 
and if so, how do I do that?



Regards,



Arjen



DISCLAIMER: This message is intended exclusively for the addressee(s) and may 
contain confidential and privileged information. If you are not the intended 
recipient please notify the sender immediately and destroy this message. 
Unauthorized use, disclosure or copying of this message is strictly prohibited. 
The foundation 'Stichting Deltares', which has its seat at Delft, The 
Netherlands, Commercial Registration Number 41146461, is not liable in any way 
whatsoever for consequences and/or damages resulting from the improper, 
incomplete and untimely dispatch, receipt and/or content of this e-mail.
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

[CMake] Patch for working with the NAG Fortran compiler

[Arjen Markus]

Hello,



I have been using the NAG Fortran compiler under Windows for the PLplot project 
(http://plplot.sf.net) and I found that I needed a small patch to have shared 
libraries (DLLs) built with it. I added a file "Windows-NAG-Fortran.cmake" to 
the Modules/Platform directory (CMake 3.4.3) that I derived from similar files 
for the NAG compiler for Linux and OSX. It looks like this:





set(CMAKE_Fortran_VERBOSE_FLAG "-Wl,-v") # Runs gcc under the hood.



set(CMAKE_SHARED_LIBRARY_CREATE_Fortran_FLAGS "-Wl,-shared")

set(CMAKE_Fortran_CREATE_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 information. If you are not the intended 
recipient please notify the sender immediately and destroy this message. 
Unauthorized use, disclosure or copying of this message is strictly prohibited. 
The foundation 'Stichting Deltares', which has its seat at Delft, The 
Netherlands, Commercial Registration Number 41146461, is not liable in any way 
whatsoever for consequences and/or damages resulting from the improper, 
incomplete and untimely dispatch, receipt and/or content of this e-mail.
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Cmake 3.5.0 and Fortran submodule cannot be built

[Arjen Markus]

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



> -Original Message-
> From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of olusegun
> ogunbade
> Sent: Wednesday, March 23, 2016 4:33 PM
> To: cmake@cmake.org
> Subject: [CMake] Cmake 3.5.0 and Fortran submodule cannot be built
>
>
> 
> From: olusegun ogunbade 
> Sent: Wednesday, March 23, 2016 2:59:07 PM
> To: cmake@cmake.org
> Subject: Cmake 3.5.0 and Fortran submodule cannot be built
>
> I was trying to build a Fortran project using Cmake-3.5.0. The project was 
> written
> with the fortran 08 submodule. The error I got is
>
> Error copying Fortran module "mod/function". Tried "mod/FUNCTION.mod" and
> "mod/function.mod".
>
> Does recent cmake support Fortran submodule?
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake
>

DISCLAIMER: This message is intended exclusively for the addressee(s) and may 
contain confidential and privileged information. If you are not the intended 
recipient please notify the sender immediately and destroy this message. 
Unauthorized use, disclosure or copying of this message is strictly prohibited. 
The foundation 'Stichting Deltares', which has its seat at Delft, The 
Netherlands, Commercial Registration Number 41146461, is not liable in any way 
whatsoever for consequences and/or damages resulting from the improper, 
incomplete and untimely dispatch, receipt and/or content of this e-mail.
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] FORTRAN name mangling

[Arjen Markus]

> 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 as far back as about five years ago, all 10 compilers surveyed by Ian 
> Chivers and Jane Sleightholme supported C interoperability.  And now there 
> are at least four compilers that even support the _additional_ C 
> interoperability features in the draft Fortran 2015 standard: the IBM, Cray, 
> Intel, and GNU compilers.  C interoperability appears to be one of the first 
> things every compiler team tackles from a new standard.

> Anyone with access to ACM Fortran Forum will benefit from consulting the 
> standards-support survey that Ian and Jane have published in almost every 
> issue for roughly a decade or so.  Standards support in  Fortran compilers is 
> not quite where it needs to be, but it's much better than it was even just a 
> couple of years ago. Great strides have been taken.

Just to chime in here, in the PLplot project (plplot.sf.net) we are currently 
reimplementing the Fortran interface to the plotting routines that have been 
implemented in C. The previous version took advantage of all Fortran 90/95 
features, such as function overloading and assumed-shape arrays to avoid the 
extra arguments needed to tell the plotting routines how many elements there 
are. This required quite a lot of C code, as the naming conventions/name 
mangling had to be handled on the C side.

The new set-up however uses the ISO_C_BINDING features to the fullest extent. 
The benefits of this new set-up are plenty:

- We can support single and double precision versions of the routines in one 
library, whereas before we had to rely on the Fortran programs using the same 
precision as the C library. This could have been done with just the Fortran 
90/95 features too - just a matter of progressive insight.

- Almost all C code has been eliminated as matching the names of the routines 
can now be done on the Fortran side. The advantage of that is that the Fortran 
compiler is completely responsible for this, rather than a set of confusing C 
macros the details of which depend on the Fortran compiler.

Of course, this means that you have to have the ability to adjust the Fortran 
code, but for a given library, you could simply write a Fortran interface layer 
that uses the ISO_C_BINDING features instead of a C one.

Regards,

Arjen
DISCLAIMER: This message is intended exclusively for the addressee(s) and may 
contain confidential and privileged information. If you are not the intended 
recipient please notify the sender immediately and destroy this message. 
Unauthorized use, disclosure or copying of this message is strictly prohibited. 
The foundation 'Stichting Deltares', which has its seat at Delft, The 
Netherlands, Commercial Registration Number 41146461, is not liable in any way 
whatsoever for consequences and/or damages resulting from the improper, 
incomplete and untimely dispatch, receipt and/or content of this e-mail.
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Problem with Fortran conditionals

[Arjen Markus]

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 check the name of the 
compiler once it has been found and if it is not the one you support, issue an 
informative message.

Regards,

Arjen


> -Original Message-
> From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Nikolaus Rath
> Sent: Friday, May 01, 2015 12:05 AM
> To: CMake
> Subject: [CMake] Problem with Fortran conditionals
>
> Hello,
>
> I am in the process of converting a bigger project from pure GNU Make to 
> CMake -
> mostly because managing dependencies for the Fortran sources has become too
> painful.
>
> Things seem to be mostly working, but I'm hitting one problem. When trying to 
> run
> the (CMake-generated) Makefile, it fails with:
>
> $ make VERBOSE=1
> [...]
> make[2]: Entering directory `/home/nrath/Q2D/LamyRidge/src/model/build'
> /home/nrath/.local/stow/cmake/bin/cmake -E cmake_copy_f90_mod
> dagmg_allroutines CMakeFiles/LR_model.dir/dagmg_allroutines.mod.stamp Intel
> /home/nrath/.local/stow/cmake/bin/cmake -E cmake_copy_f90_mod dagmg_mem
> CMakeFiles/LR_model.dir/dagmg_mem.mod.stamp Intel
> /home/nrath/.local/stow/cmake/bin/cmake -E cmake_copy_f90_mod dagmg_pardiso
> CMakeFiles/LR_model.dir/dagmg_pardiso.mod.stamp Intel Error copying Fortran
> module "dagmg_pardiso".  Tried "DAGMG_PARDISO.mod"
> and "dagmg_pardiso.mod".
> make[2]: ***
> [CMakeFiles/LR_model.dir/home/nrath/Q2D/LamyRidge/src/comm/agmg-
> seq/dagmg.f90.o.provides.build]
> Error 1
> make[2]: Leaving directory `/home/nrath/Q2D/LamyRidge/src/model/build'
> make[1]: *** [CMakeFiles/LR_model.dir/all] Error 2
> make[1]: Leaving directory `/home/nrath/Q2D/LamyRidge/src/model/build'
> make: *** [all] Error 2
>
> I am not sure why CMake is trying to copy module files around, but when I 
> looked at
> the file that provides the "dagmg_pardiso" module, I found this code:
>
> !DEC$ IF DEFINED(_MKL_)
>   MODULE dagmg_PARDISO
> USE dagmg_PARDISSO
> INTERFACE
>  [...]
> END INTERFACE
>   END MODULE dagmg_PARDISO
> !DEC$ ENDIF
> !---
> !DEC$ IF .NOT. DEFINED(_MKL_)
> SUBROUTINE PARDISO( PT, MAXFCT, MNUM, MTYPE, PHASE, N, A, IA, JA
> &
>  , PERM, NRHS, IPARM, MSGLVL, B, X, ERROR ) [...]
>  END SUBROUTINE PARDISO
> !DEC$ ENDIF
>
> I do not define __MKL__. Is it possible that the CMake dependency parser 
> doesn't
> understand this way of defining conditionals, and thus looks for a module 
> that does
> not exist?
>
> If so, what would be the best way to work around this?
>
> (The code is from a third-party library, so unfortunately I cannot easily 
> change it).
>
>
> Best,
> -Nikolaus
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake

DISCLAIMER: This message is intended exclusively for the addressee(s) and may 
contain confidential and privileged information. If you are not the intended 
recipient please notify the sender immediately and destroy this message. 
Unauthorized use, disclosure or copying of this message is strictly prohibited. 
The foundation 'Stichting Deltares', which has its seat at Delft, The 
Netherlands, Commercial Registration Number 41146461, is not liable in any way 
whatsoever for consequences and/or damages resulting from the improper, 
incomplete and untimely dispatch, receipt and/or content of this e-mail.
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Unexpected use of "ld" on Windows

[Arjen Markus]

Hello Andreas,



Hm, that has crossed my mind - maybe I should simply rename that particular 
directory. It still seems odd though that this occurs. Anyway, thanks for the 
suggestion. This is simple enough to try ;).



Regards,



Arjen



From: Andreas Pakulat [mailto:ap...@gmx.de]
Sent: 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 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 with the code). The second part, which is supposed to build a C library 
that can be called from Fortran, presents a more serious problem: for some 
reason CMake picks parts of another toolchain to build this:

The Makefile contains these lines to compile the sources:
cd D:\netcdf\netcdf-build-fortran\libsrc
C:\PROGRA~2\MICROS~3.0\VC\bin\amd64\cl.exe  @<<
 /nologo $(C_FLAGS) $(C_DEFINES) /FoCMakeFiles\ncfortran.dir\fort-attio.c.obj 
/FdD:\netcdf\netcdf-build-fortran\libsrc\ncfortran.pdb -c 
D:\netcdf\netcdf-fortran-4.4.1\libsrc\fort-attio.c

But to build the library it contains:

libsrc\ncfortran.dll: d:\netcdf\netcdf-build\liblib\netcdf.lib
libsrc\ncfortran.dll: libsrc\CMakeFiles\ncfortran.dir\objects1.rsp
@$(CMAKE_COMMAND) -E cmake_echo_color --switch=$(COLOR) --red --bold 
"Linking C shared library ncfortran.dll"
cd D:\netcdf\netcdf-build-fortran\libsrc
d:\CMake2.8.10.2\bin\cmake.exe -E vs_link_dll 
C:\PROGRA~2\HASKEL~1\201320~1.0\mingw\bin\ld.exe /nologo 
@CMakeFiles\ncfortran.dir\objects1.rsp @<<
 /out:ncfortran.dll /implib:ncfortran.lib 
/pdb:D:\netcdf\netcdf-build-fortran\libsrc\ncfortran.pdb /dll /version:0.0 
/STACK:1000 /INCREMENTAL:YES /machine:x64  /debug 
d:\netcdf\netcdf-build\liblib\netcdf.lib kernel32.lib user32.lib gdi32.lib 
winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib 
advapi32.lib
<<

As you can see, it has picked up a linker (ld.exe) belonging to a completely 
different compiler/package for this step.

I have no idea where this is coming from and how to fix this. Does anyone have 
any suggestions?

Seeing the path to that ld.exe I'm reminded of a problem a colleague recently 
had. He has Haskell installed on his system and either haskell itself or some 
haskell library came with mingw and his PATH ended up including the bin dir of 
that mingw installation. Even if that entry is after the VS compiler CMake 
apparently chooses to pick up the mingw toolchain (or parts of it), so one has 
to make sure that there's no MinGW compiler or linker or other part of the 
toolchain in any of the directories in PATH. At least thats how he resolved the 
issue.

Andreas
DISCLAIMER: This message is intended exclusively for the addressee(s) and may 
contain confidential and privileged information. If you are not the intended 
recipient please notify the sender immediately and destroy this message. 
Unauthorized use, disclosure or copying of this message is strictly prohibited. 
The foundation 'Stichting Deltares', which has its seat at Delft, The 
Netherlands, Commercial Registration Number 41146461, is not liable in any way 
whatsoever for consequences and/or damages resulting from the improper, 
incomplete and untimely dispatch, receipt and/or content of this e-mail.
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

[CMake] Unexpected use of "ld" on Windows

[Arjen Markus]

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 with the code). The second part, which is supposed to build a C library 
that can be called from Fortran, presents a more serious problem: for some 
reason CMake picks parts of another toolchain to build this:

The Makefile contains these lines to compile the sources:
cd D:\netcdf\netcdf-build-fortran\libsrc
C:\PROGRA~2\MICROS~3.0\VC\bin\amd64\cl.exe  @<<
 /nologo $(C_FLAGS) $(C_DEFINES) /FoCMakeFiles\ncfortran.dir\fort-attio.c.obj 
/FdD:\netcdf\netcdf-build-fortran\libsrc\ncfortran.pdb -c 
D:\netcdf\netcdf-fortran-4.4.1\libsrc\fort-attio.c

But to build the library it contains:

libsrc\ncfortran.dll: d:\netcdf\netcdf-build\liblib\netcdf.lib
libsrc\ncfortran.dll: libsrc\CMakeFiles\ncfortran.dir\objects1.rsp
@$(CMAKE_COMMAND) -E cmake_echo_color --switch=$(COLOR) --red --bold 
"Linking C shared library ncfortran.dll"
cd D:\netcdf\netcdf-build-fortran\libsrc
d:\CMake2.8.10.2\bin\cmake.exe -E vs_link_dll 
C:\PROGRA~2\HASKEL~1\201320~1.0\mingw\bin\ld.exe /nologo 
@CMakeFiles\ncfortran.dir\objects1.rsp @<<
 /out:ncfortran.dll /implib:ncfortran.lib 
/pdb:D:\netcdf\netcdf-build-fortran\libsrc\ncfortran.pdb /dll /version:0.0 
/STACK:1000 /INCREMENTAL:YES /machine:x64  /debug 
d:\netcdf\netcdf-build\liblib\netcdf.lib kernel32.lib user32.lib gdi32.lib 
winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib 
advapi32.lib
<<

As you can see, it has picked up a linker (ld.exe) belonging to a completely 
different compiler/package for this step.

I have no idea where this is coming from and how to fix this. Does anyone have 
any suggestions?

Regards,

Arjen


DISCLAIMER: This message is intended exclusively for the addressee(s) and may 
contain confidential and privileged information. If you are not the intended 
recipient please notify the sender immediately and destroy this message. 
Unauthorized use, disclosure or copying of this message is strictly prohibited. 
The foundation 'Stichting Deltares', which has its seat at Delft, The 
Netherlands, Commercial Registration Number 41146461, is not liable in any way 
whatsoever for consequences and/or damages resulting from the improper, 
incomplete and untimely dispatch, receipt and/or content of this e-mail.
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] cmake + vc12

[Arjen Markus]

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
>
> Is there a way to see the executed command when using "NMake Makefiles"?
> I would like to see the "cl /c /flag1 /flag2 file.cpp" etc...
>
> -- lode
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake
>

DISCLAIMER: This message is intended exclusively for the addressee(s) and may 
contain confidential and privileged information. If you are not the intended 
recipient please notify the sender immediately and destroy this message. 
Unauthorized use, disclosure or copying of this message is strictly prohibited. 
The foundation 'Stichting Deltares', which has its seat at Delft, The 
Netherlands, Commercial Registration Number 41146461, is not liable in any way 
whatsoever for consequences and/or damages resulting from the improper, 
incomplete and untimely dispatch, receipt and/or content of this e-mail.
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Mixed Fortran and C sources with Visual Studio 10

[Arjen Markus]

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 - that is, use plain 
makefiles instead
of Visual Studio to build the project.

Regards,

Arjen

> -Original Message-
> From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf
> Of Brian Wainscott
> Sent: Tuesday, October 22, 2013 12:50 AM
> To: cmake@cmake.org
> Subject: [CMake] Mixed Fortran and C sources with Visual Studio 10
>
> I'm trying to convert a large(ish) project to cmake.  Everything works fine 
> in Linux, but
> I'm having problems on Windows.
>
> Specifically, we have both C and Fortran sources mixed together in a single 
> directory.
> Cmake is producing an vcxproj file and none of the Fortran code gets compiled.
>
> I've been informed that I probably need two project files, one for C and one 
> for
> Fortran (vfproj).  OK -- so why does cmake not then produce two project files?
> Am I missing a flag or setting somewhere?
>
> As a concrete test, I tried this for a CMakeLists.txt file:
>
> enable_language(Fortran)
> enable_language(C)
> add_executable(tst tst.F cfunc.c)
>
> with a trivial Fortran main and C subroutine.  It builds fine in Linux, but 
> not on
> Windows.
>
> Everything works so well in Linux that I have a hard time believing that 
> anything
> complex should be required for Windows -- I must be missing something simple 
> but
> can't find any information on what it might be.
>
> Any suggestions on how to get this to work?
>
> I'm using cmake 2.8.11.2 with VS 10 and my Fortran compiler is Intel Composer 
> XE
> 2013.
>
> Thanks,
>
> Brian
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/listinfo/cmake

DISCLAIMER: This message is intended exclusively for the addressee(s) and may 
contain confidential and privileged information. If you are not the intended 
recipient please notify the sender immediately and destroy this message. 
Unauthorized use, disclosure or copying of this message is strictly prohibited. 
The foundation 'Stichting Deltares', which has its seat at Delft, The 
Netherlands, Commercial Registration Number 41146461, is not liable in any way 
whatsoever for consequences and/or damages resulting from the improper, 
incomplete and untimely dispatch, receipt and/or content of this e-mail.
--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Fortran MinGW on Windows

[Arjen Markus]

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 any such feature and a quick survey of 
the
documentation (and even some of module files that come 
with

CMake) did not reveal anything either.

For several years now, the trend has been to build dynamic
libraries, rather than static ones. I guess there are pros
and cons for both. I have a preference for static 
libraries

myself too, but sometimes that is simply not possible.

Regards,

Arjen



DISCLAIMER: This message is intended exclusively for the addressee(s) and may 
contain confidential and privileged information. If you are not the intended 
recipient please notify the sender immediately and destroy this message. 
Unauthorized use, disclosure or copying of this message is strictly prohibited.
The foundation 'Stichting Deltares', which has its seat at Delft, The 
Netherlands, Commercial Registration Number 41146461, is not liable in any way 
whatsoever for consequences and/or damages resulting from the improper, 
incomplete and untimely dispatch, receipt and/or content of this e-mail.




--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Fortran MinGW on Windows

[Arjen Markus]

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
libraries are taken into account. (If you were to use
gfortran as the interface to the linker, then you would
need to tell it what C++ runtime libraries are required.)

A way out would be to build these additional libraries as
DLLs (shared objects), as then the language-specific
linker can be used.

Regards,

Arjen

On Fri, 31 May 2013 07:51:34 +
 "Leek, Jim"  wrote:
Hi, I recently rebuilt an old build system with cmake. 
It works well on Linux, but part of the idea of using 
cmake was to make it more portable.  Now I'm working on 
the Windows port, but I'm having issues with the Fortran 
libraries.  The program itself is C++, but it has a 
number of optional third party libraries, a few of which 
are written in Fortran.  The weird thing is, when I do 
the final link, I get a bunch of "undefined references" 
for stuff that's in the gfortran library.



...


Thanks,
Jim





DISCLAIMER: This message is intended exclusively for the addressee(s) and may 
contain confidential and privileged information. If you are not the intended 
recipient please notify the sender immediately and destroy this message. 
Unauthorized use, disclosure or copying of this message is strictly prohibited.
The foundation 'Stichting Deltares', which has its seat at Delft, The 
Netherlands, Commercial Registration Number 41146461, is not liable in any way 
whatsoever for consequences and/or damages resulting from the improper, 
incomplete and untimely dispatch, receipt and/or content of this e-mail.




--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Problem with "configured" file under Cygwin/Windows 7

[Arjen Markus]

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 problems that turn out to be caused by a 
strange

permission set on "configured" files.

Using one of these projects I have created an almost 
minimal project
to demonstrate the problem. If you configure it via CMake 
under
Windows 7, the file "gnulliver.h" has "special 
permissions". I have
no clue what that means or how it arises, but the 
consequence is that
a program can not open it. Not even a program running 
under

Administrator rights.

Oddly enough, you can change the permissions from Windows 
Explorer by
opening the permissions dialogue and giving the user full 
access.


I have tried to reproduce it in an even smaller project 
than the one
attached, that is: just a CMakeListst.txt file and 
gnulliver.h.in,
but that worked without this problem. So it seems a 
combination of

steps is required to trigger this issue.

Can anyone shed some light on this? It makes it impossible 
to use
Cygwin in combination with Windows 7 (I have not tried on 
other
platforms, quite possibly it is specific to this 
combination.)


Regards,

Arjen




DISCLAIMER: This message is intended exclusively for the addressee(s) and may 
contain confidential and privileged information. If you are not the intended 
recipient please notify the sender immediately and destroy this message. 
Unauthorized use, disclosure or copying of this message is strictly prohibited.
The foundation 'Stichting Deltares', which has its seat at Delft, The 
Netherlands, Commercial Registration Number 41146461, is not liable in any way 
whatsoever for consequences and/or damages resulting from the improper, 
incomplete and untimely dispatch, receipt and/or content of this e-mail.




problem-cygwin.tgz
Description: Binary data
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] MSYS and Intel Fortran/MSVC/C++

[Arjen Markus]

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!

Within the MSVC-en abled MSYS shell I explicitly set
the TMP variable to "e:\\temp" and then I run the
commands:

   CMake -G "NMake Makefiles" ../src
   nmake

Both commands complete successfully - so it is indeed the
interference of MSYS with the path pointed to by the
environment variable TMP.

Regards,

Arjen



DISCLAIMER: This message is intended exclusively for the addressee(s) and may 
contain confidential and privileged information. If you are not the intended 
recipient please notify the sender immediately and destroy this message. 
Unauthorized use, disclosure or copying of this message is strictly prohibited.
The foundation 'Stichting Deltares', which has its seat at Delft, The 
Netherlands, Commercial Registration Number 41146461, is not liable in any way 
whatsoever for consequences and/or damages resulting from the improper, 
incomplete and untimely dispatch, receipt and/or content of this e-mail.




--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] MSYS and Intel Fortran/MSVC/C++

[Arjen Markus]

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 CMake with the "NMake Makefiles" generator from
an ordinary DOS-shell (enabled for MSVC), it all works 
fine.


When I use the MSYS shell (enabled for MSVC) to build the
tutorial via nmake, the compiler complains about the file
"e:" again. (I can not find that substring anywhere in the
gnerated files though.)

Examining the environment variable TMP reveals something
odd:
- In the DOS shell it has the value "e:\temp"
- In the MSYS shell it has the value /tmp, but it is
  actually the directory e:\temp (as I see the same
  files via "ls /tmp" as I see in the directory 
"e:\temp".


I suspect MSYS is providing some translations, which
obscure any solution. That typed, I realised that might
actually be the solution. Indeed:

When I set the environment variable TMP to "e:\\temp",
nmake and MSVC are happy with the situation and do compile
and link the sample project.

Now I will try the following:
MSYS with this adapted TMP variable and run CMake with
NMake Makefiles.

More to come.

Regards,

Arjen



DISCLAIMER: This message is intended exclusively for the addressee(s) and may 
contain confidential and privileged information. If you are not the intended 
recipient please notify the sender immediately and destroy this message. 
Unauthorized use, disclosure or copying of this message is strictly prohibited.
The foundation 'Stichting Deltares', which has its seat at Delft, The 
Netherlands, Commercial Registration Number 41146461, is not liable in any way 
whatsoever for consequences and/or damages resulting from the improper, 
incomplete and untimely dispatch, receipt and/or content of this e-mail.




--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] What is the proper cross-platform way to link the Python library?

[Arjen Markus]

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 cause bad results.


Have a look at the SelectLibraryConfigurations module, 
it does what you did above and in 2.8.10.* also properly 
handles lists and the case where both values are the 
same.


And from what I see (at least in the current code) 
FindPythonLibs already does exaclty that. So which CMake 
version is Arjen using? And if it is the most recent one, 
can you get him to debug why FindPythonLibs doesn't work 
as expected?




I am using CMake version 2.8.10.2 (but IIRC the problem
also occurred with 2.8.7).

My interpretation of the problem at the moment is:
- The pyconfig.h header file introduces a dependency of
  a library "python27_d.lib" directly in the object file
  - this is the consequence of the pragma.
- There is no such library in the Python installation,
  so the linker will always complain that this library
  is missing - quite independent of what CMake does.
  (In fact, the generated Makefiles and associated files
  do not refer to this library at all)

I tried copying the ordinary library to "python27_d.lib"
but that led to several unresolved symbols. So there is
more going on than just name mangling.

Regards,

Arjen



DISCLAIMER: This message is intended exclusively for the addressee(s) and may 
contain confidential and privileged information. If you are not the intended 
recipient please notify the sender immediately and destroy this message. 
Unauthorized use, disclosure or copying of this message is strictly prohibited.
The foundation 'Stichting Deltares', which has its seat at Delft, The 
Netherlands, Commercial Registration Number 41146461, is not liable in any way 
whatsoever for consequences and/or damages resulting from the improper, 
incomplete and untimely dispatch, receipt and/or content of this e-mail.




--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] MSYS and Intel Fortran/MSVC/C++

[Arjen Markus]

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. 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 "/" and "-" as the start characters for
   a command-line option.
- MSYS uses the forward slash to separate path 
components

   and in this particular case both forward and backward
   slashes occur.
- cl is complaining about a file called "e:", not 
"e:/temp"


(The DOS shell can use both forward and backward slashes
by the way as a path separator, but it is not consistent
in this - path completion only works for backward 
slashes

for instance)

This means that the MSYS shell can not be readily used
to generate the makefiles. An alternative I can imagine 
is
that I use the DOS shell and make the MinGW/MSYS 
utilities available via

the path.



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?


Some other things you can try:
add --debug-trycompile to the cmake command line.  This 
will leave the files in CMakeFiles/CMakeTmp.  You can 
then cd into there and run nmake from the command line 
and look at the makefiles.  I don't think CMake is doing 
the mixed path stuff.  I think this is a bad interaction 
with nmake and msys.



-Bill
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html


Please keep messages on-topic and check the CMake FAQ 
at: http://www.cmake.org/Wiki/CMake_FAQ


Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake






DISCLAIMER: This message is intended exclusively for the addressee(s) and may 
contain confidential and privileged information. If you are not the intended 
recipient please notify the sender immediately and destroy this message. 
Unauthorized use, disclosure or copying of this message is strictly prohibited.
The foundation 'Stichting Deltares', which has its seat at Delft, The 
Netherlands, Commercial Registration Number 41146461, is not liable in any way 
whatsoever for consequences and/or damages resulting from the improper, 
incomplete and untimely dispatch, receipt and/or content of this e-mail.




--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] MSYS and Intel Fortran/MSVC/C++

[Arjen Markus]

Hi Bill, Alan,

here is some further information:

As the MSYS environment/shell is started with a batch file
that takes care of several options and using the set-up
batch file needed for MSVC/C++ can not be used in the
default MSYS shell, I have adapted the stock batch file 
(msys.bat in c:\mingw\msys\1.0) as follows:


rem At the start
rem Initialise the MSVC/C++ environment
call "c:\program files\MicroSoft Visual Studio 
10.0\VC\vcvarsall.bat" x86


rem Rest of the original batch file follows
...

This sets all the environment variables required for 
MSVC/C++ and then starts

the 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

compilers.

My guess is that the use of the forward slash is messing
up the argument parsing:

- cl uses both "/" and "-" as the start characters for
  a command-line option.
- MSYS uses the forward slash to separate path 
components

  and in this particular case both forward and backward
  slashes occur.
- cl is complaining about a file called "e:", not 
"e:/temp"


(The DOS shell can use both forward and backward slashes
by the way as a path separator, but it is not consistent
in this - path completion only works for backward 
slashes

for instance)

This means that the MSYS shell can not be readily used
to generate the makefiles. An alternative I can imagine 
is
that I use the DOS shell and make the MinGW/MSYS 
utilities available via the path.






DISCLAIMER: This message is intended exclusively for the addressee(s) and may 
contain confidential and privileged information. If you are not the intended 
recipient please notify the sender immediately and destroy this message. 
Unauthorized use, disclosure or copying of this message is strictly prohibited.
The foundation 'Stichting Deltares', which has its seat at Delft, The 
Netherlands, Commercial Registration Number 41146461, is not liable in any way 
whatsoever for consequences and/or damages resulting from the improper, 
incomplete and untimely dispatch, receipt and/or content of this e-mail.




--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] MSYS and Intel Fortran/MSVC/C++

[Arjen Markus]

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 "/" and "-" as the start characters for
  a command-line option.
- MSYS uses the forward slash to separate path components
  and in this particular case both forward and backward
  slashes occur.
- cl is complaining about a file called "e:", not 
"e:/temp"


(The DOS shell can use both forward and backward slashes
by the way as a path separator, but it is not consistent
in this - path completion only works for backward slashes
for instance)

This means that the MSYS shell can not be readily used
to generate the makefiles. An alternative I can imagine is
that I use the DOS shell and make the MinGW/MSYS utilities 
available via the path.


Regards,

Arjen

On Thu, 03 Jan 2013 17:10:09 -0500
 Bill Hoffman  wrote:

On 1/3/2013 4:37 PM, Alan W. Irwin wrote:

...

Recalling that CMake-2.8.10 had a lot of changes to
language support is this a regression for cmake-2.8.10.2 
or do you

get the same issue for earlier cmake versions?


This does not seem to have anything to do with CMake 
versions.  Here is the error:



 	"c:\PROGRA~1\Microsoft Visual Studio 
10.0\VC\bin\cl.exe"

  @e:/Temp\nm591.tmp
  Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 
16.00.30319.01 for

  80x86
  Copyright (C) Microsoft Corporation.  All rights 
reserved.

  cl : Command line error D8022 : cannot open 'e:'
  NMAKE : fatal error U1077: '"c:\PROGRA~1\Microsoft 
Visual Studio

  10.0\VC\bin\cl.exe"' : return code '0x2

Looks like cl is using your e:/Temp for temp files. 
Maybe you have a bad env var.  You have to make sure you 
are running CMake from a shell where the command line 
tools for cl are configured correctly.  Do you have an e: 
drive on the machine?  Is there an e:/Temp?






DISCLAIMER: This message is intended exclusively for the addressee(s) and may 
contain confidential and privileged information. If you are not the intended 
recipient please notify the sender immediately and destroy this message. 
Unauthorized use, disclosure or copying of this message is strictly prohibited.
The foundation 'Stichting Deltares', which has its seat at Delft, The 
Netherlands, Commercial Registration Number 41146461, is not liable in any way 
whatsoever for consequences and/or damages resulting from the improper, 
incomplete and untimely dispatch, receipt and/or content of this e-mail.




--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] MSYS and Intel Fortran/MSVC/C++

[Arjen Markus]

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 attached output files.

Regards,

Arjen
 




DISCLAIMER: This message is intended exclusively for the addressee(s) and may 
contain confidential and privileged information. If you are not the intended 
recipient please notify the sender immediately and destroy this message. 
Unauthorized use, disclosure or copying of this message is strictly prohibited.
The foundation 'Stichting Deltares', which has its seat at Delft, The 
Netherlands, Commercial Registration Number 41146461, is not liable in any way 
whatsoever for consequences and/or damages resulting from the improper, 
incomplete and untimely dispatch, receipt and/or content of this e-mail.




cmake.err
Description: Binary data


cmake.out
Description: Binary data
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] MSYS and Intel Fortran/MSVC/C++

[Arjen Markus]

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 exclusively for the addressee(s) and may 
contain confidential and privileged information. If you are not the intended 
recipient please notify the sender immediately and destroy this message. 
Unauthorized use, disclosure or copying of this message is strictly prohibited.
The foundation 'Stichting Deltares', which has its seat at Delft, The 
Netherlands, Commercial Registration Number 41146461, is not liable in any way 
whatsoever for consequences and/or damages resulting from the improper, 
incomplete and untimely dispatch, receipt and/or content of this e-mail.




cmake.err
Description: Binary data


cmake.out
Description: Binary data
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] MSYS and Intel Fortran/MSVC/C++

[Arjen Markus]

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 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 for that.

I have to specify the compilers explicitly, because 
otherwise

the GNU compiler suite is chosen.

Unfortunately, I run into a problem with the archive 
program.
Whatever I use for this (via CMAKE_AR), CMake is not 
satisfied.
Any clues as to what archive program I am supposed to 
use?


An alternative might be to build the programs via 
gcc/gfortran
within MSYS, so that everything is ready and then 
replace the
programs by their Intel/MicroSoft versions before 
actually
running the tests, but that seems a trifle tricky and at 
the

very least cumbersome.

Regards,

Arjen



DISCLAIMER: This message is intended exclusively for the 
addressee(s) and may contain confidential and privileged 
information. If you are not the intended recipient please 
notify the sender immediately and destroy this message. 
Unauthorized use, disclosure or copying of this message 
is strictly prohibited.
The foundation 'Stichting Deltares', which has its seat 
at Delft, The Netherlands, Commercial Registration Number 
41146461, is not liable in any way whatsoever for 
consequences and/or damages resulting from the improper, 
incomplete and untimely dispatch, receipt and/or content 
of this e-mail.





--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html


Please keep messages on-topic and check the CMake FAQ 
at: http://www.cmake.org/Wiki/CMake_FAQ


Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake






DISCLAIMER: This message is intended exclusively for the addressee(s) and may 
contain confidential and privileged information. If you are not the intended 
recipient please notify the sender immediately and destroy this message. 
Unauthorized use, disclosure or copying of this message is strictly prohibited.
The foundation 'Stichting Deltares', which has its seat at Delft, The 
Netherlands, Commercial Registration Number 41146461, is not liable in any way 
whatsoever for consequences and/or damages resulting from the improper, 
incomplete and untimely dispatch, receipt and/or content of this e-mail.




--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] MSYS and Intel Fortran/MSVC/C++

[Arjen Markus]

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 for that.

I have to specify the compilers explicitly, because otherwise
the GNU compiler suite is chosen.

Unfortunately, I run into a problem with the archive program.
Whatever I use for this (via CMAKE_AR), CMake is not satisfied.
Any clues as to what archive program I am supposed to use?

An alternative might be to build the programs via gcc/gfortran
within MSYS, so that everything is ready and then replace the
programs by their Intel/MicroSoft versions before actually
running the tests, but that seems a trifle tricky and at the
very least cumbersome.

Regards,

Arjen



DISCLAIMER: This message is intended exclusively for the addressee(s) and may 
contain confidential and privileged information. If you are not the intended 
recipient please notify the sender immediately and destroy this message. 
Unauthorized use, disclosure or copying of this message is strictly prohibited.
The foundation 'Stichting Deltares', which has its seat at Delft, The 
Netherlands, Commercial Registration Number 41146461, is not liable in any way 
whatsoever for consequences and/or damages resulting from the improper, 
incomplete and untimely dispatch, receipt and/or content of this e-mail.




--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] #include and fortran dependencies

[Arjen Markus]

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 ubiquitous but still non-standard) support
of these C preprocessor commands.

Regards,

Arjen

On Tue, 28 Feb 2012 13:28:19 -0500
 Brad King  wrote:

On 2/28/2012 11:06 AM, Dirk vanMeeuwen wrote:

#include "fpp-Windows-definition.inc"
MODULE MSG
...
END MODULE

However, when this module MSG is used, the project build 
order
> generated by CMake is not correct (see attached small 
example).


Fortran dependencies are supported, and the Intel Fortran 
12 compiler

is expected to work with the NMake Makefiles generator.

I was able to reproduce the problem.  If I remove the 
#if logic from
the .inc file then it works.  I think this may be a bug 
in the
Source/cmDependsFortran* files of CMake.  It is not 
handling the #if
logic correctly and tricks itself into thinking that all 
the code
after the #include line is being preprocessed out as if 
in "#if 0".

That's why the order of the lines affects the results.

I don't have time to investigate this myself but if 
anyone is
interested then take a look at 
Source/cmDependsFortranParser.y
and Source/cmDependsFortran.cxx for use of the _RuleIf, 
_RuleElse,

and similar functions.

-Brad
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html


Please keep messages on-topic and check the CMake FAQ 
at: http://www.cmake.org/Wiki/CMake_FAQ


Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake






DISCLAIMER: This message is intended exclusively for the addressee(s) and may 
contain confidential and privileged information. If you are not the intended 
recipient please notify the sender immediately and destroy this message. 
Unauthorized use, disclosure or copying of this message is strictly prohibited.
The foundation 'Stichting Deltares', which has its seat at Delft, The 
Netherlands, Commercial Registration Number 41146461, is not liable in any way 
whatsoever for consequences and/or damages resulting from the improper, 
incomplete and untimely dispatch, receipt and/or content of this e-mail.




--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] C/CXX/Fortran Compiler not found.

[Arjen Markus]

Hi Kedar,

strange, I use both the gcc/gfortran combination and the MSVC/Ifort 
combination with CMake and I have no problems such as you describe.

Well, at least it is working for you now.

Regards,

Arjen

On 2012-01-11 17:06, Kedar Moharana wrote:

Dear Arjen,
   Just by googling I found a 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 clean directory,
as CMake keeps track of previous builds and build attempts
via all kinds of files in that directory. They may interfere
with the proper operation.

Regards,

Arjen

On Wed, 11 Jan 2012 12:28:25 +0100
 Kedar Moharana mailto:kedar.mohar...@ugent.be>> wrote:

Dear Arjen,
 Thank you very much for the reply.
Indeed, gcc command is not working on windows command prompt.

As you mentioned, I tried to set the path with
"path=c:\MinGW\bin;%PATH%"
command.
Now gcc is working.

when I tried to build with CMAKE, it can detect the Fortran
compiler; but C
and CXX is not detected yet.




DISCLAIMER: This message is intended exclusively for the
addressee(s) and may contain confidential and privileged
information. If you are not the intended recipient please notify the
sender immediately and destroy this message. Unauthorized use,
disclosure or copying of this message is strictly prohibited.
The foundation 'Stichting Deltares', which has its seat at Delft,
The Netherlands, Commercial Registration Number 41146461, is not
liable in any way whatsoever for consequences and/or damages
resulting from the improper, incomplete and untimely dispatch,
receipt and/or content of this e-mail.







--
**
Kedar Moharana
Research Scholar
Laboratory for Protein Biochemistry & Biomolecular Engineering (LProBE)
Ghent University, 
9000 Ghent, Belgium

**





DISCLAIMER: This message is intended exclusively for the addressee(s) and may 
contain confidential and privileged information. If you are not the intended 
recipient please notify the sender immediately and destroy this message. 
Unauthorized use, disclosure or copying of this message is strictly prohibited.
The foundation 'Stichting Deltares', which has its seat at Delft, The 
Netherlands, Commercial Registration Number 41146461, is not liable in any way 
whatsoever for consequences and/or damages resulting from the improper, 
incomplete and untimely dispatch, receipt and/or content of this e-mail.




--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] C/CXX/Fortran Compiler not found.

[Arjen Markus]

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 clean 
directory,

as CMake keeps track of previous builds and build attempts
via all kinds of files in that directory. They may 
interfere

with the proper operation.

Regards,

Arjen
On Wed, 11 Jan 2012 12:28:25 +0100
 Kedar Moharana  wrote:

Dear Arjen,
 Thank you very much for the reply.
Indeed, gcc command is not working on windows command 
prompt.


As you mentioned, I tried to set the path with 
"path=c:\MinGW\bin;%PATH%"

command.
Now gcc is working.

when I tried to build with CMAKE, it can detect the 
Fortran compiler; but C

and CXX is not detected yet.





DISCLAIMER: This message is intended exclusively for the addressee(s) and may 
contain confidential and privileged information. If you are not the intended 
recipient please notify the sender immediately and destroy this message. 
Unauthorized use, disclosure or copying of this message is strictly prohibited.
The foundation 'Stichting Deltares', which has its seat at Delft, The 
Netherlands, Commercial Registration Number 41146461, is not liable in any way 
whatsoever for consequences and/or damages resulting from the improper, 
incomplete and untimely dispatch, receipt and/or content of this e-mail.




--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] C/CXX/Fortran Compiler not found.

[Arjen Markus]

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.

CMake will be able to find the compiler from a DOS-box
where gcc works.

Regards,

Arjen


On Wed, 11 Jan 2012 11:55:32 +0100
 Kedar Moharana  wrote:

Dear all,
 I am trying to build from a source code using CMAKE on 
Windows 7. I have
no prior experience in building from source code, so I 
need your help in

this regard.

The application requires following external dependencies 
with versions

mentioned or more advanced versions:

  - CMake-2.6 (build system)
  - Qt-4.4 (UI framework)
  - gcc-4.3 (C, C++ and Fortran compilers)

So I installed CMake 2.8.7 in C:\Program files\CMake 2.8 
directory,
Qt-library-4.8.0 in the C:\Qt directory. For gcc-4.3, 
when I googled, I
found I can install MinGW and so I installed the latest 
version in C:\MinGW

directory.

When I am trying to build with CMAKE command, I am 
getting following error

message:


The C compiler identification is unknown

The CXX compiler identification is unknown

The Fortran compiler identification is unknown

Check for working C compiler: bcc32

CMake Error: your C compiler: "bcc32" was not found. 
Please set

CMAKE_C_COMPILER to a valid compiler path or name.

CMake Error: Internal CMake error, TryCompile configure 
of cmake failed


Check for working C compiler: bcc32 -- broken

CMake Error at C:/Program Files/CMake
2.8/share/cmake-2.8/Modules/CMakeTestCCompiler.cmake:52 
(MESSAGE):


The C compiler "bcc32" is not able to compile a simple 
test program.


It fails with the following output:

   CMake will not be able to correctly generate this 
project.


Call Stack (most recent call first):

CMakeLists.txt:2 (project)

CMake Error: your C compiler: "bcc32" was not found. 
Please set

CMAKE_C_COMPILER to a valid compiler path or name.

CMake Error: your CXX compiler: "bcc32" was not found. 
Please set

CMAKE_CXX_COMPILER to a valid compiler path or name.

CMake Error: your Fortran compiler: 
"CMAKE_Fortran_COMPILER-NOTFOUND" was
not found. Please set CMAKE_Fortran_COMPILER to a valid 
compiler path or

name.

Configuring incomplete, errors occurred!

_


I am using the Windows native command prompt.

Can anyone tell me why these compilers are not detected? 
If I have to give

some path, then which files do I have to edit?


Thanks in advance for your suggestion.


Best wishes

--
**
Kedar Moharana
Research Scholar
Laboratory for Protein Biochemistry & Biomolecular 
Engineering (LProBE)

Ghent University,
9000 Ghent, Belgium
**





DISCLAIMER: This message is intended exclusively for the addressee(s) and may 
contain confidential and privileged information. If you are not the intended 
recipient please notify the sender immediately and destroy this message. 
Unauthorized use, disclosure or copying of this message is strictly prohibited.
The foundation 'Stichting Deltares', which has its seat at Delft, The 
Netherlands, Commercial Registration Number 41146461, is not liable in any way 
whatsoever for consequences and/or damages resulting from the improper, 
incomplete and untimely dispatch, receipt and/or content of this e-mail.




--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] cmake support D programming?

[Arjen Markus]

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 curious if support for D language will be included in Cmake
(soon) ?


Sincerely,
Gour






--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake




DISCLAIMER: This message is intended exclusively for the addressee(s) and may 
contain confidential and privileged information. If you are not the intended 
recipient please notify the sender immediately and destroy this message. 
Unauthorized use, disclosure or copying of this message is strictly prohibited.
The foundation 'Stichting Deltares', which has its seat at Delft, The 
Netherlands, Commercial Registration Number 41146461, is not liable in any way 
whatsoever for consequences and/or damages resulting from the improper, 
incomplete and untimely dispatch, receipt and/or content of this e-mail.




--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Problem with dowloading CMake 2.8.6 (now gone btw)

[Arjen Markus]

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 downloaded the setup, but
I thought I'd mention it just in case.

Regards,

Arjen


DISCLAIMER: This message is intended exclusively for the addressee(s) and may 
contain confidential and privileged information. If you are not the intended 
recipient please notify the sender immediately and destroy this message. 
Unauthorized use, disclosure or copying of this message is strictly prohibited.
The foundation 'Stichting Deltares', which has its seat at Delft, The 
Netherlands, Commercial Registration Number 41146461, is not liable in any way 
whatsoever for consequences and/or damages resulting from the improper, 
incomplete and untimely dispatch, receipt and/or content of this e-mail.




--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] help with cmake fortran envar

[Arjen Markus]

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 have a fortran only project with some  source files with f77 routines  to 
compile,  My CMakeLists.txt in the projects base directory   has the following 
lines


set(CMAKE_Fortran_COMPILER  gfortran)
ENABLE_LANGUAGE(Fortran)


  but running cmake ends like so:-

-- Checking whether /usr/bin/gfortran supports Fortran 90
-- Checking whether /usr/bin/gfortran supports Fortran 90 -- yes
CMake Error: Error required internal CMake variable not set, cmake may be not 
be built correctly.

Missing variable is:
CMAKE_FORTRAN_COMPILER_ENV_VAR
CMake Error: Error required internal CMake variable not set, cmake may be not 
be built correctly.

Missing variable is:
CMAKE_FORTRAN_COMPILER
CMake Error: Could not find cmake module file:
$SOURCES/build/CMakeFiles/CMakeFORTRANCompiler.cmake
CMake Error: Could not find cmake module file:CMakeFORTRANInformation.cmake
CMake Error: CMAKE_FORTRAN_COMPILER not set, after EnableLanguage
-- Configuring incomplete, errors occurred!




#

I have set 
FC="gfortran"   and 
FFLAGS="flags/I/use/to/compile/stuff" 
as envars so I am perplexed what the required envar is.


advice would be appreciated

sincerely
luxInteg
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake




DISCLAIMER: This message is intended exclusively for the addressee(s) and may 
contain confidential and privileged information. If you are not the intended 
recipient please notify the sender immediately and destroy this message. 
Unauthorized use, disclosure or copying of this message is strictly prohibited.
The foundation 'Stichting Deltares', which has its seat at Delft, The 
Netherlands, Commercial Registration Number 41146461, is not liable in any way 
whatsoever for consequences and/or damages resulting from the improper, 
incomplete and untimely dispatch, receipt and/or content of this e-mail.




___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] linker associated to ifort fortran compiler

[Arjen Markus]

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 the linker 'lib' provided with the intel 
fortran compiler.


But, looking at my generated CMakeCache.txt I see just at the beginning:

CMAKE_AR:FILEPATH=C:/MinGW/bin/ar.exe (I have the Mingw tools installed 
on my machine


Two questions:
   - why cmake uses the 'lib' linker if another one was set in the 
CMakeCache.txt file ?


The compiler is but one of a set of related tools (the toolchain as
it is sometimes called). Choosing one means choosing all these others
as well.

CMAKE_AR is simply a variable that is used for other sets of tools.
The modules that come with CMake contain the information about what
tools to use and where to find them. There is no magic involved -
just hard labour.

If you leave the choice of the compiler to CMake, then - in my
experience - it is the generator you specify that determines
what compilers are tried first.

Regards,

Arjen


DISCLAIMER: This message is intended exclusively for the addressee(s) and may 
contain confidential and privileged information. If you are not the intended 
recipient please notify the sender immediately and destroy this message. 
Unauthorized use, disclosure or copying of this message is strictly prohibited.
The foundation 'Stichting Deltares', which has its seat at Delft, The 
Netherlands, Commercial Registration Number 41146461, is not liable in any way 
whatsoever for consequences and/or damages resulting from the improper, 
incomplete and untimely dispatch, receipt and/or content of this e-mail.




___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Problem with Intel Fortran and the Visual Studio 2008 generator

[Arjen Markus]

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 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 doubly defined (in libcmt.lib - __aenvptr,
__wenvptr, ___error_mode and ___app_type) and also a missing symbol
in libifcoremt.lib (_MAIN__).

These are system libraries that get included automatically during the
link step.

If I use the NMake Makefiles generator, however, all goes well.


I can reproduce this with VS 2008 and Intel 11.1 in 32-bit mode:

LIBCMT.lib(dllcrt0.obj) : error LNK2005: __aenvptr already defined in 
LIBCMT.lib(crt0.obj)
LIBCMT.lib(dllcrt0.obj) : error LNK2005: __wenvptr already defined in 
LIBCMT.lib(crt0.obj)
LIBCMT.lib(dllcrt0.obj) : error LNK2005: ___error_mode already defined in 
LIBCMT.lib(crt0.obj)
LIBCMT.lib(dllcrt0.obj) : error LNK2005: ___app_type already defined in 
LIBCMT.lib(crt0.obj)

Note that one comes from "dllcrt0.obj" and the other from "crt0.obj".
The build is mixing static and shared runtime libraries.

It looks like the Platform/Windows-ifort.cmake module is not getting
loaded for this generator.  This is due to a dumb bug in the language
information files.  I've pushed out a fix:

http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=20f49730

-Brad




DISCLAIMER: This message is intended exclusively for the addressee(s) and may 
contain confidential and privileged information. If you are not the intended 
recipient please notify the sender immediately and destroy this message. 
Unauthorized use, disclosure or copying of this message is strictly prohibited.
The foundation 'Stichting Deltares', which has its seat at Delft, The 
Netherlands, Commercial Registration Number 41146461, is not liable in any way 
whatsoever for consequences and/or damages resulting from the improper, 
incomplete and untimely dispatch, receipt and/or content of this e-mail.




___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Problem with Intel Fortran and the Visual Studio 2008 generator

[Arjen Markus]

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 doubly defined (in libcmt.lib - __aenvptr,
__wenvptr, ___error_mode and ___app_type) and also a missing symbol
in libifcoremt.lib (_MAIN__).

These are system libraries that get included automatically during the
link step.

If I use the NMake Makefiles generator, however, all goes well.

In both cases I use CMake 2.8 and I use only default options.
I always generate the solution/project files/makefiles in an
empty directory.

Any suggestions as to a solution?

Regards,

Arjen


DISCLAIMER: This message is intended exclusively for the addressee(s) and may 
contain confidential and privileged information. If you are not the intended 
recipient please notify the sender immediately and destroy this message. 
Unauthorized use, disclosure or copying of this message is strictly prohibited.
The foundation 'Stichting Deltares', which has its seat at Delft, The 
Netherlands, Commercial Registration Number 41146461, is not liable in any way 
whatsoever for consequences and/or damages resulting from the improper, 
incomplete and untimely dispatch, receipt and/or content of this e-mail.




___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] What triggers CMake to scan (C) files for dependencies?

[Arjen Markus]

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-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 versions did not seem to
include any dependencies from #include (the file "depend.make" was
simply a dummy).

When I added my custom build step, I had great difficulty to get
the dependencies right. The file "depend.make" remained empty.
Then I added a call to set_source_files_properties() to explicitly
set the dependency on that one header file and now I see that
_all_ C files in the project are listed there.

So, my question: is it the set_source_files_properties() command
that turns on this scanning? Is there a more explicit way (I want
to have this scanning turned on regardless of any explicit
dependencies I need).

I am using CMake 2.8

Regards,

Arjen


DISCLAIMER: This message is intended exclusively for the addressee(s) 
and may contain confidential and privileged information. If you are not 
the intended recipient please notify the sender immediately and destroy 
this message. Unauthorized use, disclosure or copying of this message is 
strictly prohibited.
The foundation 'Stichting Deltares', which has its seat at Delft, The 
Netherlands, Commercial Registration Number 41146461, is not liable in 
any way whatsoever for consequences and/or damages resulting from the 
improper, incomplete and untimely dispatch, receipt and/or content of 
this e-mail.





___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html


Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ


Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake




DISCLAIMER: This message is intended exclusively for the addressee(s) and may 
contain confidential and privileged information. If you are not the intended 
recipient please notify the sender immediately and destroy this message. 
Unauthorized use, disclosure or copying of this message is strictly prohibited.
The foundation 'Stichting Deltares', which has its seat at Delft, The 
Netherlands, Commercial Registration Number 41146461, is not liable in any way 
whatsoever for consequences and/or damages resulting from the improper, 
incomplete and untimely dispatch, receipt and/or content of this e-mail.




___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] What triggers CMake to scan (C) files for dependencies?

[Arjen Markus]

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 versions did not seem to
include any dependencies from #include (the file "depend.make" was
simply a dummy).

When I added my custom build step, I had great difficulty to get
the dependencies right. The file "depend.make" remained empty.
Then I added a call to set_source_files_properties() to explicitly
set the dependency on that one header file and now I see that
_all_ C files in the project are listed there.

So, my question: is it the set_source_files_properties() command
that turns on this scanning? Is there a more explicit way (I want
to have this scanning turned on regardless of any explicit
dependencies I need).

I am using CMake 2.8

Regards,

Arjen


DISCLAIMER: This message is intended exclusively for the addressee(s) and may 
contain confidential and privileged information. If you are not the intended 
recipient please notify the sender immediately and destroy this message. 
Unauthorized use, disclosure or copying of this message is strictly prohibited.
The foundation 'Stichting Deltares', which has its seat at Delft, The 
Netherlands, Commercial Registration Number 41146461, is not liable in any way 
whatsoever for consequences and/or damages resulting from the improper, 
incomplete and untimely dispatch, receipt and/or content of this e-mail.




___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Problem with GNU compilers - difference between "Windows" and "MinGW"

[Arjen Markus]

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 sources.
- To my surprise the free_eos project's build system failed to
  find the libblas.a and liblapack.a files that I had generated.
- I used the "MinGW Makefiles" generator in both cases.

Here is what I conclude from an analysis of what is going on:
- With the "MinGW Makefiles" generator, the GNU compilers are
  recognised first - which is what I wanted.
- I use the GNU compilers in an environment that does not state
  it is "MinGW" and so, find_library uses the Windows convention
  for naming libraries. So with in free_eos, CMake expects the
  files blas.lib and lapack.lib.
- The CMake configuration for the GNU compilers - ignoring the specifics
  of Windows - always uses the Linux convention for library names.
  So it produces libblas.a and liblapack.a.

I may be mistaken in the details, but this is definitely what it boils
down to. Shouldn't the "MinGW Makefiles" generator take care of these
two naming conventions?

Regards,

Arjen



DISCLAIMER: This message is intended exclusively for the addressee(s) and may 
contain confidential and privileged information. If you are not the intended 
recipient please notify the sender immediately and destroy this message. 
Unauthorized use, disclosure or copying of this message is strictly prohibited.
The foundation 'Stichting Deltares', which has its seat at Delft, The 
Netherlands, Commercial Registration Number 41146461, is not liable in any way 
whatsoever for consequences and/or damages resulting from the improper, 
incomplete and untimely dispatch, receipt and/or content of this e-mail.




___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Complete beginner question about tutorial

[Arjen Markus]

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 get people started rightaway. But then if they need to add a
file or change compile options, they will have to use CMake again.
If running CMake - or any other tool that generates files - is
problematic, then putting such files in the distribution is
one way out again.)

Regards,

Arjen

On 2010-09-07 15:24, David Aldrich wrote:

Hi Eike and Arjen

Thanks for your answers. Sorry for my trivial question!

I would like to ask a question about best practice. I think that, initially, we 
would use CMake only on Linux, to replace our hardcoded of gnu makefiles (we 
don't use autotools). So only one platform is involved. I am wondering what to 
put under version control. Would it be best to version control only 
CMakeLists.txt and let each developer separately run CMake and then make? Or 
should the modifier of CMakeLists.txt be responsible for running CMake and 
check-in the generated Makefile, so that the user only needs to update his 
(svn) working copy and run make?

Best regards

David


-Original Message-
From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf
Of Rolf Eike Beer
Sent: 07 September 2010 13:11
To: cmake@cmake.org
Subject: Re: [CMake] Complete beginner question about tutorial

Am Tuesday 07 September 2010 schrieb David Aldrich:

Hi

I want to run the CMake tutorial
(http://www.cmake.org/cmake/help/cmake_tutorial.html).

The tutorial appears not to show the CMake commands necessary to build
program. On Windows what command should I use to build the Tutorial
executable with Visual C++ 2008?

You should create the programs with '-G "Visual Studio 9 2008"' to get a
MSVC solution file. Load that one and just let it build.

You could open a compiler console (Start -> Programs -> Microsoft Visual
Studio 2008 -> Tools -> x86 command prompt (or something like that)) and
use '-G "NMake Makefiles"'. Then you would run "nmake" from that command
window to build. You need to run cmake in that window or it will not be
able to detect the proper compiler settings for nmake otherwise.

Eike

___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake




DISCLAIMER: This message is intended exclusively for the addressee(s) and may 
contain confidential and privileged information. If you are not the intended 
recipient please notify the sender immediately and destroy this message. 
Unauthorized use, disclosure or copying of this message is strictly prohibited.
The foundation 'Stichting Deltares', which has its seat at Delft, The 
Netherlands, Commercial Registration Number 41146461, is not liable in any way 
whatsoever for consequences and/or damages resulting from the improper, 
incomplete and untimely dispatch, receipt and/or content of this e-mail.




___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Complete beginner question about tutorial

[Arjen Markus]

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 13:07, David Aldrich wrote:
Hi 


I want to run the CMake tutorial 
(http://www.cmake.org/cmake/help/cmake_tutorial.html).

The tutorial appears not to show the CMake commands necessary to build program. 
On Windows what command should I use to build the Tutorial executable with 
Visual C++ 2008?

Best regards

David

___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake




DISCLAIMER: This message is intended exclusively for the addressee(s) and may 
contain confidential and privileged information. If you are not the intended 
recipient please notify the sender immediately and destroy this message. 
Unauthorized use, disclosure or copying of this message is strictly prohibited.
The foundation 'Stichting Deltares', which has its seat at Delft, The 
Netherlands, Commercial Registration Number 41146461, is not liable in any way 
whatsoever for consequences and/or damages resulting from the improper, 
incomplete and untimely dispatch, receipt and/or content of this e-mail.




___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CMAKE_SOURCE_DIR overwritten by CMake Fortran language support

[Arjen Markus]

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).

Regards,

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 entire source tree that ever sets
that variable.  It's in Source/cmMakefile.cxx:

 this->AddDefinition("CMAKE_SOURCE_DIR", this->GetHomeDirectory());


What does this->GetHomeDirectory() do?

Arjen reported to me that CMAKE_SOURCE_DIR was overwritten to
F:/plplot-svn/build-mingw-test-cmake/language_tests/Fortran/CMakeFiles/CMakeTmp/ 



Is that consistent with the above code in the MinGW case?


One thing you might want to try is cmake --trace, and then track down
where the CMAKE_SOURCE_DIR is getting clobbered.


This is a good approach.


In case Arjen is slow to respond with results from cmake --trace, I hope 
the

additional information above gives you some help in tracking this down.

Alan
__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__

Linux-powered Science
__


___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] building plplot

[Arjen Markus]

Hi Vince,

does your system have the "make" utility (not nmake)? That is the
build program that the MinGW generator is looking for.

You should also build in a different directory than the source directory
- to keep that clean.

So, something along these lines:

> cd \
> md plplot-build
> cd plplot-build
> cmake ..\plplot-build -G "MinGW Makefiles"

Regards,

Arjen

On 2010-03-18 19:59, Vincenzo Urso Miano wrote:

Hello,
You were right the fortran compiler was the first one on the path. Now
I put MinGw on the first position. The behaviour is somehow changed
but I still get errors.

When I type C:\plplot-5.9.5> cmake -G MinGW Makefiles on CMD
here is what I get:

CMake Error: Could not create named generator MinGW
C:\plplot-5.9.5>cmake -G "MinGW Makefiles"
CMake Error: CMake was unable to find a build program corresponding to
"MinGW Makefiles".  CMAKE_MAKE_PROGRAM is not set.  You probably need
to select a different build tool.
CMake Error: CMake was unable to find a build program corresponding to
"MinGW Makefiles".  CMAKE_MAKE_PROGRAM is not set.  You probably need
to select a different build tool.
CMake Error: Error required internal CMake variable not set, cmake may be not be
 built correctly.
Missing variable is:
CMAKE_C_COMPILER_ENV_VAR
CMake Error: Error required internal CMake variable not set, cmake may be not be
 built correctly.
Missing variable is:
CMAKE_C_COMPILER
CMake Error: Could not find cmake module file:C:/plplot-5.9.5/CMakeFiles/CMakeCC
ompiler.cmake
CMake Error: CMAKE_C_COMPILER not set, after EnableLanguage
-- Configuring incomplete, errors occurred!



I can see it is missing, for example,  CMAKE_C_COMPILER so I tried to
configure it:
C:\plplot-5.9.5>cmake -CMAKE_C_COMPILER=C:\MinGW\bin\gcc.exe

here's what I got:

loading initial cache file MAKE_C_COMPILER=C:\MinGW\bin\gcc.exe
CMake Error: Error processing file:MAKE_C_COMPILER=C:\MinGW\bin\gcc.exe
-- Building for: NMake Makefiles
CMake Error: CMake was unable to find a build program corresponding to
"NMake Makefiles".  CMAKE_MAKE_PROGRAM is not set.  You probably need
to select a different build tool.
CMake Error: Error required internal CMake variable not set, cmake may be not be
 built correctly.Missing variable is:
CMAKE_C_COMPILER_ENV_VAR
CMake Error: Error required internal CMake variable not set, cmake may be not be
 built correctly.
Missing variable is:CMAKE_C_COMPILER
CMake Error: 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 Markus :

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",
as CMake is now trying to run the compiler via nmake - I have
a hunch that that makes it think it needs to use MSVC options.

Regards,

Arjen

On 2010-03-17 20:56, Vincenzo Urso Miano wrote:

Hi everyone,
I am trying to build plplot with CMake.

My details
-Windows XP
-to build plplot I installed the MinGW suite
-cmake 2.8

Here's what i get:

C:\plplot-5.9.5>cmake -DCMAKE_INSTALL_PREFIX=C:\plplotBUILD
-- The C compiler identification is unknown
-- Check for working C compiler: C:/MinGW/bin/gcc.exe
-- Check for working C compiler: C:/MinGW/bin/gcc.exe -- broken
CMake Error at C:/Program Files/CMake
2.8/share/cmake-2.8/Modules/CMakeTestCComp
iler.cmake:50 (MESSAGE):
 The C compiler "C:/MinGW/bin/gcc.exe" is not able to compile a simple
test
 program.

 It fails with the following output:
  Change Dir: C:/plplot-5.9.5/CMakeFiles/CMakeTmp

 Run Build Command:nmake /NOLOGO "cmTryCompileExec\fast"
   nmake -f CMakeFiles\cmTryCompileExec.dir\build.make /nologo -L
 CMakeFiles\cmTryCompileExec.dir\build

   "C:\Program Files\CMake 2.8\bin\cmake.exe" -E cmake_progress_report
 C:\plplot-5.9.5\CMakeFiles\CMakeTmp\CMakeFiles 1

 Building C object CMakeFiles/cmTryCompileExec.dir/testCCompiler.c.obj

   C:\MinGW\bin\gcc.exe /DWIN32 /D_WINDOWS /W3 /Zm1000 -o
 CMakeFiles\cmTryCompileExec.dir\testCCompiler.c.obj -c
 C:\plplot-5.9.5\CMakeFiles\CMakeTmp\testCCompiler.c

 gcc.exe: /DWIN32: No such file or directory
 gcc.exe: /D_WINDOWS: No such file or directory
 gcc.exe: /W3: No such file or directory
 gcc.exe: /Zm1000: No such file or directory
 NMAKE : fatal error U1077: 'C:\MinGW\bin\gcc.exe' : return code '0x1

Re: [CMake] building plplot

[Arjen Markus]

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",
as CMake is now trying to run the compiler via nmake - I have
a hunch that that makes it think it needs to use MSVC options.

Regards,

Arjen

On 2010-03-17 20:56, Vincenzo Urso Miano wrote:

Hi everyone,
I am trying to build plplot with CMake.

My details
-Windows XP
-to build plplot I installed the MinGW suite
-cmake 2.8

Here's what i get:

C:\plplot-5.9.5>cmake -DCMAKE_INSTALL_PREFIX=C:\plplotBUILD
-- The C compiler identification is unknown
-- Check for working C compiler: C:/MinGW/bin/gcc.exe
-- Check for working C compiler: C:/MinGW/bin/gcc.exe -- broken
CMake Error at C:/Program Files/CMake 2.8/share/cmake-2.8/Modules/CMakeTestCComp
iler.cmake:50 (MESSAGE):
  The C compiler "C:/MinGW/bin/gcc.exe" is not able to compile a simple test
  program.

  It fails with the following output:
   Change Dir: C:/plplot-5.9.5/CMakeFiles/CMakeTmp

  Run Build Command:nmake /NOLOGO "cmTryCompileExec\fast"
nmake -f CMakeFiles\cmTryCompileExec.dir\build.make /nologo -L
  CMakeFiles\cmTryCompileExec.dir\build

"C:\Program Files\CMake 2.8\bin\cmake.exe" -E cmake_progress_report
  C:\plplot-5.9.5\CMakeFiles\CMakeTmp\CMakeFiles 1

  Building C object CMakeFiles/cmTryCompileExec.dir/testCCompiler.c.obj

C:\MinGW\bin\gcc.exe /DWIN32 /D_WINDOWS /W3 /Zm1000 -o
  CMakeFiles\cmTryCompileExec.dir\testCCompiler.c.obj -c
  C:\plplot-5.9.5\CMakeFiles\CMakeTmp\testCCompiler.c

  gcc.exe: /DWIN32: No such file or directory
  gcc.exe: /D_WINDOWS: No such file or directory
  gcc.exe: /W3: No such file or directory
  gcc.exe: /Zm1000: No such file or directory
  NMAKE : fatal error U1077: 'C:\MinGW\bin\gcc.exe' : return code '0x1'
  Stop.

  NMAKE : fatal error U1077: '"c:\program files\microsoft visual
  studio\vc98\bin\nmake.exe"' : return code '0x2'
  Stop.

  CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
  CMakeLists.txt:38 (project)
-- Configuring incomplete, errors occurred!

I don't know why gcc is not compiling. could you help me with this?
It's the first time I use CMake

Thanks
Vince
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake


___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CMake 2.8.1 RC 3 is ready to try

[Arjen Markus]

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 PLplot


Thanks.  I still get this:

  -- The Fortran compiler identification is GNU
  -- Check for working Fortran compiler: 
/usr/bin/gfortran.exe
  -- Check for working Fortran compiler: 
/usr/bin/gfortran.exe  -- works


-Brad



I am getting the same. Here is the full output:

-- The Fortran compiler identification is GNU
-- Check for working Fortran compiler: 
/cygdrive/c/arjen/gfortran/bin/gfortran.exe
-- Check for working Fortran compiler: 
/cygdrive/c/arjen/gfortran/bin/gfortran.exe  -- works

-- Detecting Fortran compiler ABI info
-- Detecting Fortran compiler ABI info - done
-- Checking whether 
/cygdrive/c/arjen/gfortran/bin/gfortran.exe supports 
Fortran 90
-- Checking whether 
/cygdrive/c/arjen/gfortran/bin/gfortran.exe supports 
Fortran 90 -- yes

-- Configuring done
-- Generating done
-- Build files have been written to: 
/cygdrive/c/arjen/plplot-svn/test-alan/test_build


So, there _is_ a difference between this test project and 
PLplot.


Regards,

Arjen

___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CMake 2.8.1 RC 3 is ready to try

[Arjen Markus]

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 
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 except I 
haven't bothered
with our soft-landing code to deal with missing/broken 
Fortran compilers.




I just tried Brad's simple project and that worked fine.
I then rebuilt PLplot and came across the following 
messages:


-- The C compiler identification is GNU
-- Check for working C compiler: /bin/gcc.exe
-- Check for working C compiler: /bin/gcc.exe -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- CMake version = 2.8.1
-- Checking whether system has ANSI C header files

-- Check for isnan in  - found
-- Check for using stdint.h with CXX compiler
-- Check for using stdint.h with CXX compiler - ok
-- CMAKE_GENERATOR = Unix Makefiles
-- The Fortran compiler identification is GNU
-- Check for working Fortran compiler: 
/cygdrive/c/arjen/gfortran/bin/gfortran.exe
-- Check for working Fortran compiler: 
/cygdrive/c/arjen/gfortran/bin/gfortran.exe  -- works

-- Detecting Fortran compiler ABI info
-- Detecting Fortran compiler ABI info - done
-- Checking whether 
/cygdrive/c/arjen/gfortran/bin/gfortran.exe supports 
Fortran 90
-- Checking whether 
/cygdrive/c/arjen/gfortran/bin/gfortran.exe supports 
Fortran 90 -- yes

-- Configuring done
-- Generating done
-- Build files have been written to: 
/cygdrive/c/arjen/plplot-svn/install-cygwin/language_tests/Fortran

-- The Fortran compiler identification is GNU
-- Check for working Fortran compiler: /bin/g77.exe
-- Check for working Fortran compiler: /bin/g77.exe  -- 
works

-- Detecting Fortran compiler ABI info
-- Detecting Fortran compiler ABI info - done
-- Checking whether /bin/g77.exe supports Fortran 90
-- Checking whether /bin/g77.exe supports Fortran 90 -- no
-- WARNING: fortran compiler does not support f90/95. 
Disabling f95 bindings

-- Check for f77 command line support
-- Check for f77 command line support - found
-- Check if isnan function is available in fortran
-- Check for isnan in fortran - not found
-- NOTICE: Found: /bin/g77.exe


So it sees that CMake first finds gfortran and then, upon 
processing the language_support part of PLplot, decides 
that it should continue with g77.


I will now look at Alan's test project. Hopefully that 
will give a similar result.


Regards,

Arjen
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CMake 2.8.1 RC 3 is ready to try

[Arjen Markus]

Hi Brad,

I will need to check that - PLplot does/did have a file 
CMakeFortranInformation.cmake, maybe that is the culprit.


I will try your minimal project myself, hopefully that will
give the same result, otherwise we will have a mystery at
our hands.

Regards,

Arjen

On 2010-02-22 14:35, 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 instead g77.


I cannot reproduce this.  I have a simple project:

  # CMakeLists.txt
  cmake_minimum_required(VERSION 2.6)
  project(Foo Fortran)

I get:

  -- The Fortran compiler identification is GNU
  -- Check for working Fortran compiler: /usr/bin/gfortran.exe
  -- Check for working Fortran compiler: /usr/bin/gfortran.exe  -- works

even with both gfortran and g77 in my path.
The list of possible compilers is in

  Modules/CMakeDetermineFortranCompiler.cmake

and it is this:

SET(CMAKE_Fortran_COMPILER_LIST
  ifort ifc efc f95 pgf95 lf95 xlf95 fort gfortran gfortran-4 g95 f90
  pgf90 xlf90 epcf90 fort77 frt pgf77 xlf fl32 af77 g77 f77
  )

Note that gfortran comes well before g77.  CMake 2.8 has a
new feature that once one language's compiler is enabled then
it changes the search order to look for compilers from the
same vendor for other languages.  If the GNU C compiler is
recognized first, then enabling Fortran uses this list:

SET(_Fortran_COMPILER_NAMES_GNU   gfortran gfortran-4 g95 g77)

Again, gfortran comes first.

Are you using a modified CMakeDetermineFortranCompiler.cmake
in your own CMAKE_MODULE_PATH?

-Brad


___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CMake 2.8.1 RC 3 is ready to try

[Arjen Markus]

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 ambiguous:
 INFO:compiler[GNU]
 INFO:platform[Cygwin]

Regards,

Arjen
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Compaq Visual Fortran

[Arjen Markus]

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, as there is no CMAKE_INCLUDE_FLAG_FORTRAN, it
appears.

I have not tried the undocumented route you mentioned, as that
may have an even larger impact.

Regards,

Arjen

On 2010-02-16 16:12, Brad King wrote:



The documented way to change the include path flag to "-I " instead
of just "-I" is:

  set(CMAKE_INCLUDE_FLAG_C "-I ")
  set(CMAKE_INCLUDE_FLAG_CXX "-I ")


___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Compaq Visual Fortran

[Arjen Markus]

Hi Brad,

thanks for this detailed explanation. I will try again with these
amendments.

(I detest the introduction of spaces in directory names and file names.
It messes up all manner of things! Yes, you are right, quotes won't
solve the issue.)

Regards,

Arjen

On 2010-02-16 16:12, Brad 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 manner! Instead of -I "F:\plplot-svn\..." it interprets the option
as -IF:"\plplot-svn\plplot\..."

I am not sure if there are other compilers (except Intel Fortran) that
use an optional colon to separate option name from the keyword, but
the issue is wider than just this one:

What happens if someone puts the sources in a directory whose name
contains a space, like: "c:\my documents\my sources\" ?


It will be quoted or converted to the windows "shortpath" format which
never has spaces.  CMake quotes only when necessary (see below).

The documented way to change the include path flag to "-I " instead
of just "-I" is:

  set(CMAKE_INCLUDE_FLAG_C "-I ")
  set(CMAKE_INCLUDE_FLAG_CXX "-I ")

Reading the source, I see there is an undocumented way to force
quoting of include paths:

  set(CMAKE_QUOTE_INCLUDE_PATHS 1)

One of the above should be added to the compiler information file for
Compaq.


Shouldn't all file names and directory names be properly delimited?


Quoting on windows is a PITA because programs receive one big command
line string from the operating system on startup.  Most programs just
let the runtime library parse the string to produce argv[] and call
main, but some tools get the command line string and parse it themselves.

-Brad


___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Compaq Visual Fortran

[Arjen Markus]

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 the -iface option that it could not
understand. There is no option -iface to be found anywhere, so it
was a very nasty riddle!

It took me some fiddling with versions of CMake and PLplot files before
I realised that the cause was the fact that I was compiling on the
F-disk of my laptop. So, the compile command turned out something
like:

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! Instead of -I "F:\plplot-svn\..." it interprets the option
as -IF:"\plplot-svn\plplot\..."

I am not sure if there are other compilers (except Intel Fortran) that
use an optional colon to separate option name from the keyword, but
the issue is wider than just this one:

What happens if someone puts the sources in a directory whose name
contains a space, like: "c:\my documents\my sources\" ?

Shouldn't all file names and directory names be properly delimited?

Regards,

Arjen


On 2010-02-02 13:38, Brad King wrote:



Rename Windows-f90.cmake to Windows-Compaq-Fortran.cmake and put it
in your project under CMAKE_MODULE_PATH (under a Platform/ directory).
This should enable support in your project without needing any patches
to the current CMake in CVS HEAD.

Windows-f90.cmake in its current form is not ready for inclusion in
upstream CMake as Windows-Compaq-Fortran.cmake.  It sets several
variable that are not related specifically to Fortran.  We need to
refactor it a bit.  Please submit a feature request in the issue
tracker and include the module for further discussion.


Note: I just saw there is already a Windows-df.cmake file in the
repository, but I guess "df.exe" is not used as the name for a
possible compiler.


That's a patch from you in 2006:

  http://www.cmake.org/Bug/view.php?id=3950

-Brad


___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] How to find the DLL's a a required package searched with FIND_PACKAGE()?

[Arjen Markus]

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! Thanks.

Regards,

Arjen
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] How to find the DLL's a a required package searched with FIND_PACKAGE()?

[Arjen Markus]

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. There, we all speculated from our
various
Linux and Windows platform perspectives that SET(ENV{PATH} ...) just
sets
the PATH when you are running cmake and would have no effect on the
environment for the subsequent build.  Thus, we thought you would
have to
externally set the PATH before running the build.  But we all could
be wrong
which is why I have asked this question.  :-)


Alan,

You are correct. Doing this...

SET(ENV{xxx} "value")

...in a CMakeLists.txt file only sets an environment variable for the 
duration of the cmake run. It has no influence on downstream build steps.




The story with environment variables on Windows is slightly more
complicated than that:
- On Linux/UNIX you can set environment variables for the duration of
  a shell process via the set (setenv) command and by putting such
  commands in a shell script and using . (or source) to run the
  script in the same shell. This does not happen if you run the
  shell script normally (as it is run in a separate process then).

- On Windows (or DOS if you want to include some history) there is
  no separate "source" command. Instead if you set an environment
  variable in a batch file and run that batch file in a DOS-box,
  it will keep that value even after the batch file has finished -
  the batch file is run in the same process (an exit statement in
  such a batch file exits the DOS-box!). If you run a separate
  program, changes to the environment will be lost, just as under
  Linux.

For building PLplot under Windows I extend the path first (so that
includes the directory where the DLLs will be found) and then
run the various commands (CMake and make and the examples). But
that has become an "automatism".

What you could do is wrap the CMake command in a batch file,
including the command "set path=..." and run that instead.

The drawback is that the path will be expanded each time
you run it.

Regards,

Arjen
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Compaq Visual Fortran

[Arjen Markus]

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 accepted as well.


The "Windows-f90.cmake" name is the old naming convention that depended
on the compiler executable name.  The new convention is

  --.cmake

where =Windows, =Compaq, =Fortran in this case.

I've committed the rest of the changes needed to recognize Compaq:

  Recognize the Compaq Fortran compiler
  /cvsroot/CMake/CMake/Modules/CMakeDetermineFortranCompiler.cmake,v  <--  
Modules/CMakeDetermineFortranCompiler.cmake
  new revision: 1.29; previous revision: 1.28

Rename Windows-f90.cmake to Windows-Compaq-Fortran.cmake and put it
in your project under CMAKE_MODULE_PATH (under a Platform/ directory).
This should enable support in your project without needing any patches
to the current CMake in CVS HEAD.


I will test that.



Windows-f90.cmake in its current form is not ready for inclusion in
upstream CMake as Windows-Compaq-Fortran.cmake.  It sets several
variable that are not related specifically to Fortran.  We need to
refactor it a bit.  Please submit a feature request in the issue
tracker and include the module for further discussion.


Will do that.




Note: I just saw there is already a Windows-df.cmake file in the
repository, but I guess "df.exe" is not used as the name for a
possible compiler.


That's a patch from you in 2006:

  http://www.cmake.org/Bug/view.php?id=3950



:) I thought it was (actually based on work by somebody else).

Regards,

Arjen
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Compaq Visual Fortran

[Arjen Markus]

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.

Note: I just saw there is already a Windows-df.cmake file in 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 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 send the
error report if you want.

At least we have a succesful first step.


Great.  I've committed the underlying compiler id method to
CMake upstream, plus a test:

Add alternate per-vendor compiler id detection
/cvsroot/CMake/CMake/Modules/CMakeDetermineCompilerId.cmake,v  <--  
Modules/CMakeDetermineCompilerId.cmake
new revision: 1.22; previous revision: 1.21
/cvsroot/CMake/CMake/Tests/CMakeTests/CMakeLists.txt,v  <--  
Tests/CMakeTests/CMakeLists.txt
new revision: 1.26; previous revision: 1.25
/cvsroot/CMake/CMake/Tests/CMakeTests/CompilerIdVendorTest.cmake.in,v  <--  
Tests/CMakeTests/CompilerIdVendorTest.cmake.in
new revision: 1.2; previous revision: 1.1

I did not yet commit the actual Compaq compiler entry.  That
will be just the patch below.  Please try CMake HEAD from CVS
plus the patch below.  Then add Compaq compiler support by
creating a "Platform/Windows-Compaq-Fortran.cmake" file that
sets the build rules and flags for that compiler.  Content will
be similar to the Windows-f90.cmake file that Alan sent.

-Brad

diff --git a/Modules/CMakeDetermineFortranCompiler.cmake 
b/Modules/CMakeDetermineFortranCompiler.cmake
index 44e45d8..0637d20 100644
--- a/Modules/CMakeDetermineFortranCompiler.cmake
+++ b/Modules/CMakeDetermineFortranCompiler.cmake
@@ -162,6 +162,11 @@ IF(NOT CMAKE_Fortran_COMPILER_ID_RUN)
 "-fpp"
 )

+  # Table of per-vendor compiler id flags with expected output.
+  LIST(APPEND CMAKE_Fortran_COMPILER_ID_VENDORS Compaq)
+  SET(CMAKE_Fortran_COMPILER_ID_VENDOR_FLAGS_Compaq "-what")
+  SET(CMAKE_Fortran_COMPILER_ID_VENDOR_REGEX_Compaq "Compaq Visual Fortran")
+
   # Try to identify the compiler.
   SET(CMAKE_Fortran_COMPILER_ID)
   INCLUDE(${CMAKE_ROOT}/Modules/CMakeDetermineCompilerId.cmake)



___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Compaq Visual Fortran

[Arjen Markus]

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, CMake now
recognises the compiler but does not test it with the correct
compile flags (-o being reported as ambiguous). I can send the
error report if you want.

At least we have a succesful first step.


Great.  I've committed the underlying compiler id method to
CMake upstream, plus a test:

Add alternate per-vendor compiler id detection
/cvsroot/CMake/CMake/Modules/CMakeDetermineCompilerId.cmake,v  <--  
Modules/CMakeDetermineCompilerId.cmake
new revision: 1.22; previous revision: 1.21
/cvsroot/CMake/CMake/Tests/CMakeTests/CMakeLists.txt,v  <--  
Tests/CMakeTests/CMakeLists.txt
new revision: 1.26; previous revision: 1.25
/cvsroot/CMake/CMake/Tests/CMakeTests/CompilerIdVendorTest.cmake.in,v  <--  
Tests/CMakeTests/CompilerIdVendorTest.cmake.in
new revision: 1.2; previous revision: 1.1

I did not yet commit the actual Compaq compiler entry.  That
will be just the patch below.  Please try CMake HEAD from CVS
plus the patch below.  Then add Compaq compiler support by
creating a "Platform/Windows-Compaq-Fortran.cmake" file that
sets the build rules and flags for that compiler.  Content will
be similar to the Windows-f90.cmake file that Alan sent.

-Brad

diff --git a/Modules/CMakeDetermineFortranCompiler.cmake 
b/Modules/CMakeDetermineFortranCompiler.cmake
index 44e45d8..0637d20 100644
--- a/Modules/CMakeDetermineFortranCompiler.cmake
+++ b/Modules/CMakeDetermineFortranCompiler.cmake
@@ -162,6 +162,11 @@ IF(NOT CMAKE_Fortran_COMPILER_ID_RUN)
 "-fpp"
 )

+  # Table of per-vendor compiler id flags with expected output.
+  LIST(APPEND CMAKE_Fortran_COMPILER_ID_VENDORS Compaq)
+  SET(CMAKE_Fortran_COMPILER_ID_VENDOR_FLAGS_Compaq "-what")
+  SET(CMAKE_Fortran_COMPILER_ID_VENDOR_REGEX_Compaq "Compaq Visual Fortran")
+
   # Try to identify the compiler.
   SET(CMAKE_Fortran_COMPILER_ID)
   INCLUDE(${CMAKE_ROOT}/Modules/CMakeDetermineCompilerId.cmake)



___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Compaq Visual Fortran

[Arjen Markus]

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 send the
error report if you want.

At least we have a succesful first step.

Regards,

Arjen
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Compaq Visual Fortran

[Arjen Markus]

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 _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 vendor-specific code.


I ran f90 -what:

Compaq Visual Fortran Optimizing Compiler Version 6.6 (Update C)
Copyright 2003 Compaq Computer Corp. All rights reserved.

Compaq Visual Fortran 6.6-4088-47D3B
C:\Program Files\Microsoft Visual Studio\DF98\BIN\decfor90.exe


Thanks.  Undo the previous patch and try the one below instead.

-Brad


diff --git a/Modules/CMakeDetermineCompilerId.cmake 
b/Modules/CMakeDetermineCompilerId.cmake
index a70c6ab..bf4176c 100644
--- a/Modules/CMakeDetermineCompilerId.cmake
+++ b/Modules/CMakeDetermineCompilerId.cmake
@@ -42,6 +42,11 @@ FUNCTION(CMAKE_DETERMINE_COMPILER_ID lang flagvar src)
 ENDIF(NOT CMAKE_${lang}_COMPILER_ID)
   ENDFOREACH(flags)

+  # If the compiler is still unknown, try to query its vendor.
+  IF(NOT CMAKE_${lang}_COMPILER_ID)
+CMAKE_DETERMINE_COMPILER_ID_VENDOR(${lang})
+  ENDIF()
+
   # if the format is unknown after all files have been checked, put "Unknown" 
in the cache
   IF(NOT CMAKE_EXECUTABLE_FORMAT)
 SET(CMAKE_EXECUTABLE_FORMAT "Unknown" CACHE INTERNAL "Executable file 
format")
@@ -245,3 +250,32 @@ FUNCTION(CMAKE_DETERMINE_COMPILER_ID_CHECK lang file)
 PARENT_SCOPE)
   SET(CMAKE_EXECUTABLE_FORMAT "${CMAKE_EXECUTABLE_FORMAT}" PARENT_SCOPE)
 ENDFUNCTION(CMAKE_DETERMINE_COMPILER_ID_CHECK lang)
+
+#-
+# Function to query the compiler vendor.
+FUNCTION(CMAKE_DETERMINE_COMPILER_ID_VENDOR lang)
+  FOREACH(vendor ${CMAKE_${lang}_COMPILER_ID_VENDORS})
+SET(flags ${CMAKE_${lang}_COMPILER_ID_VENDOR_FLAGS_${vendor}})
+SET(regex ${CMAKE_${lang}_COMPILER_ID_VENDOR_REGEX_${vendor}})
+EXECUTE_PROCESS(
+  COMMAND ${CMAKE_${lang}_COMPILER}
+  ${CMAKE_${lang}_COMPILER_ID_ARG1}
+  ${CMAKE_${lang}_COMPILER_ID_FLAGS_LIST}
+  ${flags}
+  WORKING_DIRECTORY ${CMAKE_${lang}_COMPILER_ID_DIR}
+  OUTPUT_VARIABLE output ERROR_VARIABLE output
+  RESULT_VARIABLE result
+  )
+IF("${output}" MATCHES "${regex}")
+  FILE(APPEND ${CMAKE_BINARY_DIR}${CMAKE_FILES_DIRECTORY}/CMakeOutput.log
+"Checking whether the ${lang} compiler is ${vendor} using \"${flags}\" 
"
+"matched \"${regex}\":\n${output}")
+  SET(CMAKE_${lang}_COMPILER_ID "${vendor}" PARENT_SCOPE)
+  BREAK()
+ELSE()
+  FILE(APPEND ${CMAKE_BINARY_DIR}${CMAKE_FILES_DIRECTORY}/CMakeError.log
+"Checking whether the ${lang} compiler is ${vendor} using \"${flags}\" 
"
+"did not match \"${regex}\":\n${output}")
+ENDIF()
+  ENDFOREACH()
+ENDFUNCTION(CMAKE_DETERMINE_COMPILER_ID_VENDOR)
diff --git a/Modules/CMakeDetermineFortranCompiler.cmake 
b/Modules/CMakeDetermineFortranCompiler.cmake
index 44e45d8..0637d20 100644
--- a/Modules/CMakeDetermineFortranCompiler.cmake
+++ b/Modules/CMakeDetermineFortranCompiler.cmake
@@ -162,6 +162,11 @@ IF(NOT CMAKE_Fortran_COMPILER_ID_RUN)
 "-fpp"
 )

+  # Table of per-vendor compiler id flags with expected output.
+  LIST(APPEND CMAKE_Fortran_COMPILER_ID_VENDORS Compaq)
+  SET(CMAKE_Fortran_COMPILER_ID_VENDOR_FLAGS_Compaq "-what")
+  SET(CMAKE_Fortran_COMPILER_ID_VENDOR_REGEX_Compaq "Compaq Visual Fortran")
+
   # Try to identify the compiler.
   SET(CMAKE_Fortran_COMPILER_ID)
   INCLUDE(${CMAKE_ROOT}/Modules/CMakeDetermineCompilerId.cmake)


___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Compaq Visual Fortran

[Arjen Markus]

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
recognize it.  We'll have to start running unrecognized compilers
with various "-V", "--version", etc. arguments hoping to find one
that prints the compiler name.

What is the output of

  f90 -what



I ran f90 -what:

Compaq Visual Fortran Optimizing Compiler Version 6.6 (Update C)
Copyright 2003 Compaq Computer Corp. All rights reserved.

Compaq Visual Fortran 6.6-4088-47D3B
C:\Program Files\Microsoft Visual Studio\DF98\BIN\decfor90.exe

Regards,

Arjen
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Compaq Visual Fortran

[Arjen Markus]

Hi Brad,

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 preprocessor, except, 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 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 possible flags
to try if it can't find a compiler id:

  SET(CMAKE_Fortran_COMPILER_ID_TEST_FLAGS
# Try compiling to an object file only.
"-c"

# Intel on windows does not preprocess by default.
"-fpp"
)

It should have tried -fpp.  Look in CMakeFiles/CMakeError.log
to see if it reports what happened.

Also, please try building the compiler id source by hand.
Copy "CMakeFortranCompilerId.F.in" and rename it to drop
the ".in" part.  Then run

  f90 -fpp CMakeFortranCompilerId.F

Please send me whatever files this produces.

Thanks,
-Brad


___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Compaq Visual Fortran

[Arjen Markus]

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 wrote:

If you turn on the preprocessor option, then a number of macros
are defined, the most useful being:

_DF_VERSION_=660 and _VF_VERSION_==660


Please try out the patch below (applies to CMake from CVS HEAD).
With it, CMake should recognize the Compaq compiler out of the box.
It won't know what flags to use without the compiler info files, but
at least it should report the compiler identification.  If that works
for you I'll commit it upstream.  Then we can work on the compiler
info files.

Thanks,
-Brad

diff --git a/Modules/CMakeFortranCompilerId.F.in 
b/Modules/CMakeFortranCompilerId.F.in
index 107470c..a9aec76 100644
--- a/Modules/CMakeFortranCompilerId.F.in
+++ b/Modules/CMakeFortranCompilerId.F.in
@@ -10,6 +10,8 @@
 PRINT *, 'INFO:compiler[G95]'
 #elif defined(__PATHSCALE__)
 PRINT *, 'INFO:compiler[PathScale]'
+#elif defined(_DF_VERSION_) || defined(_VF_VERSION_)
+PRINT *, 'INFO:compiler[Compaq]'
 #elif defined(__GNUC__)
 PRINT *, 'INFO:compiler[GNU]'
 #elif defined(__IBMC__)


___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Compaq Visual Fortran

[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 not provide platform files for it yet.
CMake already recognizes the Compaq C and C++ compilers using
the macros __DECC and __DECCXX, respectively.

(1) What macro identifies the Compaq Fortran compiler?



If you turn on the preprocessor option, then a number of macros
are defined, the most useful being:

_DF_VERSION_=660 and _VF_VERSION_==660

(660 for version 6.6 of the Compaq Visual Fortran compiler)


(2) Does the compiler need a special option to preprocess a source
with the extension ".F" (e.g. /fpp)?



Yes, /fpp - MS Windows being a platform that uses a case-preserving
scheme for file names, it makes no sense to distinguish between .F
and .f

The file extensions it typically recognises are: .for, .f and .f90
(in any case).

Regards,

Arjen
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] What's the best way to support additional compilers for an "official" CMake language such as Fortran

[Arjen Markus]

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 platform file from the PLplot
project and it worked fine. No complaints whatsoever.

I will have to check that things work fine too under MSYS and Cygwin
for this compiler too but I am pretty confident about it.

Regards,

Arjen
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] What's the best way to support additional compilers for an "official" CMake language such as Fortran

[Arjen Markus]

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 15:36, Brad King wrote:



Don't specify the CMakeLists.txt file; just put the directory.  Also,
there is no space in the "Makefiles" part of the NMake generator name:

  "c:\program files\cmake 2.8\bin\cmake" ..\plplot -G "NMake Makefiles"

If specifying the CMakeLists.txt file causes this problem, that is
a separate bug to report.

-Brad


___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] What's the best way to support additional compilers for an "official" CMake language such as Fortran

[Arjen Markus]

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 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 subdirectory in the 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?

[snip]

"c:\program files\cmake 2.8\bin\cmake" ..\plplot\CMakeLists.txt -G "NMake Make 
files"


Don't specify the CMakeLists.txt file; just put the directory.  Also,
there is no space in the "Makefiles" part of the NMake generator name:

  "c:\program files\cmake 2.8\bin\cmake" ..\plplot -G "NMake Makefiles"

If specifying the CMakeLists.txt file causes this problem, that is
a separate bug to report.

-Brad


___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] What's the best way to support additional compilers for an "official" CMake language such as Fortran

[Arjen Markus]

Hi Brad,

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 subdirectory in the 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:

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 out-of-source.
Get a fresh tree from version control and try again.

-Brad


___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] What's the best way to support additional compilers for an "official" CMake language such as Fortran

[Arjen Markus]

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 gfortran should work though.
Please confirm this when you get a chance.


Will do - Cygwin is not installed on the laptop I used, but MinGW is.




- CMake complained at first about f90 - the -o option is ambiguous IIRC


Without the Compaq compiler info files CMake has no idea how to construct
the compiler command line, so it guesses with unix conventions.  This is
not surprising.


- There were no output files created in the working directory, but there
  was a message that all was fine.


What was the actual CMake output log?


- I tried to reproduce the error messages, but CMake reacts differently
  now: there is no indication it is trying to find a Fortran compiler,
  and it is finished very fast indeed.

Is it storing the cached information in another location than the
current (working) directory? If so, which is it?


There is also a CMakeFiles subdirectory in which compiler information
is kept outside of CMakeCache.txt so that it can be shared with the
try_compile projects.  Generally you should keep the source tree totally
clean and always use outside build trees.  That way you can just wipe
out the build tree to start fresh.



My usual procedure is this:
- Clean out the directory I want to build in (no subdirectories, no
  files)
- Start a batch file or shell script which refers to the correct
  version of CMake and the correct CMakeLists.txt file with all
  the options I want to use

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!
This is the command I used:

"c:\program files\cmake 2.8\bin\cmake" ..\plplot\CMakeLists.txt -G 
"NMake Make files"


in the directory build-windows ...

Actually, the entire source directory now contains subdirectories
like CMakeFiles.

This is weird - I have never seen it do this before. The only
changes I made to the CMake part of PLplot were: move two files
out of the way and remove their inclusion from the
language_support.cmake file to avoid error messages.

Regards,

Arjen
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] What's the best way to support additional compilers for an "official" CMake language such as Fortran

[Arjen Markus]

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 ambiguous IIRC
- There were no output files created in the working directory, but there
  was a message that all was fine.
- I tried to reproduce the error messages, but CMake reacts differently
  now: there is no indication it is trying to find a Fortran compiler,
  and it is finished very fast indeed.

Is it storing the cached information in another location than the
current (working) directory? If so, which is it?

I tried to repeat the above steps with a different directory, but that
had no effect.

Regards,

Arjen

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.

Thanks,
-Brad



___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] What's the best way to support additional compilers for an "official" CMake language such as Fortran

[Arjen Markus]

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
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Please support FindLAPACK/FindBLAS for C/C++-only projects

[Arjen Markus]

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 do not provide an nm-like
utility, but there is an system-independent way to do this:


Seems like this falls under "testing a number of common choices".  The
code to iterate through the choices just has to be written.

Jed


___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] What's the best way to support additional compilers for an "official" CMake language such as Fortran

[Arjen Markus]

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 a slightly modified
version of CMakeFortranInformation.cmake in cmake/modules that searches
${CMAKE_MODULE_PATH}/Platform locations as well as
${CMAKE_ROOT}/Modules/Platform.  That's pretty clumsy but this procedure 
has

worked fine for CMake-2.6.x.



...



Of course, the long-term solution to this problem is to contribute our 
files
that support additional Fortran compilers to CMake.  We would be happy 
to do

that, but that probably involves considerable delay until they are accepted
into an official CMake release, and in any case if our users find 
additional

Fortran compilers (or C compilers or C++ compilers) they would like us to
support, we would always need to independently test these files over at
least one PLplot release cycle ourselves before contributing them to CMake.

So I would appreciate an answer to the above question about the best
procedure for supporting additional compilers (for Fortran or any other
officially supported language for CMake) within a project like PLplot.



As one of the developers in the PLplot project, who is moreover
concerned with the support of Fortran, I would like to stress that we
are quite prepared to submit the changes to existing modules or the
additional modules to CMake. We can also test the modules for the
various compilers that come with CMake within the context of PLplot.

Regards,

Arjen

___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Please support FindLAPACK/FindBLAS for C/C++-only projects

[Arjen Markus]

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 link an actual Fortran program.  When calling from C,
you have to know how Fortran names are mangled which means testing a
number of common choices.  Nobody put this logic into these Find
modules, but it would be nice because many (most?) users of BLAS/Lapack
need to call it from both Fortran and C so they need to know how the
symbols are mangled.  CBLAS/CLapack are entirely different beasts, but I
know of far more C projects that call the Fortran versions directly than
use the C bindings.



Wouldn’t it be possible to use “nm” to detect the Fortran name mangling? For 
example:

On OS X, default LAPACK library:

nm /usr/lib/liblapack.dylib | grep cheev$ | awk '{print $3}’

_cheev

On Linux, using MKL:

nm /opt/intel/Compiler/11.1/056/mkl/lib/em64t/libmkl_intel_lp64.a | grep cheev$ 
| awk '{print $3}'

cheev

(Of course the “grep” and “awk” commands can be replaced with some cmake string 
commands, if you want to make it a bit more portable.)



This would indeed not work on systems that do not provide an nm-like
utility, but there is an system-independent way to do this:

Use a set of small C programs that will call a LAPACK routine with any
of the naming conventions:

int main() {
_cheev( ... );
}

void stdcall__ CHEEV( ... );
int main() {
CHEEV( ... );
}

etc.

Whichever of the programs can be successively linked (no unresolved
symbols) is the indication of the used name mangling scheme.

Caveats:
- Some Fortran compilers add two underscores when the name of the
  routine contains at least one underscore. So that variation must
  be tested too.
- String arguments pose an extra complication - the string length is
  usually added as a separate argument, but it may come at the end
  OR right after the string argument. This is not detectable by
  the above method.

Regards,

Arjen
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] pgf90 error

[Arjen Markus]

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
  CMakeFiles/cmTryCompileExec.dir/testFortranCompiler.f.o -o 
cmTryCompileExec

  -rdynamic

  pgf90-Error-Unknown switch: -rdynamic

  gmake[1]: *** [cmTryCompileExec] Error 1


The cause is here: apparently pgf90 does not know the -rdynamic flag.
You should probably check the CMake module for that compiler.

Regards,

Arjen
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Newbie question: cmake does not have nmake generator

[Arjen Markus]

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? (I can not get to my notes about it from my office and
I am not sure I put the information on the Wiki yet)

Regards,

Arjen


On 2009-09-10 11:10, David Aldrich wrote:

Hi Arjen


you should start cmake in a clean directory - old stuff might get in the
way otherwise, as a lot of information is being cached.


Yes, that was the problem. Thanks.

As I wrote in another mail this morning (the order seems to have got reversed) 
CMake now succeeds but nmake fails:

[ 87%] Generating test_dyndrivers_dir/null.rc
NMAKE : fatal error U1077: '.\test-drv-info.exe' : return code '0xc135'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio 
8\VC\BIN\nmake.exe"' : return code '0x2'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio 
8\VC\BIN\nmake.exe"' : return code '0x2'
Stop.

I am wondering whether this is to do with the dll path, but my path does start 
with:

PATH=..\..\plplot-5.9.5\buildnmake\dll;

Best regards

David


___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Newbie question: cmake does not have nmake generator

[Arjen Markus]

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 version of CMake, from a forgotten installation of Cygwin, and that was being invoked. I have now deleted that old CMake (and hopefully Cygwin as well) and am now truly running 2.6.4. 


C:\plplot-5.9.5\buildnmake>cmake --help
cmake version 2.6-patch 4
[snip]

However, I have now hit another problem:

C:\plplot-5.9.5\buildnmake>cmake -G "NMake Makefiles" 
-DCMAKE_INSTALL_PREFIX=install ..
CMake Error: The source "C:/plplot-5.9.5/CMakeLists.txt" does not match the source 
"/cygdrive/c/plplot-5.9.5/CMakeLists.
txt" used to generate cache.  Re-run cmake with a different source directory.

Any idea why this is happening please? Is the mention of 'cygdrive' worrying?

Best regards

David
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake


___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] F90 and legacy F77

[Arjen Markus]

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:39, James C. Sutherland wrote:

Is there a way to detect and use both F77 and F90 compilers?

I have some legacy F77 code that uses constructs that have been 
deprecated/removed in F90.  I would like to compile those F77 files with 
a F77 compiler, compile the F90 files with an F90 compiler, and then 
link them with the F90 compiler.


How can this be done with CMake?

For example:
foo.f   <-- F77 file
bar.f90  <-- F90 file

I want something equivalent to
g77 foo.f -o foo.o
gfotran bar.f90 foo.o -o executable.x

___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html


Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ


Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake


___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] FW: building a mixed language programm with CMake

[Arjen Markus]

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:
- create a library (static or dynamic) from the sources in one
  programming language
- create programs using these separate libraries

While I can not come up right now with the ready made CMakeLists.txt
file, I think that is the way to do it:
- turn hello.f90 into a library (say libhello.a)
- create the program from test.cpp using that library as a dependency.

Regards,

Arjen

On 2009-06-10 15:31, Natalie Happenhofer wrote:

Hi!
I have run the commands:

$ nm test.o
 U __gxx_personality_v0
 U hello1_
 T main
$ nm hello.o
 U _gfortran_st_write
 U _gfortran_st_write_done
 U _gfortran_transfer_character
 T hello1_

$ make VERBOSE=1
/usr/bin/cmake -H/home/happenhofer/versuche/CMake_tryout/Fortran 
-B/home/happenhofer/versuche/CMake_tryout/Fortran --check-build-system 
CMakeFiles/Makefile.cmake 0
/usr/bin/cmake -E cmake_progress_start 
/home/happenhofer/versuche/CMake_tryout/Fortran/CMakeFiles 
/home/happenhofer/versuche/CMake_tryout/Fortran/CMakeFiles/progress.make

make -f CMakeFiles/Makefile2 all
make[1]: Entering directory 
`/home/happenhofer/versuche/CMake_tryout/Fortran'

make -f CMakeFiles/hi.dir/build.make CMakeFiles/hi.dir/depend
make[2]: Entering directory 
`/home/happenhofer/versuche/CMake_tryout/Fortran'
cd /home/happenhofer/versuche/CMake_tryout/Fortran && /usr/bin/cmake -E 
cmake_depends "Unix Makefiles" 
/home/happenhofer/versuche/CMake_tryout/Fortran 
/home/happenhofer/versuche/CMake_tryout/Fortran 
/home/happenhofer/versuche/CMake_tryout/Fortran 
/home/happenhofer/versuche/CMake_tryout/Fortran 
/home/happenhofer/versuche/CMake_tryout/Fortran/CMakeFiles/hi.dir/DependInfo.cmake 
--color=

make[2]: Leaving directory `/home/happenhofer/versuche/CMake_tryout/Fortran'
make -f CMakeFiles/hi.dir/build.make CMakeFiles/hi.dir/requires
make[2]: Entering directory 
`/home/happenhofer/versuche/CMake_tryout/Fortran'

make[2]: Nothing to be done for `CMakeFiles/hi.dir/requires'.
make[2]: Leaving directory `/home/happenhofer/versuche/CMake_tryout/Fortran'
make -f CMakeFiles/hi.dir/build.make CMakeFiles/hi.dir/build
make[2]: Entering directory 
`/home/happenhofer/versuche/CMake_tryout/Fortran'

Linking Fortran executable hi
/usr/bin/cmake -E cmake_link_script CMakeFiles/hi.dir/link.txt --verbose=1
/usr/bin/gfortran   -fPIC  CMakeFiles/hi.dir/hello.o  -o hi -rdynamic 
-lgfortran
/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/../../../../lib64/crt1.o: In 
function `_start':

(.text+0x20): undefined reference to `main'
collect2: ld returned 1 exit status
make[2]: *** [hi] Error 1
make[2]: Leaving directory `/home/happenhofer/versuche/CMake_tryout/Fortran'
make[1]: *** [CMakeFiles/hi.dir/all] Error 2
make[1]: Leaving directory `/home/happenhofer/versuche/CMake_tryout/Fortran'
make: *** [all] Error 2


Thanks a lot for your effort!
Natalie


 > Date: Wed, 10 Jun 2009 05:50:11 -0700
 > From: denis_scherba...@yahoo.com
 > Subject: Re: [CMake] FW: building a mixed language programm with CMake
 > To: cmake@cmake.org; natalieh...@hotmail.com
 >
 >
 > > /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/../../../../lib64/crt1.o:
 > > In function `_start':
 > > (.text+0x20): undefined reference to `main'
 >
 > Try to compile with VERBOSE option:
 >
 > make VERBOSE=1
 >
 > this will show you, what GCC does.
 >
 > > The only library I tell CMake to link to is libgfortran.so.
 > > What libraries does CMake usually link to, without
 > > specifying?
 >
 > None. CMake is a Makefile generator it does not compile or link.
 > Could you run "nm test.o" and "nm hello.o" and post the result?
 > Also post verbose output.
 >
 > Denis
 >
 >
 >
 >


¡Es hora que descubras quién eres! Alguien puede conocerte mejor que tu 
mismo. 





___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Mixing C/CPP and Fortran

[Arjen Markus]

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 not care so much.
I guess this is a somewhat new area for CMake, so you
may have to experiment with compiler flags and see how
they fit into the CMake modules ...

Regards,

Arjen

On 2009-05-27 09:38, Alin M Elena wrote:
why not try to make Fortran the main language? 

Because the main is C?

Alin


___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Mixing C/CPP and Fortran

[Arjen Markus]

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 understand it correctly.

Regards,

Arjen

On 2009-05-26 21:29, Alin M Elena wrote:

Hi Kyle,

My personal opinion is that cmake should handle correctly and generate a 
binary in this case. libhello.a is generated by the project and is intended 
for the use within the project so cmake should do it.


with shared libs things are ok.

regards,

Alin



___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Problem with recognising the MSYS environment

[Arjen Markus]

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 one point is solved.


What libraries do you want to lookup with find_library()? If those are 
system/compiler libraries (e.g. ws2), don't do that but link them by 
their name, e.g. target_link_libraries(x ws2). This will always give you 
the right one.
Find_library() should only be used for libraries that are not system or 
compiler specific, e.g. you look but libfoo but never for libm.




Werner suggested that I use CMake 2.6.3 instead of 2.6.2, as he did not
have these problems. Indeed, with CMake 2.6.3 the correct import
libraries are found.

Regards,

Arjen


Delft Hydraulics, GeoDelft, the Subsurface and Groundwater unit of TNO and parts of Rijkswaterstaat have joined forces in a new independent institute for delta technology, Deltares. Deltares combines knowledge and experience in the field of water, soil and the subsurface. We provide innovative solutions to make living in deltas, coastal areas and river basins safe, clean and sustainable. 




DISCLAIMER: This message is intended exclusively for the addressee(s) and may 
contain confidential and privileged information. If you are not the intended 
recipient please notify the sender immediately and destroy this message. 
Unauthorized use, disclosure or copying of this message is strictly prohibited.
The foundation 'Stichting Deltares', which has its seat at Delft, The 
Netherlands, Commercial Registration Number 41146461, is not liable in any way 
whatsoever for consequences and/or damages resulting from the improper, 
incomplete and untimely dispatch, receipt and/or content of this e-mail.




___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Problem with recognising the MSYS environment

[Arjen Markus]

Hello Hendrik,

we are looking for the import libraries for the system libraries
gdi32.dll and comdlg32.dll on Windows XP. These import libraries are
compiler-dependent, so perhaps target_link_libraries() is indeed a
better solution.

Regards,

Arjen

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 one point is solved.


What libraries do you want to lookup with find_library()? If those are 
system/compiler libraries (e.g. ws2), don't do that but link them by 
their name, e.g. target_link_libraries(x ws2). This will always give you 
the right one.
Find_library() should only be used for libraries that are not system or 
compiler specific, e.g. you look but libfoo but never for libm.





Delft Hydraulics, GeoDelft, the Subsurface and Groundwater unit of TNO and parts of Rijkswaterstaat have joined forces in a new independent institute for delta technology, Deltares. Deltares combines knowledge and experience in the field of water, soil and the subsurface. We provide innovative solutions to make living in deltas, coastal areas and river basins safe, clean and sustainable. 




DISCLAIMER: This message is intended exclusively for the addressee(s) and may 
contain confidential and privileged information. If you are not the intended 
recipient please notify the sender immediately and destroy this message. 
Unauthorized use, disclosure or copying of this message is strictly prohibited.
The foundation 'Stichting Deltares', which has its seat at Delft, The 
Netherlands, Commercial Registration Number 41146461, is not liable in any way 
whatsoever for consequences and/or damages resulting from the improper, 
incomplete and untimely dispatch, receipt and/or content of this e-mail.




___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Problem with recognising the MSYS environment

[Arjen Markus]

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 indeed reacting
differently if -G is set differently:

- No -G option: CMake recognised the MS Visual C/C++ compiler as
   the C compiler on my system, and both MSYS and MINGW were unset.
   (This answers Werner's suggestion)


The default on Windows is to generate for Visual Studio. 


- -G "Unix Makefiles" caused it to recognise the MSYS/MinGW installation
   of gcc and set MINGW to 1.


cygwin -> -G"Unix Makefiles" 
msys -> -G"MSYS Makefiles"

mingw (i.e. via cmd.exe shell) -> -G"MinGW Makefiles"



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.

Regards,

Arjen


Delft Hydraulics, GeoDelft, the Subsurface and Groundwater unit of TNO and parts of Rijkswaterstaat have joined forces in a new independent institute for delta technology, Deltares. Deltares combines knowledge and experience in the field of water, soil and the subsurface. We provide innovative solutions to make living in deltas, coastal areas and river basins safe, clean and sustainable. 




DISCLAIMER: This message is intended exclusively for the addressee(s) and may 
contain confidential and privileged information. If you are not the intended 
recipient please notify the sender immediately and destroy this message. 
Unauthorized use, disclosure or copying of this message is strictly prohibited.
The foundation 'Stichting Deltares', which has its seat at Delft, The 
Netherlands, Commercial Registration Number 41146461, is not liable in any way 
whatsoever for consequences and/or damages resulting from the improper, 
incomplete and untimely dispatch, receipt and/or content of this e-mail.




___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Problem with recognising the MSYS environment

[Arjen Markus]

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 doing something wrong.

Here is what I do to work under MSYS:
- Start the rxvt console (via a shortcut created during the installation
   of MSYS)

- I start CMake (version 2.6.2, IIRC) with:
   cmake -G "Unix makefiles" .


MSYS has its own generator, so this should be
  cmake -G "MSYS Makefiles"



Hm, could that be the problem? I noticed that CMake is indeed reacting
differently if -G is set differently:

- No -G option: CMake recognised the MS Visual C/C++ compiler as
  the C compiler on my system, and both MSYS and MINGW were unset.
  (This answers Werner's suggestion)

- -G "Unix Makefiles" caused it to recognise the MSYS/MinGW installation
  of gcc and set MINGW to 1.

It is worth a try, indeed!

Thanks,

Arjen


Delft Hydraulics, GeoDelft, the Subsurface and Groundwater unit of TNO and parts of Rijkswaterstaat have joined forces in a new independent institute for delta technology, Deltares. Deltares combines knowledge and experience in the field of water, soil and the subsurface. We provide innovative solutions to make living in deltas, coastal areas and river basins safe, clean and sustainable. 




DISCLAIMER: This message is intended exclusively for the addressee(s) and may 
contain confidential and privileged information. If you are not the intended 
recipient please notify the sender immediately and destroy this message. 
Unauthorized use, disclosure or copying of this message is strictly prohibited.
The foundation 'Stichting Deltares', which has its seat at Delft, The 
Netherlands, Commercial Registration Number 41146461, is not liable in any way 
whatsoever for consequences and/or damages resulting from the improper, 
incomplete and untimely dispatch, receipt and/or content of this e-mail.




___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Problem with recognising the MSYS environment

[Arjen Markus]

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 created during the installation
  of MSYS)

- I start CMake (version 2.6.2, IIRC) with:
  cmake -G "Unix makefiles" .

- My CMakeLists.txt file is this:

# Check for MSYS
#
project(check)
message("MSYS: >${MSYS}<")
message("Mingw: >${MINGW}<")

- The output is this:

-- The C compiler identification is GNU
-- The CXX compiler identification is GNU
-- Check for working C compiler: C:/msys/1.0/mingw/bin/gcc.exe
-- Check for working C compiler: C:/msys/1.0/mingw/bin/gcc.exe -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: C:/msys/1.0/mingw/bin/c++.exe
-- Check for working CXX compiler: C:/msys/1.0/mingw/bin/c++.exe -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
MSYS: ><
Mingw: >1<
-- Configuring done
-- Generating done
-- Build files have been written to: C:/arjen/plplot-svn/test-mingw

As you can see, the MSYS variable does not get set.

I have found a workaround: if the environment variable OSTYPE has the
value "msys", then set MSYS explicitly to 1. But I do not know how
universal that workaround is.

The other problem (the one that triggered this investigation in the
first place) is that the find_library command does not find the
import libraries for gdi32.dll and comdlg32.dll specific to gcc under
MSYS, despite the hint given, but the MSVC import libraries instead.
(These are unuseable though with gcc)

I can workaround that problem as well, but again: I can not be sure
this will work on any other system but mine.

What is a better solution for this?

Regards,

Arjen



Delft Hydraulics, GeoDelft, the Subsurface and Groundwater unit of TNO and parts of Rijkswaterstaat have joined forces in a new independent institute for delta technology, Deltares. Deltares combines knowledge and experience in the field of water, soil and the subsurface. We provide innovative solutions to make living in deltas, coastal areas and river basins safe, clean and sustainable. 




DISCLAIMER: This message is intended exclusively for the addressee(s) and may 
contain confidential and privileged information. If you are not the intended 
recipient please notify the sender immediately and destroy this message. 
Unauthorized use, disclosure or copying of this message is strictly prohibited.
The foundation 'Stichting Deltares', which has its seat at Delft, The 
Netherlands, Commercial Registration Number 41146461, is not liable in any way 
whatsoever for consequences and/or damages resulting from the improper, 
incomplete and untimely dispatch, receipt and/or content of this e-mail.




___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] fortran flags in a c++ linked executable

[Arjen Markus]

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 affect the reading of the big-endian 
binary file (which is in read in fortran).  Perhaps I am still not 
setting it properly?


James


On Mar 31, 2009, at 1:30 PM, Alin M Elena wrote:


man g++
add_definition is a preprocessor directive not linking flag

Alin
--
__
"If the Universities will not study useless subjects, who will?"
G. F. FitzGerald, Nature, 45/46, 392 (1892)
__
Mr Alin M ELENA
Irish Centre for High-End Computing -- www.ichec.ie 
The Design Tower, Trinity Technology & Enterprise Campus
Grand Canal Quay, Dublin 2, Ireland
Tel: +353 (0) 1 5241608 ext 29
Fax: +353 (0) 1 7645845
http://alin.elenaworld.net
alin.el...@ichec.ie 
alinm.el...@gmail.com 
__
On Tuesday 31 March 2009 17:27:39 you wrote:
> > Should not the flag be passed to the linker? So in this case the
> > linker flags are read from the c++ compiler flags?
>
> I tried adding
> add_definitions( ${CMAKE_Fortran_FLAGS} )
> But the g++ linker complained about an unrecognized option (the -
> fconvert=big-endian option).
>
> When linking, I pull in the gfortran library,
> target_link_libraries( readx gfortran )
>
> When creating the fortran object files the appropriate flags are
> passed, but the g++ compiler has no notion of endian-ness...
>
> Any other ideas?







___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake



Delft Hydraulics, GeoDelft, the Subsurface and Groundwater unit of TNO and parts of Rijkswaterstaat have joined forces in a new independent institute for delta technology, Deltares. Deltares combines knowledge and experience in the field of water, soil and the subsurface. We provide innovative solutions to make living in deltas, coastal areas and river basins safe, clean and sustainable. 




DISCLAIMER: This message is intended exclusively for the addressee(s) and may 
contain confidential and privileged information. If you are not the intended 
recipient please notify the sender immediately and destroy this message. 
Unauthorized use, disclosure or copying of this message is strictly prohibited.
The foundation 'Stichting Deltares', which has its seat at Delft, The 
Netherlands, Commercial Registration Number 41146461, is not liable in any way 
whatsoever for consequences and/or damages resulting from the improper, 
incomplete and untimely dispatch, receipt and/or content of this e-mail.




___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Problem with Fortran module enclosed in #ifdef

[Arjen Markus]

> 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 CMake to
> perform preprocessing during dependency scanning for files with ".f".
>

Ah, of course. It was the included code. Sorry for the noise.

Regards,

Arjen
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Problem with Fortran module enclosed in #ifdef

[Arjen Markus]

>>
> 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 a more general
> solution, because I cannot be sure, that this is the only file, where
> preprocessing makes a difference. There might
> be other files containing a USE directive enclosed in ifdefs.
>

Most compilers seem to have a switch to turn preprocessing on,
no matter what the extension is. While that is not very portable
(but then, .F is not either!), it will get you going.

Regards,

Arjen
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Problems with Intel Fortran 11 on Windows XP

[Arjen Markus]

>> -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 go the extra mile and
>> some how automatically put the correct version in the file
>> and not break
>> older versions of Fortran.
>
> Yes, I understand, but I assume you can fix this in a future version?
>
> As for detecting the version of Fortran, you can look at this:
>
> [HKEY_LOCAL_MACHINE\SOFTWARE\Intel\Compilers\Fortran\110.066]
> "Revision"=dword:0042
> "Minor Version"=dword:
> "Major Version"=dword:000b
>
> The only problem is the "110.066" part in the address, but as this is
> the only "folder" under
> HKEY_LOCAL_MACHINE\SOFTWARE\Intel\Compilers\Fortran
> i guess it is doable to detect the compiler version (b is of course hex
> for 11).
>
Would that not break when there are several versions installed?

Perhaps the output from ifort /what helps a bit:

Intel(R) Visual Fortran Compiler for applications running on IA-32,
Version 10.1Build 20070913 Package ID: w_fc_p_10.1.011
Copyright (C) 1985-2007 Intel Corporation.  All rights reserved.

ifort: command line error: no files specified; for help type "ifort /help"

(Pity they do not use /v or -v ...)

Regards,

Arjen
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Problems with Intel Fortran 11 on Windows XP

[Arjen Markus]

>> 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 for working Fortran compiler: C:/Program
> Files/intel/Compiler/11.0/066/fortran/Bin/IA32/ifort.exe -- broken
> CMake Error at C:/Program Files/CMake
> 2.6/share/cmake-2.6/Modules/CMakeTestFortranCompiler.cmake:25 (MESSAGE):
>   The Fortran compiler "C:/Program
>   Files/intel/Compiler/11.0/066/fortran/Bin/IA32/ifort.exe" is not able
> to
>   compile a simple test program.
>
> --
> ... the output is the same as in the previous mail.
>
> Thanks for any help, I would really like to be able to generate a
> Visual Studio Project to compare CMake to a manual Visual Studio
> setup as some here do today.
>

This looks suspiciously like the kind of errors you get if the
environment is set incorrectly, that is, if you have not run
ifortvars.bat before running CMake.

(Another possibility is that there is a mixup between MinGW and
plain Windows: I have that sort of problems with another compiler
combination.)

What happens if you compile and link a small program by hand on
the DOS prompt?

Regards,

Arjen
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Fortran to C mapping module

[Arjen Markus]

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 compilers.  Does anyone know of a web site that lists different
Fortran compiler name mangling schemes?



Not sure if this will help you much, but,
http://en.wikipedia.org/wiki/Name_mangling#Name_mangling_in_Fortran
speaks of a few.


I had most of that covered, but did not know this:

already containing an underscore ("FOO_BAR") has two underscores 
appended ("foo_bar__"),


That is a tricky one, I will add a check for.


For my project to combine Fortran and Tcl I have devised something similar.
You can find it at http://ftcl.cvs.sourceforge.net/viewvc/ftcl/src/ 
(http://ftcl.sf.net for the project itself)

It implements every scheme I am aware of.

Note that with Fortran 2003 interfacing between Fortran and C becomes 
much easier as you

can do that via the ISO_C_BINDINGS module.

Regards,

Arjen
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Fortran dependency fixes

[Arjen Markus]

> 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.
>>
>> Regards,
>>
>> Arjen
>
> This bug was in cmake-2.4, which based on makedepf90-2.6.2 .  It was fixed
> by
> updating the cmake fortran parser to makedepf90-2.8.8, the version Gary
> uses.
>

Right, clear enough.

Regards,

Arjen
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Fortran dependency fixes

[Arjen Markus]

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 an adaptation of makedepf90. Furthermore, I noticed that there 
seems to be a patch in cmake indicating that the infinite loop problem 
has been fixed. 
 
My problem is that there are significant differences between the 
adaptation of makedepf90 in cmake from the original open source 
(makedepf90 version 2.8.8) for me to back out the fix.  One solution 
would be to just move over to the use of cmake, but this will not 
happen within our established processes.  Is there a Fortran 
dependencies guru who can explain the recent changes to the makedepf90 
(lex/yacc) which enhanced the support of the Fortran dependencies in 
cmake?


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.


Regards,

Arjen
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] windows command to compile

[Arjen Markus]

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 what compilers you have available, as they normally
include a make utility of sorts. But:
- gcc and related compilers can be used with "make"
- another popular utility is "nmake", which comes with the MS compilers

Regards,

Arjen

___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Extension proposal: CheckFortranFuinctionExists.cmake

[Arjen Markus]

> 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, afaik. For real number crunching one also uses the intel/amd or
>> goto
>> libraries and there is always only one library of these, for both C and
>> Fortran (afaik, these optimized libraries are also not written in
>> fortran
>> anymore, they just have this stupid interface to be compatible with
>> fortran.
>> The other issue with fortran libraries is to figure out, how these have
>> been
>> compiled (additional underscores, etc).
>
> You have described issues which illustrate and support my point. They may
> be
> considered fairly trivial on one fixed platform but become important if
> you
> are trying to make a multi-platform build system.  For example, what do
> you
> do about the underscore issue if you are testing the linking of C code
> with
> the fortran blas library? On one platform you will have to test sgemm, on
> another you will have to test sgemm_.  These cross-platform build-system
> issues all disappear if you test C/C++ code against the C version of blas.
>
>>
>> On the other hand, cblas even has a slightly different interface than
>> nativ
>> blas, so without changing the existing code it is not suitable for
>> linking.
>>
>
> Changing your existing code once to link to cblas may be a smaller price
> to
> pay. If your existing C/C++ code linked to the fortran BLAS library is to
> work on multiple platforms, what do you do about the cross-platform issue
> involving underscores?  You will end up doing a lot of extra work to
> support
> the platform variations that is not required if you link to the C version
> of
> BLAS.
>

With regards to the differences in calling and naming conventions
between Fortran and C, I recently posted a program on the comp.lang.fortran
newsgroup to solve that issue automatically, at least for the platforms
I have access to. It is part of my Ftcl project, the combination of Fortran
and Tcl - http://ftcl.sf.net. I post it below, as it may help solving the
current issue.

The idea is very simple:
Let the linker decide which version of a C routine will be called
by the Fortran program and let that version write its properties
to a header file.

Regards,

Arjen

- probe.f90 -
! probe.f90 --
! Try and identify the Fortran naming and calling convention
! - part of Ftcl
!
! Note:
! This is the Fortran part of a program  that uses a few tricks
! to determine:
! - The naming convention for the Fortran compiler (including
!   the current options that influence this convention).
!   The result will be:
!   - One of FOR_ALL_LOWER, FOR_ALL_CAPS, FOR_UNDERSCORE or
FOR_DBL_UNDERSCORE
! will be defined. These are the most common naming conventions
! - The macro IN_BETWEEN is defined or undefined so that string
!   arguments can be properly passed
! - The macro FOR_CALL is defined to capture the correct calling
!   convention vis-a-vis stack clean-up
! - The values of these macros are stored in a file "ftcl_conventions.h"
!
! If the program fails, it will need to be expanded, as that is an
! indication that this particular combination of Fortran and C
! compilers is not yet supported.
!
program probe

character(len=7) :: first  = 'Fortran'
character(len=3) :: second = 'Tcl'

call probe_c( first, second )

end program probe

- probe_c.c -
/* probe_c.c --
 * Companion to the file probe.f90. Together they form a program
 * that will write a header file with the right macros for
 * setting up the interface between Fortran and C.
 *
 */

#include 
#include 

/* probe_c --
   Plainly named version
*/

void probe_c( char *first, int len_first, char *second, int len_second ) {

FILE *outfile ;

outfile = fopen( "ftcl_conventions.h", "w" ) ;

fprintf( outfile, "#define FOR_ALL_LOWER\n" ) ;
fprintf( outfile, "#define FOR_CALL\n" ) ;

/* If hidden length argument in between, then len_first must be 7 */
if ( len_first == 7 ) {
fprintf( outfile, "#define IN_BETWEEN\n" ) ;
} else if ( (int) second == 7 ) {
fprintf( outfile, "#undef IN_BETWEEN\n" ) ;
} else {
fprintf( stderr, "Unknown expected calling convention - assuming
NOT IN_BETWEEN!\n" ) ;
fprintf( outfile, "#undef IN_BETWEEN\n" ) ;
}

fclose( outfile ) ;
}

/* PROBE_C --
   All capitals version - possibly __stdcall too
*/
#ifdef _MSC_VER
#define FOR_CALL __stdcall
#else
#define FOR_CALL
#endif

void FOR_CALL PROBE_C( char *first, int len_first, char *second, int
len_second ) {

FILE *outfile ;

outfile = fopen( "ftcl_conventions.h", "w" ) ;

fprintf( outfile, "#define FOR_ALL_CAPS\n" ) ;
#ifdef _MSC_VER
fprintf( outfile, "#define FOR_C

Re: [CMake] Generating source code packages with Windows line endings

[Arjen Markus]

> 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 endings.
> Notepad.
>
> You may think I'm joking but it becomes surprisingly annoying to open an
> e.g.
> CMakeLists file in Notepad and have it be unreadable so you have to open
> it
> up in another tool.
>
> Can't think of anything else I actually use that has that problem but
> the "default Windows editor" doesn't like them.
>

I have run into problems with UNIX line-endings in the
following circumstances:

- Batch files on Windows 95 (also 98?):
  My favourite Windows editor is normally set to produce UNIX-style
  output, but batch files under Windows 95 with UNIX line-endings
  seemed to be regarded as one single line. This is no longer a problem
  with Windows NT and XP.

- Visual Basic programs (VB 6 at least, do not know about VB.net):
  One typical example is that they can not read INI files with
  such line-endings. Probably other files are a problem too.

- Source-code control systems:
  They typically (?) seem to get confused when confronted with
  a file whose versions use different line-endings - each line
  will be regarded as changed then. (This can really mess up
  the change history!)

Undoubtedly there are other things, but these are what I can
come up with right now.

In general though, compilers for C, Fortran, Java, ... have
no problem at all. Also the generated programs can deal with
both types of line-endings.

Most editors - notepad is the notorious exception - under
Windows accept UNIX-style files too.

Regards,

Arjen
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] gfortran/CheckFortranFunctionExists.cmake issue with 2.6.0

[Arjen Markus]

>
> 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 Fortran experts here who care to comment) do
> you think this change to using "call" rather than "external" will work for
> most/all other fortran compilers?
>
> If so, I will put in the appropriate bug fix request for 2.6.1.
>

The external statement simply declares the name to be that of an
external symbol, instead of (possibly) an intrinsic function/subroutine.

I guess that it does not always lead to a required symbol in the resulting
program - hence the fact that gfortran accepts this.

To make it foolproof, you can use:

  external ${FUNCTION}
  call ${FUNCTION}()

(the name that is substituted for "FUNCTION" just might be
the name of an intrinsic function/routine that that compiler
defines - with the external statement you avoid even that
- remote - possibility).

Regards,

Arjen

___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] C++ and FORTRAN

[Arjen Markus]

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 Makefiles, everything works correctly; both the C++
main and the FORTRAN subroutines are correctly compiled and linked.
However, if I generate a visual studio 2008 project and try to build it
within the GUI, the FORTRAN object is not compiled. (I have to admit
nearly complete ignorance about how visual studio works so this is very
likely a case of operator error; but it looks like no compilation
directives are created for the FORTRAN source file.)
I attached some files which emulate my project. Any guidance would be
greatly appreciated.
 


Hi Allen,

perhaps the dependencies are not set correctly? Visual Studio (at least 
recent

versions) does not allow mixed-language projects, so everything is put in a
separate project. To get an executable, however, all projects must be built.

I have no experience with the "solution" files that CMake produces, but this
is a likely cause.

Regards,

Arjen
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Dealing with dll PATH on Windows

[Arjen Markus]

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 PATH).

What is the best way to accomplish generating a .slnenv file for each
generated .sln file?

It seems like this type of capability would greatly enhance the usability
of CMake for developers using Visual Studio.  Would this add-in make
sense as an enhancement to CMake?
 


What can it do that CMake doesn't already do? Nothing from a first look.
   



As far as I can tell, CMake does not currently do this.  When setting 
environment variables via $ENV{PATH}, these variables are only in effect 
during the CMake configuration and build file generation.  I need the 
variables to be in effect for the loaded solution file (When I run an 
executable from Visual Studio, I need PATH to be setup to find the required 
dlls).


There would probably be a way to accomplish this in CMake if it is possible to 
set registry entries from CMake.  I see that CMake can get registry entries; 
however, I do not see that there is a way to set registry entries.


Am I missing something?  Is there a way to set registry entries from CMake?
 

Having CMake set the necessary registry entries would not help with 
binary distributions of your product. I do not whether that is relevant

to you, but in general that would be a problem:
- Your clients may have the libraries installed in a different place
- They may have different versions
- They may lack the permissions to install libraries

Come to think of it:
They may lack the permissions to update the registry.

How does the tool you mention handle that sort of situations by the way?
(Mind you, I am not trying to be sceptical - it is just that I have
run into all manner such problems before and a simple solution
seems utopic)

Regards,

Arjen



___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Issue with CMAKE 2.6 and Windows.

[Arjen Markus]

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 these are not described (as far as I can tell)
   



The subsections immediately following that sentence describe them.  I've
added an explicit note to this effect.

-Brad

 


Hi Brad,

thanks, I suspected as much, but could not be sure.
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake