Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CMake find module #8

Open
jenskeiner opened this issue Mar 9, 2016 · 2 comments
Open

CMake find module #8

jenskeiner opened this issue Mar 9, 2016 · 2 comments
Labels
automation Suggestions and possible candidates for automation. build routine Topics concerning the build routine. enhancement question
Milestone

Comments

@jenskeiner
Copy link
Contributor

Transferred from: https://github.com/NFFT/nfft_old/issues/12

I wrote a CMake find module to help the discovery of the different components of NFFT v3.3 inside projects using CMake as their build system. Would you guys be interested to have it upstream in the repository ?

@kevinmatthes
Copy link
Contributor

In my opinion, it is definitely an interesting feature to have an alternative build system in case that the current one, automake, should not be available for some reasons on some machines.

I would like to suggest to think about an integration for the next bigger release in order to enhance the portability to different systems. For testing and debugging, we could bind it as a submodule from an external repository within the NFFT namespace such that we can adjust it easier without too much overhead to this repository.

Which version of cmake does the suggested build routine require, at the moment? Does it work with the latest versions (for instance version 3.20.x or newer), too, or does it require a certain older version?

@kevinmatthes kevinmatthes added automation Suggestions and possible candidates for automation. build routine Topics concerning the build routine. enhancement question labels Oct 30, 2021
@kevinmatthes kevinmatthes added this to the 4.0.0 milestone Oct 30, 2021
@kevinmatthes
Copy link
Contributor

When we would outsource both build routines to different repositories within the NFFT namespace -- and bind both as submodules --, users could decide for one during the cloning process (by just cloning the preferred one) or, in a later step, by passing an option to bootstrap.sh or configure in order to proceed with the selected build system.

Thereby, we would be more flexible regarding adjustments of the build system since we would have a fallback solution -- the opposite build system -- in case that an update to one of the systems would cause problems. Hence, the project could be developed more flexible since the build routines could be updated one after another.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
automation Suggestions and possible candidates for automation. build routine Topics concerning the build routine. enhancement question
Projects
None yet
Development

No branches or pull requests

3 participants
@jenskeiner @kevinmatthes and others