the default setup script name becomes "setup"
it can be changed in autocmake.cfg
This commit is contained in:
Radovan Bast
@ -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
|
||||
|
||||
@ -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::
|
||||
|
||||
|
||||
@ -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
|
||||
|
||||
|
||||
@ -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.
|
||||
|
||||
|
||||
|
||||
@ -8,7 +8,7 @@ solutions exist to this problem: GNU Makefiles is the traditional approach.
|
||||
Today, CMake is one of the trendier alternatives which can generate Makefiles
|
||||
starting from a file called ``CMakeLists.txt``.
|
||||
Autocmake composes 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`` as well as a setup script, which serves as a front-end to
|
||||
``CMakeLists.txt``. All this is done based on a lightweight ``autocmake.cfg``
|
||||
file::
|
||||
|
||||
@ -24,9 +24,9 @@ file::
|
||||
| python update.py .. |
|
||||
| |
|
||||
v v
|
||||
CMakeLists.txt (and setup.py front-end)
|
||||
CMakeLists.txt (and setup front-end)
|
||||
| |
|
||||
| python setup.py |
|
||||
| python setup |
|
||||
| which invokes CMake |
|
||||
v User of the code
|
||||
Makefile (or something else) |
|
||||
@ -44,7 +44,7 @@ scientific projects which typically have very similar requirements:
|
||||
|
||||
- Fortran and/or C and/or C++ support
|
||||
- Tuning of compiler flags
|
||||
- Front-end script with good defaults (setup.py)
|
||||
- Front-end script with good defaults
|
||||
- Support for parallelization: MPI, OMP, CUDA
|
||||
- Math libraries: BLAS, LAPACK
|
||||
|
||||
|
||||
@ -7,9 +7,9 @@ Autocmake update and test scripts require Python 2.7 or higher. We try to also
|
||||
support Python 3 (tested with Python 3.4). If the script fails with Python 3,
|
||||
consider this a bug and please file an issue.
|
||||
|
||||
The generated ``setup.py`` runs with Python >= 2.7 (also tested with Python
|
||||
The generated setup script runs with Python >= 2.7 (also tested with Python
|
||||
3.4; probably also lower).
|
||||
|
||||
.. todo::
|
||||
|
||||
Figure out lower Python version bound for setup.py.
|
||||
Figure out lower Python version bound for setup.
|
||||
|
||||
@ -9,7 +9,7 @@ TL;DR How do I compile the code?
|
||||
|
||||
::
|
||||
|
||||
$ python setup.py [-h]
|
||||
$ python setup [-h]
|
||||
$ cd build
|
||||
$ make
|
||||
|
||||
@ -17,10 +17,10 @@ TL;DR How do I compile the code?
|
||||
How can I specify the compiler?
|
||||
-------------------------------
|
||||
|
||||
By default ``setup.py`` will attempt GNU compilers.
|
||||
By default the setup script will attempt GNU compilers.
|
||||
You can specify compilers manually like this::
|
||||
|
||||
$ python setup.py --fc=ifort --cc=icc --cxx=icpc
|
||||
$ python setup --fc=ifort --cc=icc --cxx=icpc
|
||||
|
||||
|
||||
How can I add compiler flags?
|
||||
@ -29,7 +29,7 @@ How can I add compiler flags?
|
||||
You can do this with ``--extra-fc-flags``, ``--extra-cc-flags``, or
|
||||
``--extra-cxx-flags`` (depending on the set of enabled languages)::
|
||||
|
||||
$ python setup.py --fc=gfortran --extra-fc-flags='-some-exotic-flag'
|
||||
$ python setup --fc=gfortran --extra-fc-flags='-some-exotic-flag'
|
||||
|
||||
|
||||
How can I redefine compiler flags?
|
||||
@ -42,9 +42,9 @@ these environment variables you have full control over the flags
|
||||
without editing CMake files.
|
||||
|
||||
|
||||
How can I select CMake options via the setup.py script?
|
||||
-------------------------------------------------------
|
||||
How can I select CMake options via the setup script?
|
||||
----------------------------------------------------
|
||||
|
||||
Like this::
|
||||
|
||||
$ python setup.py --cmake-options="-DTHIS_OPTION=ON -DTHAT_OPTION=OFF"
|
||||
$ python setup --cmake-options="-DTHIS_OPTION=ON -DTHAT_OPTION=OFF"
|
||||
|
||||
Reference in New Issue
Block a user