CMake setup

[xsacha]

Currently everything seems to be manual set up in CMake rather than using CMakes features.
Things like setting up debug/release configuration, setting up the CFLAGS, setting up certain variables that already exist in CMake.
This should all be left to CMake and the file will be easier to maintain and work everywhere.

[martin-frbg]

Can you be more specific please, or even prepare a PR for discussion ? It is quite likely that none of us who contributed to the current cmake build framework are enlightened about the true capabilities, but just dropping a "this is not how you do it" here will probably help noone. (Not requiring the latest and greatest release of cmake for building is considered a feature however)

[xsacha]

I do intend to provide a pull request but just posted this to find out some background and whether it is intended for some reason or if it is being worked on somewhere.

Currently, almost everything is done manually: from choosing cflags (like -O2), detecting fPIC, choosing build types (release and debug), choosing output directories, detecting architecture/OS, building static and shared libs, finding programs and so on and so forth. None of this requires CMake 3.0 or newer. It can all be done on CMake 2.8 just fine.
The strange thing is if you just.. don't.. do these things, CMake will just do them automatically anyway. So I am not sure why they were being done at all.

[brada4]

Can you make one line PR unintentionally to put us on right path? Your chat is too generic to act upon.

[martin-frbg]

It is quite possible that the current cmake files are basically literal translations of the GNU Makefiles, written by people much more familiar with the latter. (This is certainly true for any changes I made there). If I am not mistaken, they still carry a warning that the resulting library may be different from what a plain make would build and not all options may be supported.

[xsacha]

It is quite possible that the current cmake files are basically literal translations of the GNU Makefiles,

This is exactly the situation. As CMake has a lot of autoconfiguration, much of the checks and manual flag placement that are required in Makefiles can be removed. Also, people who use CMake expect it to operate different.
For instance, you would be hard-pressed to find any CMake project that builds both static and shared in the same configuration as that is not how it is intended to be used. Further, CMake projects are often used as dependencies for other CMake projects -- especially in the case of a library project, such as OpenBLAS. As such it is common to make tests optional and ensure that the project can be both imported (when built standalone) or included as a subdirectory of another project. Currently the project does neither.

Due to the auto-configuration nature of CMake it is generally assumed it works on multiple platforms as well. Right now it works only on Windows, with x86 processors, with fortran enabled and under specific conditions.

I have made a PR #1279 that goes towards fixing these issues. It now builds on Linux and without fortran available. I have removed a substantial amount of manual configuration but there is still a lot of work to do. I plan to have it supporting other architectures such as ARM and other platforms such as Andoid and iOS soon as this specifically benefits my projects.

[martin-frbg]

Due to the auto-configuration nature of CMake it is generally assumed it works on multiple platforms as well. Right now it works only on Windows,

If this is true it must be a very recent breakage in the "develop" branch, possibly a side effect of #1256

[xsacha]

There was a number of other blockers for Linux, such as the utest running without fortran enabled. I just fixed another one. The kernel/Makefile.LA files did not exist in CMakeLists.txt, for example.

That's why I have also enabled CI for the Linux-specific CMake builds. They are usually a good indication that every non-Windows platform is broken.