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

CMakeLists vs Makefile #22

Open
grische opened this issue Dec 4, 2019 · 5 comments
Open

CMakeLists vs Makefile #22

grische opened this issue Dec 4, 2019 · 5 comments

Comments

@grische
Copy link
Contributor

grische commented Dec 4, 2019

Why do you have both a CMakeLists.txt and a Makefile? Which one is the preferred one?

Considering that the Makefile is being overriden by cmake, can it be removed to avoid ambiguity?

@ax3l
Copy link
Member

ax3l commented Dec 4, 2019

Hi and thanks for the report!

We maintain the CMakeLists.txt version. The old Makefile script is just lingering around from the long-term unmaintained repo that we forked from: https://sourceforge.net/p/cudagpumemtest

We should remove it accordingly, but it probably contains some hints in case someone actually wants to use the OpenCL version (instead of the CUDA tests that we focus on).

@ax3l ax3l added the question label Dec 4, 2019
@ax3l
Copy link
Member

ax3l commented Dec 4, 2019

I personally also added a Spack package that builds from CMake, as recommended.

@ax3l
Copy link
Member

ax3l commented Dec 4, 2019

Considering that the Makefile is being overriden by cmake, can it be removed to avoid ambiguity?

Don't build CMake projects in-source, please. Create a temporary build directory and execute cmake <pathToSource> in it.

@grische
Copy link
Contributor Author

grische commented Dec 4, 2019

@ax3l Makes sense.

Could you add build instructions to the README? I assumed the cmake variant is the new one, but the readme clearly stated that the Makefile is the current version which was quite confusing.

@ax3l
Copy link
Member

ax3l commented Dec 4, 2019

Yes, good idea. We initially thought our changes might be accepted upstream again and tried to change as little as possible.

I think a decade later we can assume nothing will happen upstream anymore and so let's change more boldly along the repo lines ;)

This was referenced Dec 6, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants