On Thu, Aug 12, 2010 at 8:51 PM, David <da...@silveregg.co.jp> wrote: > Hi Kurt, > > On 08/13/2010 03:40 AM, Kurt Smith wrote: >> Hi, >> >> I'm very interested in Bento and think it will be a killer project. >> >> My question: do you anticipate supporting Fortran 90 within Bento, or >> will that be delegated to an external build tool? > > Bento does not support building at all. The idea is that you will be > able to plug your build tool of choice if desired, and bento will just > gives you a very high level description of your extensions. > > Right now, I am working on yaku, which is a simple build tool designed > as a library, and would be used by bento by default. If I can build > scipy with it and keep it simple, I will integrate yaku and bento. This > means at least basic fortran spuport. Otherwise, I may just give up yaku > - if it ends up being as big as say waf, there is really no point in it. > > I was not using waf directly because previous to 1.6, using waf as a > library was not as easy as expected (much better than scons, though), > but this is changing in 1.6. This means I will also need to add fortran > support to waf. I really like waf but was a bit concerned with the lack > of usage - now that samba is working on it, the prospect of long term > support for waf look much better ( > http://wiki.samba.org/index.php/Waf). >
This is all very good to hear. I've been struggling with numpy.distutils for fwrap, and it is a nightmare. My current problem---requiring yet-another-monkeypatch---is getting try_compile in the 'config' stage to work with Fortran 90 sources and .mod files that have to be generated before the 'config' stage begins. Sounds like the best long-term solution is to put effort into better fortran support in waf, unless you plan on yaku's fortran support covering all cases (fortran 77/9X, .mod files, etc.). I'll start looking into that. Is there a repo somewhere, or are you contributing to waf directly? >> There are some >> intricacies with Fortran 90 that make it difficult to use with the >> usual configure-then-build ordering, specifically when the configure >> step depends on .mod files that don't exist until after compilation. > > Could you expand on this ? Nothing prevents the configure step from > building some mod files necessary for configuration a priori. > Are you referring to waf? Or are you speaking of Bento/yaku? I don't know waf that well, but my impression was that the configure & build stages are fairly separate with compilation only in the latter. But that was just an initial impression from a quick look at the source. A somewhat separate question: Since both waf & bento have 'configure' steps how do they coordinate with each other, i.e. what is the 'responsibility' for each configure step? (same goes for bento/scons, or any other build tool, I reckon.) >> >> Also, what about projects with Pyrex/Cython sources: will Bento >> internally support .pyx files? > > You can already build extensions with cython with bento+yaku. You just > add .pyx files as sources in the Extension section of the bento.info, > and it is then up to the build tool to deal with .pyx. > > You can see an example in the port of nipy build to bento, which has > cython files: > > http://github.com/cournape/nipy/tree/bento_build > > Note that even though the bento.info format itself is pretty stable, > anything that goes in bscript files (to customize build) keeps changing > and is highly unstable. I still have no clear idea about the API > (scipy's build idiosyncraties keep breaking the assumptions I have made > so far :) ). > > To somewhat deal with the unstability API-wise, you can include a copy > of bento+yaku in your project, as I have done in nipy. It is a > self-contained file which is about 350 kb (and down to 80 kb if you > don't care about supporting building windows installers). > Interesting. Kinda like waf's recommendation to include waf with the project, which I like. Is this recommended for bento/yaku, too, or just a current stopgap? > cheers, > > David > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
