[Numpy-discussion] Refactor fork uses the ./configure, make, make install process.
david at silveregg.co.jp
Sun Dec 5 20:03:05 EST 2010
On 12/05/2010 05:57 AM, Dag Sverre Seljebotn wrote:
> On 12/04/2010 09:11 PM, Charles R Harris wrote:
>> On Sat, Dec 4, 2010 at 12:59 PM, Ilan Schnell <ischnell at enthought.com
>> <mailto:ischnell at enthought.com>> wrote:
>> Yes, numpy-refactor builds of top of libndarray. The whole point
>> was that the libndarray is independent of the interface, i.e. the
>> CPython or the IronPython interface, and possibly other (Jython)
>> in the future.
>> Looking at different building/packaging solutions for libndarray,
>> autoconf make things very easy, it's a well established pattern,
>> I'm sure David C. will agree.
>> I know he has expressed reservations about it on non-posix platforms
>> and some large projects have moved away from it. I'm not saying it
>> isn't the best short term solution so you folks can get on with the
>> job, but it may be that long term we will want to look elsewhere.
> Such as perhaps waf for building libndarray, which seems like it will be
> much easier to make work nicely with Bento etc. than autoconf (again,
> speaking long-term).
> Also, it'd be good to avoid a seperate build system for Windows (problem
> of keeping changes sync-ed with Visual Studio projects etc. etc.).
Is support for visual studio projects a requirement for the refactoring
? If so, the only alternative to keeping changes in sync is to be able
to generate the project files from a description, which is not so easy
(and quite time consuming). I know of at least two tools doing that:
cmake and gpy (the build system used for chrome).
More information about the NumPy-Discussion