Though the current build system has its merits, I think it is a suboptimal approach in the long run:
A lot of a people are actually very used to the open source build system "industry standards" Autotools or Cmake. Although they are complex tools, in most cases the compilation (AND system specific installation!) of our library should come down to something like ./configure && make && sudo make install (or ./configure --prefix=/home/user/opt && make && make install to install in user prefix). In our system we would have to provide an extensive config template with extensive documentation to match the capabilities of ./configure and ./configure --help
We want to support as many target systems (and compilers) as possible. Doing this via our hand-made system means solving a problem that is difficult and already solved. And I already hate our different compiler calls in every script for Linux and MacOS.
We are now already supporting 4 extra build options with some kind of interdependence, which is currently not even represented because you can select only one option at a time (.e.g. no profiling and openmp at the same time). The flags to be added for each option also depend sometimes on the compiler and system used, so again this is becoming a mess and is a solved problem.
The whole library is rebuilt on every ./build.sh no matter how much was changed. Since compile times start to become long enough to be relevant, this is already an issue and will get worse and worse.
All the ./run.sh compile every test, benchmark or example on every run, no matter if it is necessary.
So concluding, overall I think the benefits of a proper build system outweigh the loss of a lightweight and extremely transparent system. And I'm not afraid of having the Autotools chain as dependency, because I don't think any relevant target system is missing them.
Therefore we should switch our build system to autotools.
Though the current build system has its merits, I think it is a suboptimal approach in the long run:
./configure && make && sudo make install(or./configure --prefix=/home/user/opt && make && make installto install in user prefix). In our system we would have to provide an extensive config template with extensive documentation to match the capabilities of./configureand./configure --help./build.shno matter how much was changed. Since compile times start to become long enough to be relevant, this is already an issue and will get worse and worse../run.shcompile every test, benchmark or example on every run, no matter if it is necessary.So concluding, overall I think the benefits of a proper build system outweigh the loss of a lightweight and extremely transparent system. And I'm not afraid of having the Autotools chain as dependency, because I don't think any relevant target system is missing them.
Therefore we should switch our build system to autotools.