On Tue, Mar 30, 2010 at 12:52 PM, Ondrej Certik <[email protected]> wrote: > On Tue, Mar 30, 2010 at 9:17 AM, Kurt Smith <[email protected]> wrote: >> On Thu, Mar 25, 2010 at 12:52 AM, Dag Sverre Seljebotn >> <[email protected]> wrote: >> [snip] >> >>>> >>>> That should be enough. I use cmake, so I'd appreciate if fwrap could >>>> just spit the C (or fortran or both) files, that I compile and link >>>> myself. Just like Cython does. (I read some issues with integrating >>> >>> Note that fwrap generates both C, Fortran and Cython code to make >>> everything work together in a standard-compliant way... >>> >>> Also, unless things have changed, a configuration script must be run as >>> part of the build process to detect which C types correspond to which >>> Fortran types. f2py just makes blatant assumptions in this area and you >>> could probably impose such blatant assumptions yourself too if you want >>> to avoid complicating your build. >> >> I'm shaking out these details as time goes on -- I'm settling on a few >> solutions for different use scenarios (not all are implemented, >> though). >> >> 1) David Cournapeau indicated that generating, compiling and running a >> fortran 'genconfig' program is a problem for using fwrap with scipy -- >> I believe because of windows restrictions. This is the easiest way to >> get the config modules/headers/pxd's generated without an fwrap >> dependency. >> >> 2) Allow the user to specify the mapping between each fortran >> kind-type-parameter and C type, with a dictionary in a specification >> file. This is brain-dead simple to get working -- not as >> user-friendly, though. May lead to hard-to-debug runtime segfaults if >> the mappings are specified incorrectly. >> >> 3) Let fwrap do it all -- but this requires fwrap to do the >> compilation step. Safer & friendlier, but introduces a compile-time >> dependency. > > As I wrote in my earlier email above, I think a project (or fwrap) has > to have runtime tests, that the mappings work. In particular, it > should test every type (in and out) and make sure it works. Such a > test imho has to be included with the project and the idea is that if > the tests pass, then the wrappers work (and there will be no runtime > segfaults). And fwrap can make a good job at trying to guess the types > right, but imho the tests are necessary.
I'm in complete agreement, and fwrap is very thorough about testing C-Fortran type compatibility. If it detects incompatibility it will raise an exception. The #2 option above should have emphasized the "may" qualifier. The difficulty is that there are some corner cases when fwrap might not have access to everything it needs to ensure type compatibility, and so the spec file would allow the user to fill in the missing info -- but this is a corner case and unlikely to occur. Kurt BTW -- I just set up an fwrap-users mailing list on googlegroups. Perhaps we should take the conversation there. http://groups.google.com/group/fwrap-users _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
