-
Notifications
You must be signed in to change notification settings - Fork 163
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
Add second stage build #56
Conversation
Only have a dependance on the existence of a fortran compiler if "LINALG_VENDOR MATCHES "LAPACKE"". When using LAPACKE, you need the fortran support libraries like gfortran to be linked in.
The 2nd stage of the Makefile build was not implemented in cmake. When this shortcomming was identified, it was better understood that each source file is compiled multiple times with different flags for different purposes. The rather verbose approach taken to preserve backwards compatibility, and to avoid multiple conditional compilation with different flags was to use the source files as templates that are re-written to the build tree, and then compiled. This approach facilitates debugging (the code compiled can be viewed from the build tree, without identiftying the result of the pre-processor.
The really cool pre-processing magic from misc/cppmap.h is hard for most developers to descipher, and can be a source of frustration for developers who wish to expand upon the bart infrastructure, or contribute new features to bart.
The build_targets.mk files was created to provide a single point of modification when new targets are added. This will allow for CMake builds to automatically identify when a new target is added from the Makefile build system.
The mat2cfl is build if matlab is found, otherwise if matlab is not found, or if USE_MATLAB is off, then it is not built.
The ISMRMRD support is no functional.
Both cmake and Make now can build doc/commands.txt.
Thank you, Hans! Is there a workaround for the LAPACKE issue, so that I can try this on my machine? I will merge this now, but in the long run we should simplify this. It seems that some things which are simple to do with make and shell scripts are rather complicated with cmake.
Finally, would it be possible to add a section to .travis.yml where the cmake build is tested? Martin |
Martin, The main reason for the very convoluted CMake is that I wanted to minimize the changes in the Makefile and code. The cmake configuration could be made tremendously simpler if we did not need to maintain the build structure dictated by the current Makefile. I would NOT use this cmake file as an indication the complexity of cmake. It has many hacks that work arounds so that the Makefile system does not need to change. I will work on the items in your list as time permits, but I am really busy right now making LAPACK updates and other projects. Can you please elaborate on the “LAPACKE issues” that you are having? I am just starting to use BART, so I did not know how people use it. In some respects, I just made sure that CMake could do everything that the Makefile did without changing the current build process. Hans From: Martin Uecker notifications@github.com Thank you, Hans! Is there a workaround for the LAPACKE issue, so that I can try this on my machine? I will merge this now, but in the long run we should simplify this. It seems that some things which are simple to do with make and shell scripts are rather complicated with cmake. Martin — |
@uecker I finished adding the rest of the Makefile functionality to cmake this morning.
@mjacobs75 Mathews, These are the patches you need to be able to completely build bart with cmake.
Hans