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

Inconsistencies between using setup and bare cmake #219

Open
robertodr opened this issue Dec 5, 2017 · 4 comments
Open

Inconsistencies between using setup and bare cmake #219

robertodr opened this issue Dec 5, 2017 · 4 comments

Comments

@robertodr
Copy link
Contributor

I think configuring a project with setup and bare cmake should lead to the exact same result, but this is not currently the case:

  1. setup sets compilers as FC=gfortran cmake. I think it is better to pass them as CMake variables: cmake -DCMAKE_Fortran_COMPILER=gfortran, which is also portable.
  2. setup creates the build directory beforehand and then moves into it before running cmake. With bare cmake I do cmake -H. -Bbuild (also portable) I encountered this problem because I am running a configuration script that needs cmake to be run from the root directory (I know this is bad practice)
  3. For some reason, running bare cmake leads the math detector to believe that I want to use MKL. I haven't investigated this last problem more.

Possible solutions:

  1. If you agree, I can change this rather easily. Some of the code in configure.py and generate.py can be simplified/removed.
  2. I would keep the check on existing build directories (though this is not CMake behavior and it might confuse people used to bare cmake) but generate the CMake command as cmake -H<project_root_dir> -B<build_path>.
@bast
Copy link
Member

bast commented Dec 6, 2017

I agree with you that "configuring a project with setup and bare cmake should lead to the exact same result" and I can imagine that it may not always and when it does not, I consider it a bug or bad design of some of the components. This is important when a project is included as external project.

  1. Agree. What you describe is clearly better. I simply did not know better in the past. Will also simplify Windows and as you say remove a lot of clutter.
  2. Agree. It's more portable. But I really want to know what -H means and perhaps rather use the --long-flags for more clarity. This will be mostly transparent but if somebody goes into the code that they have an idea what is happening.
  3. We can look at it but good to have a concrete example that I can copy paste into my terminal.

@robertodr
Copy link
Contributor Author

I will send a PR for this. My example for the moment was hande-qmc/hande#2, but really, any project using Autocmake will be an example. For -H the documentation says it will output an help message if called without a directory as argument.

@bast
Copy link
Member

bast commented Dec 8, 2017

So we can leave out the -H? Since the script will always call it with an argument.

@robertodr
Copy link
Contributor Author

I feel -H is the proper way of doing it, even if it's undocumented.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants