Re: [cmake-developers] [PATCH] Fix a few issues in FindHDF5 module

[Tim Gallagher]

Good catch! The version I patched against didn't have the 
HDF5_Fortran_HL_LIBRARY_NAMES_INIT variable at the time. There was only the 
HDF5_Fortran_LIBRARY_NAMES_INIT variable. 

I'm not sure which version of the code my original patch was against after this 
long. However, since I submitted my ticket in July of 2011, Will committed 
support for the HL libraries in August of 2011 with commit 
http://www.cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ad218e4 , which added 
the HDF5_Fortran_HL_LIBRARY_NAMES_INIT variable. Perhaps that commit was 
intended to reference/fix my ticket?

At any rate, since what I submitted wouldn't apply against the current version, 
it looks like this work supersedes that patch. 

Tim

- Original Message -
From: "Brad King" <brad.k...@kitware.com>
To: "tim gallagher" <tim.gallag...@gatech.edu>
Cc: cmake-developers@cmake.org, "Paul Romano" <paul.k.rom...@gmail.com>
Sent: Wednesday, September 2, 2015 11:16:34 AM
Subject: Re: [cmake-developers] [PATCH] Fix a few issues in FindHDF5 module

On 09/02/2015 11:07 AM, Tim Gallagher wrote:
> It looks like the 2nd commit you linked to does the same thing as
> my patch (add hdf5hl_fortran to the Fortran library list). 

Not quite.  It is:

> -set( HDF5_Fortran_HL_LIBRARY_NAMES_INIT hdf5hl_fortran
> +set( HDF5_Fortran_HL_LIBRARY_NAMES_INIT hdf5hl_fortran hdf5_hl

One can see hdf5hl_fortran was already in that list.

Your patch was:

> -set( HDF5_Fortran_LIBRARY_NAMES_INIT hdf5_fortran 
> ${HDF5_C_LIBRARY_NAMES_INIT} )
> +set( HDF5_Fortran_LIBRARY_NAMES_INIT hdf5_fortran hdf5hl_fortran 
> ${HDF5_C_LIBRARY_NAMES_INIT} )

which adds it to a different list, though perhaps the wrong one
since it is not for the _HL component.

-Brad

-- 

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-developers

Re: [cmake-developers] [PATCH] Fix a few issues in FindHDF5 module

[Tim Gallagher]

It looks like the 2nd commit you linked to does the same thing as my patch (add 
hdf5hl_fortran to the Fortran library list). 

So it should work fine and my patch is no longer needed. I will have to see if 
I have a project that still uses the HL library, it's been 4 years since I 
think I've used it. So it wasn't an outstanding issue for me -- I just wanted 
to help close out an open issue if they were related!

Thanks,

Tim

- Original Message -
From: "Brad King" <brad.k...@kitware.com>
To: "Tim Gallagher" <tim.gallag...@gatech.edu>
Cc: cmake-developers@cmake.org, "Paul Romano" <paul.k.rom...@gmail.com>
Sent: Wednesday, September 2, 2015 10:59:34 AM
Subject: Re: [cmake-developers] [PATCH] Fix a few issues in FindHDF5 module

On 09/02/2015 10:44 AM, Tim Gallagher wrote:
> I haven't followed the discussion on this issue, but how does it
> relate to the ticket I opened awhile ago?
> 
> http://public.kitware.com/Bug/view.php?id=12316

Sorry we missed that patch.

> It looks like it may supersede or fix that issue? If so, I guess
> the issue can be closed!

I've updated the issue with links to this thread and the fixes so
far.  Please check if it resolves the problem and comment in the
issue.  Otherwise we can look at taking your patch from there too.

Thanks,
-Brad

-- 

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-developers

Re: [cmake-developers] [PATCH] Fix a few issues in FindHDF5 module

[Tim Gallagher]

I haven't followed the discussion on this issue, but how does it relate to the 
ticket I opened awhile ago?

http://public.kitware.com/Bug/view.php?id=12316

It looks like it may supersede or fix that issue? If so, I guess the issue can 
be closed!

Tim

- Original Message -
From: "Brad King" 
To: "Paul Romano" 
Cc: cmake-developers@cmake.org
Sent: Wednesday, September 2, 2015 10:19:52 AM
Subject: Re: [cmake-developers] [PATCH] Fix a few issues in FindHDF5 module

On 08/31/2015 10:45 PM, Paul Romano wrote:
> Here is a set of three patches that breaks out the changes.

Thanks.  I've applied the first two:

 FindHDF5: Fix support for HL and Fortran_HL components
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=19e7db07

 FindHDF5: Add hdf5_hl to list of libraries to search for Fortran_HL
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f7f73df1

I've also drafted a find_program NAMES_PER_DIR option, merged
to 'next' for testing here:

 Merge topic 'find_program-NAMES_PER_DIR' into next
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2bc3f46b

Please look at basing work on commit 8ea7611b to use NAMES_PER_DIR
for FindHDF5.  Of course HDF5_PREFER_PARALLEL may also still be
needed in case both executables sit in the same directory.

Thanks,
-Brad
-- 

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-developers
-- 

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-developers

Re: [cmake-developers] Is there an official FindMKL module?

[Tim Gallagher]

It's possible this wasn't the final version we came up with, but it's also 
possible that it is the final version and that's why I never formally submitted 
it. Like I said, it was last touched in 2012 and I found these files on a 
colleague's backup drive! 

We can work on getting it fully functioning and submit it as an official module 
moving forward if you are willing/able to be a module maintainer with me on it. 
When you get time to work on it again, let me know and I'll see what I can do 
to help. I don't have a ton of time for it right now, but I will do what I can. 

We can take the development discussion off-list if you would like and set up a 
github for it so we can collaborate and get things moving along. 

Tim 

- Original Message -

From: Siebren Reker siebren.re...@gmail.com 
To: tim gallagher tim.gallag...@gatech.edu 
Cc: cmake-developers@cmake.org 
Sent: Friday, August 28, 2015 4:42:29 AM 
Subject: Re: [cmake-developers] Is there an official FindMKL module? 


Hi Tim, 




On Thu, Aug 27, 2015 at 7:32 PM, Tim Gallagher  tim.gallag...@gatech.edu  
wrote: 




Hi Siebren, 

I tried to link statically and it did not work for me, similar errors as to 
what you are getting. 





Ok, thank you for verifying 

blockquote


The way the macro is supposed to work -- it checks for the MKL link tool and if 
it is available, it uses and provides the libraries needed. If it is 
unavailable (or throws errors or whatever else the case may be), then FindBLAS 
reverts back to the way it handles MKL currently. 

/blockquote



Sound good to me. 

blockquote

I have attached the module that provides the interface to the MKL command line 
tool as well as the changed FindBLAS module that uses it. Major caveat here -- 
I have not used these since 2012, with one of the Intel 12.something compilers 
and CMake 2.8. I did a quick diff on the FindBLAS in the current version and 
the CMake 2.8 version and there's only very minor changes that shouldn't affect 
this working. If it turns out this is useful and close to functional, then we 
can work on getting it current. 

/blockquote



What you have sent feels 80% complete. It doesn't work out of the box, but I 
could hack some small changes in to get some things working. I won't have more 
time for this today, so here is what I've spotted so far, in case you want to 
continue on this now. 
- The calls to the macro (in FindBLAS.cmake) don't match with the macro input 
in GetIntelMKLInfo, maybe you were adding additional parameters for the mkl 
version and things such as integer representation, but hadn't gotten around to 
adding them in the macro? Removing them from FindBLAS.cmake allowed me to test 
further, but I can see that some more inputs to the MKL command line tool need 
to be supported. 
- The static flag was giving errors on the command line, an easy fix was to use 
the same syntax as for the other flags: 

list(APPEND mkl_tool_opts --linking=static) 
- The stripping off of the additional libraries is very nice, but the regex for 
the math library is overzealous: -lm matches all -lmkl_intel_thread etc. 
- The grouping of the static libraries results in them being parsed as 
static_flags, which leaves the final mkl_libs empty. Even though all 
information has correctly been extracted, the macro then reports failure. 
- I was not sure about the tool1 vs tool2 differences, was this also 
intermediate work on getting the mkl_version information in? 


I'll have more time to look at this next week, thanks for sharing this. 


best, 
Siebren 






-- 

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-developers

Re: [cmake-developers] Is there an official FindMKL module?

[Tim Gallagher]

Siebren, 

We've never really used static linking so I am not sure if it ever really 
worked. I can try and let you know. 

However, I'm having flashbacks here to something I thought I had done before. I 
dug through my emails and back in 2012 I had signed up to maintain a new module 
that provided a macro to interface with the MKL tool and generated the proper 
linking based on what it reported. My colleague and I had written it because we 
were tired of the difficulties in the current modules. This new module provided 
a macro and the FindBLAS and FindLAPACK modules would call the macro to get the 
link information. 

I got push access to create the topic branch but then I don't know what 
happened. I don't know if I never pushed it, or it never got 
tested/approved/checked, no clue. I actually still have all of the modules and 
changes I had made, but it was in version 2.8. I wish I could remember if I had 
actually pushed it to CMake or not, but I really don't remember why it never 
happened. 

So anyway, now that we're discussing it again, if the CMake community wants the 
MKL support improved, I can dust off the modules and see what it would take to 
get it officially in the stream. 

Tim 

- Original Message -

From: Siebren Reker siebren.re...@gmail.com 
To: tim gallagher tim.gallag...@gatech.edu 
Cc: cmake-developers@cmake.org 
Sent: Thursday, August 27, 2015 6:32:17 AM 
Subject: Re: [cmake-developers] Is there an official FindMKL module? 


Hi Tim, 


Quick add-on to my previous email. With BLA_STATIC ON, I see from the 
CMakeError.log that the static libraries ARE found (I was trusting the), but 
the linking of the test program goes wrong: 
undefined reference to `mkl_blas_sgemv` 
But that function IS implemented in one of the three libraries that is found, 
in my case in libmkl_sequential.a 


So this is probably a linking/ library ordering error. 
Indeed, Intel fora and the link advisor I mentioned earlier also report the 
need for grouping these as in 
-Wl,--start-group ${MKLROOT}/lib/intel64/libmkl_intel_lp64.a 
${MKLROOT}/lib/intel64/libmkl_core.a ${MKLROOT}/lib/intel64/libmkl_sequential.a 
-Wl,--end-group 



Is my understanding correct, and can this be fixed? 


kind regards, 
Siebren 




On Thu, Aug 27, 2015 at 11:50 AM, Siebren Reker  siebren.re...@gmail.com  
wrote: 



Hi Tim, 


That is encouraging, thanks. I went back and tried harder this time, when I 
specified BLA_VENDOR precisely and leave BLA_STATIC off, I am able to get to 
the correct versions. 
In the very same directory where the shared libraries are found, I have the 
static libraries as well, but BLA_STATIC on in that case does not find the 
libraries. 


I've read up a bit on this now, so maybe the following information is helpful: 
This is a CMake 3.3.0 installation 
My project has both C and Fortran enabled 
I call it as follows: 


set( BLA_STATIC ON) 
set( BLA_VENDOR Intel10_64lp_seq) 

find_package( BLAS ) 


Is BLA_STATIC = ON working for you? 


A separate question I have is if the linker command that will be produced 
afterwards is of course different from the one supplied by Intel in their tool. 
Should that not concern me? 


kind regards, 
Siebren 






On Wed, Aug 26, 2015 at 4:59 PM, Tim Gallagher  tim.gallag...@gatech.edu  
wrote: 

blockquote


We sometime struggled to get it working, but we never had to resort to using a 
FindMKL -- FindBLAS and FindLAPACK work just fine for us, provided we do things 
correctly. 

So long as we have sourced the mklvars script that ships with Intel MKL and we 
put: 

BLA_VENDOR =Intel10_64lp_seq ccmake /path/to/source/dir 
Then everything works fine and we have no issues. So we have to give CMake a 
hint that we want to pick the Intel version rather than the generic one (and 
we're using the sequential, 64bit MKL -- if you look in FindBLAS you can see 
other vendor types). 

Have you had things fail when you setup your environment variables using the 
scripts Intel provides and when you set the BLA_VENDOR hint as an environment 
variable? 

Tim 



From: Siebren Reker  siebren.re...@gmail.com  
To: cmake-developers@cmake.org 
Sent: Wednesday, August 26, 2015 10:18:44 AM 
Subject: [cmake-developers] Is there an official FindMKL module? 




Hello, 


I am using the find_package() command to load settings for the Intel Math 
Kernel Library (MKL). This works through a custom FindMKL.cmake module that 
I've made for myself. 


However, when looking at: 
https://software.intel.com/en-us/articles/intel-mkl-link-line-advisor/ 

I can tell that what I've done is likely only correct for my specific case, and 
certainly not robust against library version changes and various other changes 
(openmp, static vs dynamic linking etc.). 



Instead of a FindMKL.cmake module, an alternative is to have MKL be discovered 
in the FindBLAS or FindLAPACK modules, but according to what I can find on the 
bug tracker, that solution is also in a fairly broken state: 

Bug 14138: http

Re: [cmake-developers] Is there an official FindMKL module?

[Tim Gallagher]

Hi Siebren, 

I tried to link statically and it did not work for me, similar errors as to 
what you are getting. 

The way the macro is supposed to work -- it checks for the MKL link tool and if 
it is available, it uses and provides the libraries needed. If it is 
unavailable (or throws errors or whatever else the case may be), then FindBLAS 
reverts back to the way it handles MKL currently. 

I have attached the module that provides the interface to the MKL command line 
tool as well as the changed FindBLAS module that uses it. Major caveat here -- 
I have not used these since 2012, with one of the Intel 12.something compilers 
and CMake 2.8. I did a quick diff on the FindBLAS in the current version and 
the CMake 2.8 version and there's only very minor changes that shouldn't affect 
this working. If it turns out this is useful and close to functional, then we 
can work on getting it current. 

Tim 

- Original Message -

From: Siebren Reker siebren.re...@gmail.com 
To: tim gallagher tim.gallag...@gatech.edu 
Cc: cmake-developers@cmake.org 
Sent: Thursday, August 27, 2015 11:16:34 AM 
Subject: Re: [cmake-developers] Is there an official FindMKL module? 


Hi Tim, 



On Thu, Aug 27, 2015 at 4:32 PM, Tim Gallagher  tim.gallag...@gatech.edu  
wrote: 




Siebren, 

We've never really used static linking so I am not sure if it ever really 
worked. I can try and let you know. 




Could you please do so? Just to verify that I'm not doing something obviously 
wrong 

blockquote


However, I'm having flashbacks here to something I thought I had done before. I 
dug through my emails and back in 2012 I had signed up to maintain a new module 
that provided a macro to interface with the MKL tool and generated the proper 
linking based on what it reported. My colleague and I had written it because we 
were tired of the difficulties in the current modules. This new module provided 
a macro and the FindBLAS and FindLAPACK modules would call the macro to get the 
link information. 

/blockquote



Sounds clean, but are you sure the tool is always available? 

blockquote


I got push access to create the topic branch but then I don't know what 
happened. I don't know if I never pushed it, or it never got 
tested/approved/checked, no clue. I actually still have all of the modules and 
changes I had made, but it was in version 2.8. I wish I could remember if I had 
actually pushed it to CMake or not, but I really don't remember why it never 
happened. 

So anyway, now that we're discussing it again, if the CMake community wants the 
MKL support improved, I can dust off the modules and see what it would take to 
get it officially in the stream. 

/blockquote


I'd be more than happy to test this. I've found a number of hits on Google for 
FindMKL.cmake files. I certainly wasn't alone in having trouble to get this to 
work (doesn't mean much of course). 


best, 
Siebren 

blockquote


Tim 



From: Siebren Reker  siebren.re...@gmail.com  
To: tim gallagher  tim.gallag...@gatech.edu  
Cc: cmake-developers@cmake.org 
Sent: Thursday, August 27, 2015 6:32:17 AM 
Subject: Re: [cmake-developers] Is there an official FindMKL module? 




Hi Tim, 


Quick add-on to my previous email. With BLA_STATIC ON, I see from the 
CMakeError.log that the static libraries ARE found (I was trusting the), but 
the linking of the test program goes wrong: 
undefined reference to `mkl_blas_sgemv` 
But that function IS implemented in one of the three libraries that is found, 
in my case in libmkl_sequential.a 


So this is probably a linking/ library ordering error. 
Indeed, Intel fora and the link advisor I mentioned earlier also report the 
need for grouping these as in 
-Wl,--start-group ${MKLROOT}/lib/intel64/libmkl_intel_lp64.a 
${MKLROOT}/lib/intel64/libmkl_core.a ${MKLROOT}/lib/intel64/libmkl_sequential.a 
-Wl,--end-group 



Is my understanding correct, and can this be fixed? 


kind regards, 
Siebren 




On Thu, Aug 27, 2015 at 11:50 AM, Siebren Reker  siebren.re...@gmail.com  
wrote: 

blockquote

Hi Tim, 


That is encouraging, thanks. I went back and tried harder this time, when I 
specified BLA_VENDOR precisely and leave BLA_STATIC off, I am able to get to 
the correct versions. 
In the very same directory where the shared libraries are found, I have the 
static libraries as well, but BLA_STATIC on in that case does not find the 
libraries. 


I've read up a bit on this now, so maybe the following information is helpful: 
This is a CMake 3.3.0 installation 
My project has both C and Fortran enabled 
I call it as follows: 


set( BLA_STATIC ON) 
set( BLA_VENDOR Intel10_64lp_seq) 

find_package( BLAS ) 


Is BLA_STATIC = ON working for you? 


A separate question I have is if the linker command that will be produced 
afterwards is of course different from the one supplied by Intel in their tool. 
Should that not concern me? 


kind regards, 
Siebren 






On Wed, Aug 26, 2015 at 4:59 PM, Tim Gallagher  tim.gallag...@gatech.edu

Re: [cmake-developers] Is there an official FindMKL module?

[Tim Gallagher]

We sometime struggled to get it working, but we never had to resort to using a 
FindMKL -- FindBLAS and FindLAPACK work just fine for us, provided we do things 
correctly. 

So long as we have sourced the mklvars script that ships with Intel MKL and we 
put: 

BLA_VENDOR =Intel10_64lp_seq ccmake /path/to/source/dir 
Then everything works fine and we have no issues. So we have to give CMake a 
hint that we want to pick the Intel version rather than the generic one (and 
we're using the sequential, 64bit MKL -- if you look in FindBLAS you can see 
other vendor types). 

Have you had things fail when you setup your environment variables using the 
scripts Intel provides and when you set the BLA_VENDOR hint as an environment 
variable? 

Tim 

- Original Message -

From: Siebren Reker siebren.re...@gmail.com 
To: cmake-developers@cmake.org 
Sent: Wednesday, August 26, 2015 10:18:44 AM 
Subject: [cmake-developers] Is there an official FindMKL module? 


Hello, 


I am using the find_package() command to load settings for the Intel Math 
Kernel Library (MKL). This works through a custom FindMKL.cmake module that 
I've made for myself. 


However, when looking at: 
https://software.intel.com/en-us/articles/intel-mkl-link-line-advisor/ 

I can tell that what I've done is likely only correct for my specific case, and 
certainly not robust against library version changes and various other changes 
(openmp, static vs dynamic linking etc.). 



Instead of a FindMKL.cmake module, an alternative is to have MKL be discovered 
in the FindBLAS or FindLAPACK modules, but according to what I can find on the 
bug tracker, that solution is also in a fairly broken state: 

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

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

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



Google tells me that many people have (like me) created their own FindMKL.cmake 
module, which are equally specific and tailored. 



Is anyone aware of a more official FindMKL module available somewhere, or at 
least something that is being somewhat maintained, either by someone at Kitware 
or Intel? Or of a plan to develop something like that? 



kind regards, 
Siebren Reker 
-- 

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-developers 
-- 

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-developers

Re: [cmake-developers] Assembly/preprocessed targets for Fortran

[Tim Gallagher]

Sorry about the TABs, I guess emacs defaults to it and I never noticed.

I have attached an updated patch where the tabs are removed and the test for 
CMAKE_EXPORT_COMPILE_COMMANDS is also removed. 

Tim

- Original Message -
From: Brad King brad.k...@kitware.com
To: tim gallagher tim.gallag...@gatech.edu, cmake-developers@cmake.org
Sent: Wednesday, November 5, 2014 11:26:26 AM
Subject: Re: [cmake-developers] Assembly/preprocessed targets for Fortran

On 11/04/2014 06:37 PM, Tim Gallagher wrote:
 I have attached the patch to enable the targets for Fortran.

Thanks.  Please update it to avoid using hard TABs for indentation.
Also in the CompileCommandOutput test hunk:

 -project (CompileCommandOutput CXX)
 +project (CompileCommandOutput)
 +enable_language(CXX)
 +enable_language(Fortran)

there are a couple problems:

- By removing any explicit languages from the project() call
  it will enable C and CXX by default.  Use NONE to suppress
  that.

- We cannot assume that Fortran will be available.  The other
  Fortran tests are all guarded by availability of a Fortran
  compiler.

The test for CMAKE_EXPORT_COMPILE_COMMANDS was already missing
for C, so let's just skip Fortran for the test too.  They can
be fixed together as a separate change later.

Thanks,
-Brad

From ff4a9ffe8a03822e87bc7d26a144ab2ca1e1ced6 Mon Sep 17 00:00:00 2001
From: Tim Gallagher tim.gallag...@gatech.edu
Date: Wed, 5 Nov 2014 12:07:33 -0500
Subject: [PATCH] Enabled the generation of assembly and preprocessor targets 
 for Fortran.

The Makefile generator has been updated to create .i and .s targets for
Fortran files. The variable lang_is_c_or_cxx has been changed and split
into variables to indicate languages which can be preprocessed, generate
assembly, or have their compile commands output. This should allow for
more fine-grained control over these behaviors if languages can handle
some or all of those features.

The modules have been updated to set the CMAKE_Fortran_CREATE_* flags
required. This has been tested successfully on Intel and GNU suites but
remains untested for the others. The assumption is that other Fortran
compilers handle the options the same way their respective C/C++
compilers handle it.

Testing has been added to the FortranOnly test to verify the
preprocessor works. This test behaves the same as the test in the
Complex test for C++. There is no test for assembly in C/C++ however, so
there is not one in Fortran either.
---
 Modules/Compiler/GNU-Fortran.cmake   |5 
 Modules/Compiler/HP-Fortran.cmake|3 +++
 Modules/Compiler/Intel-Fortran.cmake |3 +++
 Modules/Compiler/PGI-Fortran.cmake   |5 
 Modules/Compiler/SunPro-Fortran.cmake|3 +++
 Modules/Compiler/XL-Fortran.cmake|4 ---
 Modules/Platform/HP-UX-HP-Fortran.cmake  |3 +++
 Modules/Platform/IRIX.cmake  |8 ++
 Modules/Platform/IRIX64.cmake|9 +++
 Source/cmLocalUnixMakefileGenerator3.cxx |   43 +-
 Source/cmMakefileTargetGenerator.cxx |   13 ++---
 Tests/FortranOnly/CMakeLists.txt |   22 +++
 Tests/FortranOnly/test_preprocess.cmake  |7 +
 13 files changed, 91 insertions(+), 37 deletions(-)
 create mode 100644 Tests/FortranOnly/test_preprocess.cmake

diff --git a/Modules/Compiler/GNU-Fortran.cmake b/Modules/Compiler/GNU-Fortran.cmake
index 313ccbd..dfd7927 100644
--- a/Modules/Compiler/GNU-Fortran.cmake
+++ b/Modules/Compiler/GNU-Fortran.cmake
@@ -8,10 +8,5 @@ set(CMAKE_Fortran_FORMAT_FREE_FLAG -ffree-form)
 set(CMAKE_Fortran_FLAGS_MINSIZEREL_INIT -Os)
 set(CMAKE_Fortran_FLAGS_RELEASE_INIT -O3)
 
-# We require updates to CMake C++ code to support preprocessing rules
-# for Fortran.
-set(CMAKE_Fortran_CREATE_PREPROCESSED_SOURCE)
-set(CMAKE_Fortran_CREATE_ASSEMBLY_SOURCE)
-
 # Fortran-specific feature flags.
 set(CMAKE_Fortran_MODDIR_FLAG -J)
diff --git a/Modules/Compiler/HP-Fortran.cmake b/Modules/Compiler/HP-Fortran.cmake
index cc56b46..ad821ab 100644
--- a/Modules/Compiler/HP-Fortran.cmake
+++ b/Modules/Compiler/HP-Fortran.cmake
@@ -1,3 +1,6 @@
 set(CMAKE_Fortran_VERBOSE_FLAG -v)
 set(CMAKE_Fortran_FORMAT_FIXED_FLAG +source=fixed)
 set(CMAKE_Fortran_FORMAT_FREE_FLAG +source=free)
+
+set(CMAKE_Fortran_CREATE_ASSEMBLY_SOURCE CMAKE_Fortran_COMPILER DEFINES FLAGS -S SOURCE -o ASSEMBLY_SOURCE)
+set(CMAKE_Fortran_CREATE_PREPROCESSED_SOURCE CMAKE_Fortran_COMPILER DEFINES FLAGS -E SOURCE  PREPROCESSED_SOURCE)
diff --git a/Modules/Compiler/Intel-Fortran.cmake b/Modules/Compiler/Intel-Fortran.cmake
index 84f6182..9ebac5a 100644
--- a/Modules/Compiler/Intel-Fortran.cmake
+++ b/Modules/Compiler/Intel-Fortran.cmake
@@ -7,3 +7,6 @@ set(CMAKE_Fortran_MODDIR_FLAG -module )
 set(CMAKE_Fortran_VERBOSE_FLAG -v)
 set(CMAKE_Fortran_FORMAT_FIXED_FLAG -fixed)
 set(CMAKE_Fortran_FORMAT_FREE_FLAG -free)
+
+set(CMAKE_Fortran_CREATE_PREPROCESSED_SOURCE CMAKE_Fortran_COMPILER DEFINES FLAGS -E SOURCE

Re: [cmake-developers] Assembly/preprocessed targets for Fortran

[Tim Gallagher]

Here's to hoping 3rd time's the charm...

Also, what version of gfortran do you have that requires both -E and -cpp to do 
the preprocessing? I don't need that on my version, I'm using 4.7.1. There may 
need to be more sophisticated logic in the Compiler module to add -cpp to the 
command line for versions that require it.

Tim

- Original Message -
From: Brad King brad.k...@kitware.com
To: Tim Gallagher tim.gallag...@gatech.edu
Cc: cmake-developers@cmake.org
Sent: Wednesday, November 5, 2014 12:55:04 PM
Subject: Re: [cmake-developers] Assembly/preprocessed targets for Fortran

On 11/05/2014 12:14 PM, Tim Gallagher wrote:
 I have attached an updated patch

Thanks!  Please split this into two patches.  The first one should
do the refactoring of the variable name and corresponding logic
with no functionality changes.  The second one can add the Fortran
feature.

Also please keep C++ source lines to 79 columns or below.

The FortranOnly test fails for me with:

 f95: error: gfortran does not support -E without -cpp

because it doesn't enable preprocessing for lower-case extensions.
You'll need to add another .F test source with an upper-case
extension to activate preprocessing without special flags.

Thanks,
-Brad

From 4d7eafbcf923fda5f541bc9e5fbdb1004e29ecf1 Mon Sep 17 00:00:00 2001
From: Tim Gallagher tim.gallag...@gatech.edu
Date: Wed, 5 Nov 2014 13:37:25 -0500
Subject: [PATCH] Refactored the checks for language-specific targets and
 export compile cmds

The checks are now split into languages that are able to generate
assembly listings, languages that are able to generate
preprocessed listings and languages that are able to export the
compile commands.
---
 Source/cmLocalUnixMakefileGenerator3.cxx |   44 +-
 Source/cmMakefileTargetGenerator.cxx |   14 +++---
 2 files changed, 35 insertions(+), 23 deletions(-)

diff --git a/Source/cmLocalUnixMakefileGenerator3.cxx b/Source/cmLocalUnixMakefileGenerator3.cxx
index c18e027..e6b125b 100644
--- a/Source/cmLocalUnixMakefileGenerator3.cxx
+++ b/Source/cmLocalUnixMakefileGenerator3.cxx
@@ -314,37 +314,43 @@ void cmLocalUnixMakefileGenerator3::WriteLocalMakefile()
  lo-first.c_str(), lo-second);

 // Check whether preprocessing and assembly rules make sense.
-// They make sense only for C and C++ sources.
-bool lang_is_c_or_cxx = false;
+// They make sense only for C/C++ sources.
+bool lang_has_preprocessor = false;
+bool lang_has_assembly = false;
+
 for(std::vectorLocalObjectEntry::const_iterator ei =
   lo-second.begin(); ei != lo-second.end(); ++ei)
   {
-  if(ei-Language == C || ei-Language == CXX)
+  if(ei-Language == C ||
+ ei-Language == CXX)
 {
-lang_is_c_or_cxx = true;
+   // Right now, C/C++ have both a preprocessor and the
+   // ability to generate assembly code
+lang_has_preprocessor = true;
+lang_has_assembly = true;
 break;
 }
   }

 // Add convenience rules for preprocessed and assembly files.
-if(lang_is_c_or_cxx  (do_preprocess_rules || do_assembly_rules))
+if(lang_has_preprocessor  do_preprocess_rules)
   {
   std::string::size_type dot_pos = lo-first.rfind(.);
   std::string base = lo-first.substr(0, dot_pos);
-  if(do_preprocess_rules)
-{
-this-WriteObjectConvenienceRule(
-  ruleFileStream, target to preprocess a source file,
-  (base + .i).c_str(), lo-second);
-  lo-second.HasPreprocessRule = true;
-}
-  if(do_assembly_rules)
-{
-this-WriteObjectConvenienceRule(
-  ruleFileStream, target to generate assembly for a file,
-  (base + .s).c_str(), lo-second);
-  lo-second.HasAssembleRule = true;
-}
+  this-WriteObjectConvenienceRule(
+ruleFileStream, target to preprocess a source file,
+   (base + .i).c_str(), lo-second);
+  lo-second.HasPreprocessRule = true;
+  }
+
+if(lang_has_assembly  do_assembly_rules)
+  {
+  std::string::size_type dot_pos = lo-first.rfind(.);
+  std::string base = lo-first.substr(0, dot_pos);
+  this-WriteObjectConvenienceRule(
+   ruleFileStream, target to generate assembly for a file,
+   (base + .s).c_str(), lo-second);
+  lo-second.HasAssembleRule = true;
   }
 }

diff --git a/Source/cmMakefileTargetGenerator.cxx b/Source/cmMakefileTargetGenerator.cxx
index 1adcb8a..6b98b35 100644
--- a/Source/cmMakefileTargetGenerator.cxx
+++ b/Source/cmMakefileTargetGenerator.cxx
@@ -702,7 +702,13 @@ cmMakefileTargetGenerator

   vars.Defines = definesString.c_str();

-  bool lang_is_c_or_cxx = ((lang == C) || (lang == CXX));
+  // At the moment, it is assumed that C/C++ have both
+  // assembly and preprocessor capabilities. The same is true for the
+  // ability to export compile commands
+  bool lang_has_preprocessor = ((lang == C

[cmake-developers] Assembly/preprocessed targets for Fortran

[Tim Gallagher]

Hi all,

I was trying to generate the assembly listing for some Fortran code and while 
searching for how to do it in CMake, I came across an email thread from a few 
years ago from somebody asking how to do it in C/C++ by running `make 
file.s`. I vaguely remembered knowing this at one point so I tried it with my 
Fortran source and those targets didn't exist. I was about to get on the 
mailing list to ask if anybody else came across this problem, but first I 
clicked through the email thread and there was a message that I sent out 
basically saying Hey, this doesn't work for Fortran -- is there any way that 
could be fixed? 

I guess I send too many emails and forgot about that. 

At any rate, I looked through the CMake source code and it didn't seem that 
hard to make it work correctly for Fortran also. I made the changes on my local 
branch and it works great for the Intel and GNU compiler suites on Linux (those 
are the only ones I have access to). I modified the other compiler modules on 
the assumption that the options were the same for C, C++ and Fortran source 
files (which is true for Intel and GNU). 

I have a couple questions:

1) There are only 2 lines that needed changing in the C++ source to enable the 
functionality. In both places it is adding Fortran to the check for C and 
C++ when assigning the `lang_is_c_or_cxx` variable. That variable name should 
change, but is `lang_is_c_or_cxx_or_fortran` really a good name? Seems a bit 
long, but it's not used often and that makes it very clear what it is storing. 

2) How would/could I go about testing the changes to the other 
compilers/platforms that I do not have personal access to? I'd like to verify 
the options work, and that I didn't miss any compilers/platforms.  

Let me know if this is something that anybody else is interested in and I can 
send out a patch or something to get it tested. If there is interest in 
including the update, I can send a patch if that's easier than setting me up 
for push access -- the changes are really minor.

Thanks,

Tim
-- 

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-developers

Re: [cmake-developers] Assembly/preprocessed targets for Fortran

[Tim Gallagher]

Hi Brad,

Thanks for the info. 

What does the CMAKE_EXPORT_COMPILE_COMMANDS do? Or maybe more precisely, what 
output should I expect when it is set to ON instead of OFF? I tried it with my 
changes and nothing breaks, but I also don't see any difference in outputs with 
it set to ON so maybe I am missing something. 

I'll also dig into the testing to see what it would take to add the coverage.

Thanks again,

Tim

- Original Message -
From: Brad King brad.k...@kitware.com
To: tim gallagher tim.gallag...@gatech.edu, cmake-developers@cmake.org
Sent: Tuesday, November 4, 2014 3:45:39 PM
Subject: Re: [cmake-developers] Assembly/preprocessed targets for Fortran

On 11/04/2014 03:19 PM, Tim Gallagher wrote:
 I looked through the CMake source code and it didn't seem that
 hard to make it work correctly for Fortran also. I made the
 changes on my local branch and it works great for the Intel
 and GNU compiler suites on Linux (those are the only ones I
 have access to). I modified the other compiler modules on the
 assumption that the options were the same for C, C++ and Fortran
 source files (which is true for Intel and GNU).

Great, thanks for looking into this.

 adding Fortran to the check for C and C++ when assigning
 the `lang_is_c_or_cxx` variable. That variable name should change

Perhaps lang_has_preprocessor?  You could also add

 bool const lang_has_assembly = lang_has_preprocessor;

and update each use of the variable to use the proper name.
In the future the answer may not be the same.

Watch out for other uses of lang_is_c_or_cxx, like for
CMAKE_EXPORT_COMPILE_COMMANDS.  Check if each use case
makes sense for Fortran.

 2) How would/could I go about testing the changes to the other
 compilers/platforms that I do not have personal access to?

You could look at adding coverage of these make targets to
the test suite under the proper conditions.  That will likely
be a harder change than your main fix though.

Thanks,
-Brad

-- 

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-developers

Re: [cmake-developers] Assembly/preprocessed targets for Fortran

[Tim Gallagher]

Scratch that, I found it. Wasn't looking in the right places!

The export command works for Fortran, so that's not an issue.

I'll take a look at the testing and see if I can get that going. I'll send 
along a patch when I get it worked out.

Thanks,

Tim

- Original Message -
From: Tim Gallagher tim.gallag...@gatech.edu
To: Brad King brad.k...@kitware.com
Cc: cmake-developers@cmake.org
Sent: Tuesday, November 4, 2014 4:08:49 PM
Subject: Re: [cmake-developers] Assembly/preprocessed targets for Fortran

Hi Brad,

Thanks for the info. 

What does the CMAKE_EXPORT_COMPILE_COMMANDS do? Or maybe more precisely, what 
output should I expect when it is set to ON instead of OFF? I tried it with my 
changes and nothing breaks, but I also don't see any difference in outputs with 
it set to ON so maybe I am missing something. 

I'll also dig into the testing to see what it would take to add the coverage.

Thanks again,

Tim

- Original Message -
From: Brad King brad.k...@kitware.com
To: tim gallagher tim.gallag...@gatech.edu, cmake-developers@cmake.org
Sent: Tuesday, November 4, 2014 3:45:39 PM
Subject: Re: [cmake-developers] Assembly/preprocessed targets for Fortran

On 11/04/2014 03:19 PM, Tim Gallagher wrote:
 I looked through the CMake source code and it didn't seem that
 hard to make it work correctly for Fortran also. I made the
 changes on my local branch and it works great for the Intel
 and GNU compiler suites on Linux (those are the only ones I
 have access to). I modified the other compiler modules on the
 assumption that the options were the same for C, C++ and Fortran
 source files (which is true for Intel and GNU).

Great, thanks for looking into this.

 adding Fortran to the check for C and C++ when assigning
 the `lang_is_c_or_cxx` variable. That variable name should change

Perhaps lang_has_preprocessor?  You could also add

 bool const lang_has_assembly = lang_has_preprocessor;

and update each use of the variable to use the proper name.
In the future the answer may not be the same.

Watch out for other uses of lang_is_c_or_cxx, like for
CMAKE_EXPORT_COMPILE_COMMANDS.  Check if each use case
makes sense for Fortran.

 2) How would/could I go about testing the changes to the other
 compilers/platforms that I do not have personal access to?

You could look at adding coverage of these make targets to
the test suite under the proper conditions.  That will likely
be a harder change than your main fix though.

Thanks,
-Brad

-- 

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-developers
-- 

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-developers

Re: [cmake-developers] Assembly/preprocessed targets for Fortran

[Tim Gallagher]

Hi Brad,

I have attached the patch to enable the targets for Fortran. It includes 
updates to 2 tests to make sure that it works as expected. Both of the tests 
pass for me with Intel and GNU but that's all I have access to.

Let me know if I messed anything up or if you have any suggestions on things I 
should have done better/differently so I know to do it correctly next time I 
have a patch.

Thanks,

Tim

- Original Message -
From: Tim Gallagher tim.gallag...@gatech.edu
To: tim gallagher tim.gallag...@gatech.edu
Cc: cmake-developers@cmake.org, Brad King brad.k...@kitware.com
Sent: Tuesday, November 4, 2014 4:12:01 PM
Subject: Re: [cmake-developers] Assembly/preprocessed targets for Fortran

Scratch that, I found it. Wasn't looking in the right places!

The export command works for Fortran, so that's not an issue.

I'll take a look at the testing and see if I can get that going. I'll send 
along a patch when I get it worked out.

Thanks,

Tim

- Original Message -
From: Tim Gallagher tim.gallag...@gatech.edu
To: Brad King brad.k...@kitware.com
Cc: cmake-developers@cmake.org
Sent: Tuesday, November 4, 2014 4:08:49 PM
Subject: Re: [cmake-developers] Assembly/preprocessed targets for Fortran

Hi Brad,

Thanks for the info. 

What does the CMAKE_EXPORT_COMPILE_COMMANDS do? Or maybe more precisely, what 
output should I expect when it is set to ON instead of OFF? I tried it with my 
changes and nothing breaks, but I also don't see any difference in outputs with 
it set to ON so maybe I am missing something. 

I'll also dig into the testing to see what it would take to add the coverage.

Thanks again,

Tim

- Original Message -
From: Brad King brad.k...@kitware.com
To: tim gallagher tim.gallag...@gatech.edu, cmake-developers@cmake.org
Sent: Tuesday, November 4, 2014 3:45:39 PM
Subject: Re: [cmake-developers] Assembly/preprocessed targets for Fortran

On 11/04/2014 03:19 PM, Tim Gallagher wrote:
 I looked through the CMake source code and it didn't seem that
 hard to make it work correctly for Fortran also. I made the
 changes on my local branch and it works great for the Intel
 and GNU compiler suites on Linux (those are the only ones I
 have access to). I modified the other compiler modules on the
 assumption that the options were the same for C, C++ and Fortran
 source files (which is true for Intel and GNU).

Great, thanks for looking into this.

 adding Fortran to the check for C and C++ when assigning
 the `lang_is_c_or_cxx` variable. That variable name should change

Perhaps lang_has_preprocessor?  You could also add

 bool const lang_has_assembly = lang_has_preprocessor;

and update each use of the variable to use the proper name.
In the future the answer may not be the same.

Watch out for other uses of lang_is_c_or_cxx, like for
CMAKE_EXPORT_COMPILE_COMMANDS.  Check if each use case
makes sense for Fortran.

 2) How would/could I go about testing the changes to the other
 compilers/platforms that I do not have personal access to?

You could look at adding coverage of these make targets to
the test suite under the proper conditions.  That will likely
be a harder change than your main fix though.

Thanks,
-Brad

-- 

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-developers
From 03f06808a086dd767e3414a5a1e5fc14ecc0a0e3 Mon Sep 17 00:00:00 2001
From: Tim Gallagher tim.gallag...@gatech.edu
Date: Tue, 4 Nov 2014 18:26:22 -0500
Subject: [PATCH] Enabled the generation of assembly and preprocessor targets
 for Fortran.

The Makefile generator has been updated to create .i and .s targets for
Fortran files. The variable lang_is_c_or_cxx has been changed and split
into variables to indicate languages which can be preprocessed, generate
assembly, or have their compile commands output. This should allow for
more fine-grained control over these behaviors if languages can handle
some or all of those features.

The modules have been updated to set the CMAKE_Fortran_CREATE_* flags
required. This has been tested successfully on Intel and GNU suites but
remains untested for the others. The assumption is that other Fortran
compilers handle the options the same way their respective C/C++
compilers handle it.

Testing has been added to the FortranOnly test to verify the
preprocessor works. This test behaves the same as the test in the
Complex test for C++. There is no test for assembly in C/C++ however, so
there is not one in Fortran

Re: [cmake-developers] New module introduction

[Tim Gallagher]

I have a question for the developers list since I'm (brand) new to this:

Right now, the FindBLAS and FindLAPACK will not find Intel MKL that ships with 
versions of the compiler released since last year. We've written something that 
will make it work, but right now we only have it working on Linux with intel64 
architecture. 

We don't have time right now to put in Windows support or 32bit support. And 
even if we could, we don't have any Windows or 32bit machines to test it on 
anyway. So should I push what I have and get it into the stream with the 
deficiencies documented since what is there will at least fix problems for many 
people? Should I leave it on the stage branch until either we or somebody else 
can help us with the remainder of it? 

I'll hold off on pushing anything until I know if pushing partial support is 
okay or not. Thanks,

Tim

- Original Message -
From: Tim Gallagher tim.gallag...@gatech.edu
To: cmake-developers@cmake.org
Sent: Tuesday, January 24, 2012 9:10:43 PM
Subject: [cmake-developers] New module introduction

Hi,

I've been on the users mailing list a few different times to submit patches for 
the FindBLAS and FindLAPACK modules and we found some more bugs with them. It 
was known awhile ago that they don't work for the new Intel MKL naming 
conventions (http://www.mail-archive.com/cmake@cmake.org/msg38606.html). We 
finally hit the point where we had to fix it.

So, in order to do this correctly, there is an additional module that 
interfaces with a tool provided by Intel to generate the information needed to 
link. We've written this module and are polishing it now. We've also modified 
FindBLAS and FindLAPACK to use the new module and also fixed a few smaller bugs 
during this process. 

I would like to sign up as a module maintainer for this new module (and get 
push access to put it in the repository). I've done all the steps on the wiki 
for doing this except introducing the module (which is what I'm doing now!) and 
applying for git access (which I will do when I find out this email was what 
'introduce the module' meant). If I need to send out the new module first for 
review or something, let me know and we'll do it as soon as it's finished. 

Thanks,

Tim
--

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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
--

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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

[cmake-developers] New module introduction

[Tim Gallagher]

Hi,

I've been on the users mailing list a few different times to submit patches for 
the FindBLAS and FindLAPACK modules and we found some more bugs with them. It 
was known awhile ago that they don't work for the new Intel MKL naming 
conventions (http://www.mail-archive.com/cmake@cmake.org/msg38606.html). We 
finally hit the point where we had to fix it.

So, in order to do this correctly, there is an additional module that 
interfaces with a tool provided by Intel to generate the information needed to 
link. We've written this module and are polishing it now. We've also modified 
FindBLAS and FindLAPACK to use the new module and also fixed a few smaller bugs 
during this process. 

I would like to sign up as a module maintainer for this new module (and get 
push access to put it in the repository). I've done all the steps on the wiki 
for doing this except introducing the module (which is what I'm doing now!) and 
applying for git access (which I will do when I find out this email was what 
'introduce the module' meant). If I need to send out the new module first for 
review or something, let me know and we'll do it as soon as it's finished. 

Thanks,

Tim
--

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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers