Comments (5)
I absolutely agree with the sentiment, but both distutils
and numpy.distutils
are messy for building mixed language projects, which is why I found raw Makefiles simplest initially. Haven't used CMake but depending on it seems like quite a lot of overhead.
from f90wrap.
I've build simple Python extensions with distutils and more complex
mixed-language Python extensions with CMake. If you can get distutils to
compile all your files --- for example, if the entire extension is in one
source file --- then that is certainly the easiest. That seems to be the
case with f90wrap, and I would see no reason to change. Thankfully, it
looks like the mixed-language stuff is in the examples.
I've figured out how to build mixed-language extensions with CMake. Yes,
it's a bit of overhead. But CMake is standardized, and that
standardization allows users to compile your project the same as a dozen
others. The example of how to do this is in:
https://github.com/citibob/fexception
This is a good example because it is multi-language (Fortran / Python /
C++), while still being a very small project overall. And it has examples
showing how to use it in each language. The scripts here should be
transferrable to f90_wrap without too much trouble. (The fexception
package might be of interest to f90_wrap users as well; it allows you throw
exceptions in Fortran and catch them in Python. I use this to write Python
unit tests for my Fortran code. I throw an exception deep within the
Fortran code, and I'm then able to inspect and verify the state of the
computation (in Python) at the point the exception was thrown).
When building CMake scripts, it might be useful to grab the C compiler from
Python, rather than relying on the user to specify one (and hoping that it
will be compatible with Python). This can be done as:
import sysconfig
sysconfig.get_config_var('CC')
'/Users/rpfische/macports/gcc49-python3/bin/gcc-mp-4.9'
sysconfig.get_config_var('CFLAGS')
'-Wno-unused-result -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall
-Wstrict-prototypes -pipe -Os -m64'
sysconfig.get_config_var('CXXFLAGS')
sysconfig.get_config_var('CXX')
'/Users/rpfische/macports/gcc49-python3/bin/g++-mp-4.9'
sysconfig.get_config_var('CXX_FLAGS')
(see for more:
http://www.programcreek.com/python/example/66995/distutils.ccompiler.get_default_compiler
)
HOWEVER... one must account for the possibility that the compiler used to
compile Python is no loner available on the current system; thus, the user
should still be able to override this mechanism.
-- Bob
On Wed, Oct 14, 2015 at 4:37 PM, James Kermode [email protected]
wrote:
I absolutely agree with the sentiment, but both distutils and
numpy.distutils are messy for building mixed language projects, which is
why I found raw Makefiles simplest initially. Haven't used CMake but
depending on it seems like quite a lot of overhead.—
Reply to this email directly or view it on GitHub
#27 (comment)
.
from f90wrap.
Thanks for the suggestions. Will consider CMake, and also look at conda which seems to be gaining a lot of traction in the scipy community at the moment.
from f90wrap.
also look at conda which seems to be gaining a lot of traction in the scipy community at the moment.
with conda, you have everything in hand.
from f90wrap.
A comment from a potential user that just discovered this project 10 minutes ago: I also find raw Makefiles perfectly fine :)
from f90wrap.
Related Issues (20)
- IndentationError with python 3.9 HOT 5
- Extra (unnecessary) newline character in .py file for long variable names HOT 3
- more explanations on the provided examples HOT 2
- Handling reserved Python words in f90wrap HOT 6
- Help wrapping a project HOT 7
- Data type determined at run time
- Issues with Compiling MPI Program HOT 3
- Support for Intel oneAPI2022
- multidimensional arrays in derived types broken if compiled with long integers as default HOT 1
- Python 3.11 support HOT 8
- Pre-build f90wrap wheels for windows HOT 3
- Derived types containing allocatable character arrays
- `integer, value, intent(in)`/`integer, value` arguments converted to/wrapped as `real`
- Wrong module class name in a call to `f90wrap.runtime.FortranDerivedTypeArray` HOT 2
- numpy > 1.23 support HOT 2
- Switch to pyproject.toml based build system HOT 7
- duplicate symbol in formal argument list HOT 2
- Issues on Mac OS X - for f90wrap 0.2.12 HOT 1
- BUG: Routines including procedure arguments (callbacks) are excluded HOT 1
- Can `f90wrap`parse FORD docstrings?
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from f90wrap.