Project

General

Profile

Task #815

update CMake modules with latest version

Added by Rossen Apostolov over 7 years ago. Updated over 6 years ago.

Status:
Closed
Priority:
Normal
Category:
build system
Target version:
Difficulty:
uncategorized
Close

Description

Before 4.6 we should update all vanilla modules that are used from CMake.

Shall we put those vanilla ones in a separate sub-directory of $GMXDIR/cmake to distinguish them from the custom ones? It'll be easier to update later

Associated revisions

Revision b39f096c (diff)
Added by Mark Abraham over 7 years ago

Removed duplicate CMake functionality

The FindXXX modules that I have removed are found in standard CMake
2.8.2, so we don't need to duplicate them if we choose to have a
similar minimum requirement for CMake. So far, I've arbitrarily chosen
2.8.0 as a compromise between modernity and widespread adoption.
See discussion in Redmine issue #815.

The logic for the work-around for Cray MPI is now in CMakeLists.txt

The test for the Git version has also moved into CMakeLists.txt

We had a minor change in the LibXml2 module that catered to some
weird/broken CMake environment Teemu had, but it looks to be
unnecessary for modern CMake.

The LAPACK find module is nearly the same as standard, apart from a
bug fix that we have found and reported upstream. So we have to
keep the duplicated code.

Change-Id: If312671392f9b77c0007c761ccb37688bcfc13b3

Revision 949ebbd5 (diff)
Added by Teemu Murtola over 7 years ago

Added gtest and gmock under src/external/.

Source code copied from Google Test / Google Mock 1.6.0 (see
README.Gromacs for details).
Build system adapted to build tests against these versions of gtest and
gmock. Added advanced CMake variables GMX_USE_GTEST and GMX_USE_GMOCK,
which can be used to disable building the frameworks (and tests that use
them).

Google Test 1.6.0 handles test-thrown exceptions better (reports them as
failures instead of terminating the whole executable). With this
version, system-wide installation is no longer supported by Google, and
the officially supported way is to build the test framework as part of
the build system. Thus, the simplest way is to include the whole
framework in the source tree, which also makes it simpler to build the
tests.

Makes issue #639 obsolete (removes FindGMock.cmake completely) and
relates to #815 (removes FindCMake.cmake, which was copied from 2.8.2).

Change-Id: I021e81ea1529c8dea621c2d8b060c08987f9ca59

Revision 99135bd7 (diff)
Added by Christoph Junghans over 6 years ago

Updated FindGSL.cmake to version written by me.

relates to #815

Change-Id: I323f113b4016ef232124fcdcc985d0526bc8a880

History

#1 Updated by Christoph Junghans over 7 years ago

Possibly gromacs could also deliver a cmake module for third party packages and install it under the common cmake module patch.

Example: https://code.google.com/p/votca/source/browse/CMakeModules/FindGROMACS.cmake?repo=csg

We should also create a cmake.config, see:
http://www.vtk.org/Wiki/CMake/Tutorials/How_to_create_a_ProjectConfig.cmake_file

#2 Updated by Szilárd Páll over 7 years ago

IMO we should replicate as many vanilla CMake scripts as possible. I don't see any reason for keeping them other than the case when we want backward-compatibility with a widely used older CMake version.

So I'd say we should remove as many as possible and keep only the ones that are really needed. I guess we could start by bumping the required version to 2.8 or at least 2.6.4.

Sz.

#3 Updated by Mark Abraham over 7 years ago

Szilárd Páll wrote:

IMO we should replicate as many vanilla CMake scripts as possible. I don't see any reason for keeping them other than the case when we want backward-compatibility with a widely used older CMake version.

So I'd say we should remove as many as possible and keep only the ones that are really needed. I guess we could start by bumping the required version to 2.8 or at least 2.6.4.

Do you mean we should replicate as few vanilla CMake scripts as possible? I think that is a good idea because it reduces the code base we need to know and support.

#4 Updated by Mark Abraham over 7 years ago

Also, bumping the required version is a good thing to do now before 4.6 work starts - though only if there's something useful we're achieving with the bump. What's desirable in more recent CMake?

#5 Updated by Szilárd Páll over 7 years ago

Do you mean we should replicate as few vanilla CMake scripts as possible? I think that is a good idea because it reduces the code base we need to know and support.

Right, I meant few. Thanks for pointing it out!

#6 Updated by Szilárd Páll over 7 years ago

Mark Abraham wrote:

Also, bumping the required version is a good thing to do now before 4.6 work starts - though only if there's something useful we're achieving with the bump. What's desirable in more recent CMake?

One advantage I know without checking is that the FindCUDA.cmake modules are included in 2.8.x. There are probably others as well, though.

#7 Updated by Mark Abraham over 7 years ago

Szilárd Páll wrote:

Mark Abraham wrote:

Also, bumping the required version is a good thing to do now before 4.6 work starts - though only if there's something useful we're achieving with the bump. What's desirable in more recent CMake?

One advantage I know without checking is that the FindCUDA.cmake modules are included in 2.8.x. There are probably others as well, though.

That sounds like a good enough excuse to me. Since 4.6 will be the first release where autoconf will not be supported, it makes sense to set a fairly recent CMake version requirement. Many people will have to deal with CMake for the first time then, and we may as well cater to modern versions.

#8 Updated by Alexey Shvetsov over 7 years ago

Well there is short list of cmake modules that are already in cmake 2.8.5
  • FindBLAS.cmake
  • FindCUDA.cmake
  • FindGit.cmake
  • FindLAPACK.cmake
  • FindMPI.cmake
  • FindLibXml2.cmake

#9 Updated by Alexey Shvetsov over 7 years ago

Also NASM related modules
  • CMakeASM-NASMInformation.cmake
  • CMakeDetermineASM-NASMCompiler.cmake
  • CMakeTestASM-NASMCompiler.cmake

#10 Updated by Szilárd Páll over 7 years ago

I wouldn't take version bump that far as requiring 2.8.5 would require almost everyone to compile cmake from source just to be able to compile Gromacs. I'm not sure what would be an adequate version, but I'd prefer to be rather conservative and settle with 2.8.0 unless there is a good reason for 2.8.1/2.

#11 Updated by Alexey Shvetsov over 7 years ago

Well all this modules also included in 2.8.0 it seems. I only tested this on 2.8.5 and on 2.8.4.

PS in cmake changelog [[http://www.cmake.org/files/v2.8/CMakeChangeLog-2.8.5]] has no entryes on new module inclusion

#12 Updated by Szilárd Páll over 7 years ago

Alexey Shvetsov wrote:

Well all this modules also included in 2.8.0 it seems. I only tested this on 2.8.5 and on 2.8.4.

Still, we'll have to be careful when declaring vanilla CMake modules as "OK" as there might have been important fixes between 2.8.0 and 2.8.5.

#13 Updated by Alexey Shvetsov over 7 years ago

Well at least on four different systems dropping cmake modules works for me. Not sure about FindMPI and Cray but recent FindMPI may also work as long as user can also specify MPI_INCLUDES MPI_LIBS and it will find needed mpi implentation

#14 Updated by Mark Abraham over 7 years ago

Alexey Shvetsov wrote:

Well at least on four different systems dropping cmake modules works for me. Not sure about FindMPI and Cray but recent FindMPI may also work as long as user can also specify MPI_INCLUDES MPI_LIBS and it will find needed mpi implentation

Great, that's a start, but it's the weird cases that GROMACS caters for that matter (e.g. Cray MPI). We need to do diff comparisons and make decisions about those differences before we can drop our versions of these CMake modules.

#15 Updated by Alexey Shvetsov over 7 years ago

Most modules has a major rewrite after they was added to gromacs so they need teting.

#16 Updated by Mark Abraham over 7 years ago

In bfd3765462e3, Rossen updated some of the modules we import to 2.8.2, so rather than revert to 2.8.0, how about we pick 2.8.2 as our requirement?

#17 Updated by Rossen Apostolov over 7 years ago

I would say just port to 2.8.5. The FindMPI.cmake modules are quite different between 2.8.2 and 2.8.5, and by the time we have 4.6 out at least Ubuntu will come with 2.8.5 https://launchpad.net/ubuntu/+source/cmake, which should be next month (11.10 release):)

The question is how to organize the vanilla modules and our own patched ones. Have them in different directories or add a header to them? Separate directories might be better since we have our own scripts too.

#18 Updated by Mark Abraham over 7 years ago

Rossen Apostolov wrote:

I would say just port to 2.8.5. The FindMPI.cmake modules are quite different between 2.8.2 and 2.8.5, and by the time we have 4.6 out at least Ubuntu will come with 2.8.5 https://launchpad.net/ubuntu/+source/cmake, which should be next month (11.10 release):)

Fedora 16 (the next one) will have 2.8.5 also.

The question is how to organize the vanilla modules and our own patched ones. Have them in different directories or add a header to them? Separate directories might be better since we have our own scripts too.

If we're getting rid of vanilla ones (and I thought that was agreed, caveat testing), we're left only with the non-vanilla ones, and they can go wherever. Ideally I think there should be no non-vanilla ones either. For example, the Cray MPI test may as well go at the parent level as inside FindMPI.cmake.

#19 Updated by Szilárd Páll over 7 years ago

I'm not sure sure I understand what you mean by "port to". If this means requiring CMake 2.8.5 then I am strongly against it as it would mean that pretty much everybody will have to compile CMake from source just to be able to compile Gromacs.

Secondly, I don't get what organization is needed for vanilla modules. The vanilla modules are vanilla because CMake ships them so there is no point in replicating them. There is only one case when replicating is still desired: when we don't want to require a very new version, and the respective module does work with older CMake (e.g. FindCUDA borrowed from CMake 2.8 has been used with 2.6.4 as a requirement).

So in case of modules we currently have replicated in the source tree and are included in CMake 2.8, if the respective module's functionality:
- matches our needs, we can remove it from the Gromacs source tree;
- doesn't work for us, we need to keep a patched version (as Roland suggested in Gerrit contributing back would be the right thing to do).

#20 Updated by Rossen Apostolov over 7 years ago

Szilárd Páll wrote:

I'm not sure sure I understand what you mean by "port to". If this means requiring CMake 2.8.5 then I am strongly against it as it would mean that pretty much everybody will have to compile CMake from source just to be able to compile Gromacs.

Yes, we should require 2.8.5 and since by the time 4.6 is out most distributions will have the package available.

Secondly, I don't get what organization is needed for vanilla modules. The vanilla modules are vanilla because CMake ships them so there is no point in replicating them. There is only one case when replicating is still desired: when we don't want to require a very new version, and the respective module does work with older CMake (e.g. FindCUDA borrowed from CMake 2.8 has been used with 2.6.4 as a requirement).

Some modules might work with older cmake versions but officially supporting them is unneeded.

So in case of modules we currently have replicated in the source tree and are included in CMake 2.8, if the respective module's functionality:
- matches our needs, we can remove it from the Gromacs source tree;
- doesn't work for us, we need to keep a patched version (as Roland suggested in Gerrit contributing back would be the right thing to do).

Yes, correct. Except that our patched version should be based on a vanilla 2.8.5

#21 Updated by Szilárd Páll over 7 years ago

Rossen Apostolov wrote:

Szilárd Páll wrote:

I'm not sure sure I understand what you mean by "port to". If this means requiring CMake 2.8.5 then I am strongly against it as it would mean that pretty much everybody will have to compile CMake from source just to be able to compile Gromacs.

Yes, we should require 2.8.5 and since by the time 4.6 is out most distributions will have the package available.

I have to disagree. While coming desktop Linux distributions might ship CMake 2.8.5, that's not a good enough reason because:
- most compute centers will not have it;
- CentOS 5.7 and 6.0 both have 2.6.4 (!);
- not everybody rolls with the latest OS versions, e.g. many people stick to LTS Ubuntu versions, even on desktop;
- not everybody rolls with the latest software version on MacOS, Windows, etc. either and it would piss off (or even turn down) a lot of people to have to update their CMake just to compile Gromacs.

#22 Updated by Alexey Shvetsov over 7 years ago

Well, when release of gromacs 4.6 series expected? If you count CentOS 5.x why not also count RHEL 4.x and its derviates. They doesnt have cmake at all, but some large clusters still use them as OS (thats why i have almoust full base system installed in $HOME/prefix with new compilers etc on this systems).

Also users alredy forced to install fftw to use gromacs and possibly atlas or any other blas/lapack library so why not use new cmake as hard dep?

#23 Updated by Berk Hess over 7 years ago

We clearly have two competing aspects here.
One the one hand we want to copy and maintain as little CMake functionality as possible.
On the other hand we don't want to require the newest CMake version, as then almost everyone will have to upgrade.

As configuring and compiling Gromacs is the only thing (except running) that nearly every user has to do, we should make this as easy as possible. Since 2.8.5 doesn't seem to be available on any current OS distribution, we should not require 2.8.5. Even 2.8.0 is not installed everywhere, but as this will make our live a lot easier and it will take a few months for the final release, we can live with 2.8.0.

#24 Updated by Rossen Apostolov over 7 years ago

Berk Hess wrote:

We clearly have two competing aspects here.
One the one hand we want to copy and maintain as little CMake functionality as possible.
On the other hand we don't want to require the newest CMake version, as then almost everyone will have to upgrade.

Why is it a big deal to compile CMake? It's a simple procedure, simpler than fftw actually(no single/double precision choices). And it's very normal if you want a newer version of one package to need to upgrade something else. It's much more effort to unnecessary maintain functionality that is already available.
Also, with CPack we can make our own binaries too.

As configuring and compiling Gromacs is the only thing (except running) that nearly every user has to do, we should make this as easy as possible. Since 2.8.5 doesn't seem to be available on any current OS distribution, we should not require 2.8.5.

It will be on Ubuntu and Fedora

Even 2.8.0 is not installed everywhere, but as this will make our live a lot easier and it will take a few months for the final release, we can live with 2.8.0.

Why for us 2.8.0 is easier than 2.8.5? I'd say there's chance that the other way round is easier in the long run.

#25 Updated by Alexey Shvetsov over 7 years ago

Other distros like gentoo and gentoo-based ones already have cmake 2.8.5 so it will be easyer to use cmake >=2.8

#26 Updated by Szilárd Páll over 7 years ago

Why is it a big deal to compile CMake? It's a simple procedure, simpler than fftw actually(no single/double precision choices). And it's very normal if you want a newer version of one package to need to upgrade something else. It's much more effort to unnecessary maintain functionality that is already available.

CMake is not like fftw! The former is a build generator, a tool you use to get your code compiled, the later is a library Gromacs depends on. While the former - at least in the OSS world is expected to be quite a bit version agnostic so that virtually whatever version you have it just works, this is not necessarily the case for the latter - library dependencies always go with versions.

When was the last time you had to compile autotools just to be able to compile a piece of OSS code? Requiring CMake 2.8.5 is pretty much like requiring gcc 4.7.

Also, with CPack we can make our own binaries too.

Sure, we can. However, binaries only make sense for Windows/Mac OS, not for Linux.

Why for us 2.8.0 is easier than 2.8.5? I'd say there's chance that the other way round is easier in the long run.

It's easier because of the far wider adoption. The question is not whether the latest Fedora/Ubuntu/Gentoo/etc. distro has or will have 2.8.5, but how widely the respective CMake version is adopted.

Deprecation autotools will already be a trauma for many users and we shouldn't make this even worse by requiring them to compile CMake from source.

#27 Updated by Alexey Shvetsov over 7 years ago

Szilárd Páll wrote:

When was the last time you had to compile autotools just to be able to compile a piece of OSS code? Requiring CMake 2.8.5 is pretty much like requiring gcc 4.7.

Its not like requiring gcc 4.7 (its currently in pre alpha stage) while cmake 2.8.0 was released about two years ago (Nov 2009) cmake 2.8.5 was released as bugfix release this year about 2 mounth ago.

#28 Updated by Christoph Junghans over 7 years ago

Compiling cmake is not hard, actually it is easier than compiling fftw and/or autotools as it only needs a c++ compiler.

However, from my own experience with exotic hpc platforms, I vote for requiring cmake 2.8.0 (or even less) and just add all needed cmake files in an separate directory and update them every year (or so). You won't believe me, but there are cmake 2.8 installations without such basic modules like FindPkgConfig.cmake.

Votca is using cmake as well and we had a lot of complains after switching away from autotools and this will happen to gromacs as well, but gromacs has 2 orders of magnitude more users ;-) So make this step as simple as possible. We should create a wiki page with screenshots of cmake-qui.

#29 Updated by Alexey Shvetsov over 7 years ago

Or with ccmake and instructions of how to build cmake manualy @ ${HOME}

#30 Updated by Mark Abraham over 7 years ago

Compiling CMake is indeed easy, but we should look for a compromise between useful features and wide adoption. If CUDA really is the only thing that requires 2.8, then maybe 2.6.x plus custom FindCUDA.cmake is the way to go.

Tomorrow I will have a go at back-porting our modified FindXXX.cmake files so that we can better understand what our real dependency requirements are.

There is some rudimentary usage information for CMake here http://www.gromacs.org/Developer_Zone/Cmake, but we will need to do a lot better before 4.6 gets alpha-released.

#31 Updated by Szilárd Páll over 7 years ago

Christoph Junghans wrote:

Compiling cmake is not hard, actually it is easier than compiling fftw and/or autotools as it only needs a c++ compiler.

However, from my own experience with exotic hpc platforms, I vote for requiring cmake 2.8.0 (or even less) and just add all needed cmake files in an separate directory and update them every year (or so). You won't believe me, but there are cmake 2.8 installations without such basic modules like FindPkgConfig.cmake.

Thanks for the tip!

So does this mean that our effort to eliminate as much of the replicated vanilla (or almost vanilla) CMake modules might miss the point and in some backfire? Can you recall what was the frequency of this issue and what platforms were affected? Should we worry about it in general or is it rare enough so that we can get around it by providing separately a tarball with an extra set of (tested and working) modules as drop-in alternatives to missing default ones?

Votca is using cmake as well and we had a lot of complains after switching away from autotools and this will happen to gromacs as well, but gromacs has 2 orders of magnitude more users ;-) So make this step as simple as possible. We should create a wiki page with screenshots of cmake-qui.

Right, that's a good idea.

#32 Updated by Szilárd Páll over 7 years ago

Mark Abraham wrote:

Compiling CMake is indeed easy, but we should look for a compromise between useful features and wide adoption. If CUDA really is the only thing that requires 2.8, then maybe 2.6.x plus custom FindCUDA.cmake is the way to go.

That we don't know yet. The only thing known for sure from my experience with 4.5.x GPU support is that CMake 2.6.4+ is needed for the FindCUDA.cmake module.

We would really need to start working on working the required features for 4.6 (list sent to gmx-core) to see what the potential higher version requirements of more advanced things (CPack, CDash, CTest) are.

#33 Updated by Mark Abraham over 7 years ago

Mark Abraham wrote:

Tomorrow I will have a go at back-porting our modified FindXXX.cmake files so that we can better understand what our real dependency requirements are.

We were duplicating FindXXX modules for CUDA, MPI, LibXml2, BLAS from CMake 2.8.2, with some minor changes, if any. I've cross-ported the necessary changes to CMakeLists.txt so that I could eliminate the duplicate modules.

We had a custom Git, which I've removed in favour of the standard one, cross-porting the check for git version.

We have a custom Pthreads, and I think someone knowledgeable about threading requirements should look at whether the standard FindThreads.cmake is suitable.

We have custom FFTW*, MKL, GSL, OpenMM and we need to keep them because they are not present in standard CMake. We should probably add a FindVMD.cmake to GROMACS and contribute a FindGROMACS.cmake to CMake.

We have a bugfix in an otherwise-standard LAPACK that I have sent upstream to CMake, but we need to keep our fixed version until the fix is accepted and widely available (i.e. years).

The resulting version built fine for me on CMake 2.8.2, and failed for lack of FindGit on 2.6.3, as expected.

#34 Updated by Rossen Apostolov over 7 years ago

http://www.gromacs.org/Developer_Zone/Cmake says that 2.8.3 should be avoided because of bug http://www.cmake.org/Bug/view.php?id=11464.
I don't know if this bug is present in pre-2.8.3 versions.

#35 Updated by Mark Abraham over 7 years ago

Rossen Apostolov wrote:

http://www.gromacs.org/Developer_Zone/Cmake says that 2.8.3 should be avoided because of bug http://www.cmake.org/Bug/view.php?id=11464.
I don't know if this bug is present in pre-2.8.3 versions.

Then we need CMakeLists.txt to provide a warning and/or fatal error with 2.8.3. What assembly stuff is affected by the bug?

#36 Updated by Rossen Apostolov over 7 years ago

Mark Abraham wrote:

Rossen Apostolov wrote:

http://www.gromacs.org/Developer_Zone/Cmake says that 2.8.3 should be avoided because of bug http://www.cmake.org/Bug/view.php?id=11464.
I don't know if this bug is present in pre-2.8.3 versions.

Then we need CMakeLists.txt to provide a warning and/or fatal error with 2.8.3. What assembly stuff is affected by the bug?

It seems it can't find the assembly compiler. And if it affects the earlier versions too then we should go to 2.8.5

#37 Updated by Mark Abraham over 7 years ago

Rossen Apostolov wrote:

Mark Abraham wrote:

Rossen Apostolov wrote:

http://www.gromacs.org/Developer_Zone/Cmake says that 2.8.3 should be avoided because of bug http://www.cmake.org/Bug/view.php?id=11464.
I don't know if this bug is present in pre-2.8.3 versions.

Then we need CMakeLists.txt to provide a warning and/or fatal error with 2.8.3. What assembly stuff is affected by the bug?

It seems it can't find the assembly compiler. And if it affects the earlier versions too then we should go to 2.8.5

The CMake thread says pre-2.8.3 is fine, and 2.8.4 fixed it.

#38 Updated by Rossen Apostolov over 7 years ago

The CMake thread says pre-2.8.3 is fine, and 2.8.4 fixed it.

That's good.
But one more thing about 2.8.5 if we'll stay with lower version. FindMPI.cmake in 2.8.5 is very different from e.g. the 2.8.2 version. It might make compilation on various hpc systems easier.

#39 Updated by Mark Abraham over 7 years ago

FindMPI.cmake has been removed, so that part of the issue is no longer of concern.

#40 Updated by Teemu Murtola over 6 years ago

  • Status changed from New to Feedback wanted

Is there still something that we have unnecessary duplicated from CMake (or from a too old version), or could this be closed?

#41 Updated by Erik Lindahl over 6 years ago

  • Status changed from Feedback wanted to Closed

No answer to Teemu's question, so I'll assume people are happy for now and don't have any modules that need fixing. Closing for now.

#42 Updated by Szilárd Páll over 6 years ago

  • Status changed from Closed to Feedback wanted

Erik Lindahl wrote:

No answer to Teemu's question, so I'll assume people are happy for now and don't have any modules that need fixing. Closing for now.

I have to disagree with that assumption. There are no responsible people assigned to the lifted CMake modules, so no answer just means that nobody has checked it out. We have 10 Find*.cmake modules:

  1. FindBLAS.cmake - updated to v2.8.8 in 702bcdae
  2. FindFFTW.cmake - custom has seen lots of attention
  3. FindGit.cmake - included v2.8.2 in 31b6cf1
  4. FindLAPACK.cmake - updated to v2.8.8 in 702bcdae
  5. FindMKL.cmake - custom - has not been updated since 2009; the history does not state where it comes from or who implemented it, added in 86ae5b69; needs work as using MKL AFAIK currently does not without manual tweaking
  6. FindOpenMM.cmake - custom
  7. FindOpenMP.cmake - from 2.8.7 (history does not state it, but source does)
  8. FindPthreads.cmake - custom; the history does not state where it comes from or who implemented it, added in 86ae5b69
  9. FindVMD.cmake - custom
  10. Findgsl.cmake - custom; the history does not state where it comes from or who implemented it, added in 5d67b0cf

Based on the above, the question is whether there is any advantage of upping the version of the lifted modules and whether there is anything that should/can be done about the others with open questions. I'll check the former.

#43 Updated by Szilárd Páll over 6 years ago

Szilárd Páll wrote:

  1. FindBLAS.cmake - updated to v2.8.8 in 702bcdae

no relevant update

  1. FindFFTW.cmake - custom has seen lots of attention
  2. FindGit.cmake - included v2.8.2 in 31b6cf1

some useful update (new module detects git version itself which could be removed from the root CMakeList.txt), but won't work with early versions of 2.8.x.

  1. FindLAPACK.cmake - updated to v2.8.8 in 702bcdae

no relevant udpate

  1. FindMKL.cmake - custom - has not been updated since 2009; the history does not state where it comes from or who implemented it, added in 86ae5b69; needs work as using MKL AFAIK currently does not without manual tweaking
  2. FindOpenMM.cmake - custom
  3. FindOpenMP.cmake - from 2.8.7 (history does not state it, but source does)

no relevant update

  1. FindPthreads.cmake - custom; the history does not state where it comes from or who implemented it, added in 86ae5b69
  2. FindVMD.cmake - custom
  3. Findgsl.cmake - custom; the history does not state where it comes from or who implemented it, added in 5d67b0cf

Based on the above, the question is whether there is any advantage of upping the version of the lifted modules and whether there is anything that should/can be done about the others with open questions. I'll check the former.

So no updates needed, but it still bugs me that we have one broken and two phantom-ish modules. The former needs confirmation (tested it a while ago) before filing an issue, not sure about the latter.

#44 Updated by Erik Lindahl over 6 years ago

Good - I would actually strongly prefer NOT to update modules, since we've done a fair amount if checking on platforms in addition to Jenkins, and it would be a bummer to break something there!

#45 Updated by Erik Lindahl over 6 years ago

  • Status changed from Feedback wanted to Closed

There is a separate redmine issue for the MKL bug (#1110), so let's move that discussion there.

#46 Updated by Szilárd Páll over 6 years ago

Erik Lindahl wrote:

Good - I would actually strongly prefer NOT to update modules, since we've done a fair amount if checking on platforms in addition to Jenkins, and it would be a bummer to break something there!

Agreed. Now that we have a full picture, it would still be nice to add a note on where do they comes from to the two phantom, but working modules - especially that we are re-licencing them without knowing whether they are original work of the contributors: Erik (FindPthreads), Christoph (Findgsl).

Erik and Christoph, do you recall where do these codes originate from?

#47 Updated by Christoph Junghans over 6 years ago

I believe Findgsl is based on:
http://www.cmake.org/pipermail/cmake/attachments/20080709/38127d1f/attachment.obj

but you could also use the one from VOTCA:
http://code.google.com/p/votca/source/browse/CMakeModules/FindGSL.cmake?repo=tools
which is written by me and I am willing to change it from Apache License to LGPL.

#48 Updated by Szilárd Páll over 6 years ago

Christoph Junghans wrote:

I believe Findgsl is based on:
http://www.cmake.org/pipermail/cmake/attachments/20080709/38127d1f/attachment.obj

but you could also use the one from VOTCA:
http://code.google.com/p/votca/source/browse/CMakeModules/FindGSL.cmake?repo=tools
which is written by me and I am willing to change it from Apache License to LGPL.

Great, I'm fine with either noting the source (which does not seem to mention licensing) or replacing with your code. Whichever solution is simplest and requires less work (including testing and review) should be preferred.

Thanks for the quick reply!

#49 Updated by Szilárd Páll over 6 years ago

Erik, we are only missing your feedback to have a clean cmake module tree free of potential licensing conflicts.

Also available in: Atom PDF