the default setup script name becomes "setup"

it can be changed in autocmake.cfg

doc/developers/bootstrap.rst

@@ -39,7 +39,7 @@ Generating the CMake infrastructure
 Now customize ``autocmake.cfg`` to your needs
 (see :ref:`autocmake_cfg`)
 and then run the ``update.py`` script which
-creates ``CMakeLists.txt`` and ``setup.py`` in the target path::
+creates ``CMakeLists.txt`` and a setup script in the target path::
 
   $ python update.py ..
 
@@ -59,10 +59,10 @@ called ``downloaded/``::
 Building the project
 --------------------
 
-Now you have ``CMakeLists.txt`` and ``setup.py`` in the project root and the project
+Now you have ``CMakeLists.txt`` and setup script in the project root and the project
 can be built::
 
   $ cd ..
-  $ python setup.py [-h]
+  $ python setup [-h]
   $ cd build
   $ make

doc/developers/configuration.rst

@@ -105,13 +105,13 @@ to all libraries it needs::
   - fetching lib/docopt/docopt.py
   - fetching update.py
 
-Good. Now we can generate ``CMakeLists.txt`` and ``setup.py``::
+Good. Now we can generate ``CMakeLists.txt`` and the setup script::
 
   $ python update ..
 
   - parsing autocmake.cfg
   - generating CMakeLists.txt
-  - generating setup.py
+  - generating setup script
 
 Excellent. Here is the generated ``CMakeLists.txt``::
 
@@ -134,12 +134,12 @@ Excellent. Here is the generated ``CMakeLists.txt``::
 This is the very bare minimum. Every Autocmake project will have at least these
 settings.
 
-And we also got a ``setup.py`` script (front-end to ``CMakeLists.txt``) with
+And we also got a setup script (front-end to ``CMakeLists.txt``) with
 the following default options::
 
   Usage:
-    ./setup.py [options] [<builddir>]
-    ./setup.py (-h | --help)
+    ./setup [options] [<builddir>]
+    ./setup (-h | --help)
 
   Options:
     --type=<TYPE>                          Set the CMake build type (debug, release, or relwithdeb) [default: release].
@@ -195,10 +195,10 @@ documentation (see below), then the fetched file is placed into the same
 directory as the CMake module file which fetches it.
 
 
-Generating setup.py options
----------------------------
+Generating setup options
+------------------------
 
-Options for the ``setup.py`` script can be generated with the ``docopt``
+Options for the setup script can be generated with the ``docopt``
 option. As an example, the following ``autocmake.cfg`` snippet will add a
 ``--something`` flag::
 

doc/developers/example.rst

@@ -71,7 +71,7 @@ We need to create ``src/CMakeLists.txt`` which can look like this::
 
 We wrote that we want to get an executable "hello.x" built from our sources.
 
-Now we have everything to generate ``CMakeLists.txt`` and ``setup.py``::
+Now we have everything to generate ``CMakeLists.txt`` and a setup script::
 
   $ cd cmake
   $ python update ..
@@ -91,7 +91,7 @@ And this is what we got::
   |   |   `-- docopt
   |   |       `-- docopt.py
   |   `-- update.py
-  |-- setup.py
+  |-- setup
   `-- src
       |-- CMakeLists.txt
       |-- feature1.F90
@@ -100,7 +100,7 @@ And this is what we got::
 
 Now we are ready to build::
 
-  $ python setup.py --fc=gfortran --cc=gcc
+  $ python setup --fc=gfortran --cc=gcc
 
   FC=gfortran CC=gcc cmake -DEXTRA_FCFLAGS="''" -DENABLE_FC_SUPPORT="ON" -DEXTRA_CFLAGS="''" -DCMAKE_BUILD_TYPE=release -G "Unix Makefiles" None /home/user/example
 

doc/developers/faq.rst

@@ -4,8 +4,8 @@ FAQ for developers
 ==================
 
 
-Autocmake does not do feature X - I really need feature X and a setup.py flag --X
----------------------------------------------------------------------------------
+Autocmake does not do feature X - I really need feature X and a setup flag --X
+------------------------------------------------------------------------------
 
 The Autocmake developers have to be very conservative and only a very limited
 set of portable features of absolutely general interest become part of the
@@ -25,7 +25,7 @@ And include this feature to the main ``CMakeLists.txt`` in ``autocmake.cfg``::
   source: custom/my_feature.cmake
 
 Now your code is included in the main ``CMakeLists.txt``. Perhaps you also
-want a ``setup.py`` flag to toggle the feature::
+want a setup script flag to toggle the feature::
 
   [my_feature]
   source: custom/my_feature.cmake
@@ -37,8 +37,8 @@ good code quality, and of general interest, you can suggest it to be part of
 the standard set of modules or even a core feature.
 
 
-How can I get a setup.py flag --X that toggles a CMake variable?
-----------------------------------------------------------------
+How can I get a setup flag --X that toggles a CMake variable?
+-------------------------------------------------------------
 
 The following will add a ``--something`` flag which toggles the CMake variable
 ``ENABLE_SOMETHING``::
@@ -48,6 +48,17 @@ The following will add a ``--something`` flag which toggles the CMake variable
   define: '-DENABLE_SOMETHING={0}'.format(arguments['--something'])
 
 
+Can I change the name of the setup script?
+------------------------------------------
+
+Yes you can do that in ``autocmake.cfg``. Here we for instance change the name to "configure"::
+
+  [project]
+  name: myproject
+  min_cmake_version: 2.8
+  setup_script: configure
+
+
 In CMake I can do feature X - can I do that also with Autocmake?
 ----------------------------------------------------------------
 
@@ -63,26 +74,26 @@ Yes, you probably want to do that. Autocmake generates a number of files which
 in principle could be generated at configure- or build-time.  However, you
 probably do not want the users of your code to run any Autocmake scripts like
 ``update.py`` to generate the files they need to build the project. The users
-of your code will run ``setup.py`` directly and expect everything to just work
+of your code will run ``setup`` directly and expect everything to just work
 (TM).
 
 
-The update.py script is overwriting my CMakeLists.txt and setup.py, isn't this bad?
------------------------------------------------------------------------------------
+The update.py script is overwriting my CMakeLists.txt and setup, isn't this bad?
+--------------------------------------------------------------------------------
 
 No, it is not as bad as it first looks. It is a feature. Normally
-``CMakeLists.txt`` and ``setup.py`` should not contain any explicit
+``CMakeLists.txt`` and ``setup`` should not contain any explicit
 customization and therefore should not contain anything that could not be
 regenerated. In any case you should use version control so that you can inspect
-and compare changes introduced to ``CMakeLists.txt`` and ``setup.py`` and
+and compare changes introduced to ``CMakeLists.txt`` and ``setup`` and
 possibly revert them. See also the next remark.
 
 
-But I need to manually edit and customize CMakeLists.txt and setup.py every time I run update.py!?
---------------------------------------------------------------------------------------------------
+But I need to manually edit and customize CMakeLists.txt and setup every time I run update.py!?
+-----------------------------------------------------------------------------------------------
 
 You typically never need to manually edit and customize ``CMakeLists.txt`` and
-``setup.py`` directly. You can introduce customizations in ``autocmake.cfg``
+``setup`` directly. You can introduce customizations in ``autocmake.cfg``
 which get assembled into the front-end scripts.