update general section
This commit is contained in:
		| @@ -5,8 +5,10 @@ About Autocmake | ||||
|  | ||||
| Building libraries and executables from sources can be a complex task. Several | ||||
| solutions exist to this problem: GNU Makefiles is the traditional approach. | ||||
| Today, CMake is one of the trendier alternatives. Autocmake is a script which | ||||
| composes well tested CMake building blocks into a CMake project and generates | ||||
| Today, CMake is one of the trendier alternatives which can generate Makefiles | ||||
| starting from a file called ``CMakeLists.txt``. Consider Autocmake a | ||||
| ``CMakeLists.txt``-generator.  Autocmake is a collection of scripts which | ||||
| compose well tested CMake building blocks into a CMake project and generates | ||||
| ``CMakeLists.txt`` as well as ``setup.py``, which serves as a front-end to | ||||
| ``CMakeLists.txt``. All this is done based on a lightweight ``autocmake.cfg`` | ||||
| file:: | ||||
| @@ -34,10 +36,7 @@ file:: | ||||
|   Build/install/test targets | ||||
|  | ||||
|  | ||||
| Why Autocmake | ||||
| ------------- | ||||
|  | ||||
| The main motivation for us to create Autocmake as a CMake framework library and | ||||
| Our main motivation to create Autocmake as a CMake framework library and | ||||
| CMake module composer was to simplify CMake code transfer between codes. We got | ||||
| tired of manually diffing and copy-pasting boiler-plate CMake code and watching | ||||
| it diverge while maintaining the CMake infrastructure in a growing number of | ||||
| @@ -50,24 +49,9 @@ scientific projects which typically have very similar requirements: | ||||
| - Math libraries: BLAS, LAPACK | ||||
|  | ||||
| Our other motivation for Autocmake was to make it easier for developers who do | ||||
| not know CMake to use CMake by providing a higher-level entry point to CMake. | ||||
| not know CMake to provide a higher-level entry point to CMake. | ||||
|  | ||||
| Autocmake is a chance to provide a well documented and tested set of CMake | ||||
| plug-ins. With this we wish to give also users of codes the opportunity to | ||||
| introduce the occasional tweak without the need to dive deep into CMake | ||||
| documentation. | ||||
|  | ||||
|  | ||||
| Explicit is better than implicit | ||||
| -------------------------------- | ||||
|  | ||||
| Our design principle is to let Autocmake do one thing, as explicitly as | ||||
| possible and to minimize "hidden" actions in the background. | ||||
|  | ||||
|  | ||||
| Convention over configuration | ||||
| ----------------------------- | ||||
|  | ||||
| Our guideline is to follow good established conventions in order to allow users | ||||
| and developers to recognize the configuration when experimenting with an | ||||
| Autocmake-powered project. | ||||
|   | ||||
| @@ -5,7 +5,7 @@ Requirements and dependencies | ||||
|  | ||||
| The ``update.py`` script requires Python >= 2.7. We try to also | ||||
| support Python 3. If the script fails with Python 3, consider this | ||||
| as bug. | ||||
| a bug and please file an issue. | ||||
|  | ||||
| The generated CMake infrastructure requires CMake >= 2.8. | ||||
| The generated ``setup.py`` runs with Python >= 2.7 (also Python 3). | ||||
|   | ||||
		Reference in New Issue
	
	Block a user