[Numpy-discussion] Refactor fork uses the ./configure, make, make install process.

[David]

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).

cheers,

David