On Tue, 27 May 2008, Frank Niessink wrote: > Hi Jerome, > > 2008/5/27 Jerome Laheurte <[EMAIL PROTECTED]>: >> Under Windows and MacOS, nothing. Under Linux, it's difficult to say; >> considering the various versions of Python/glibc shipped with today's >> distros, there is no way to make a "universal" binary. The glibc part >> is moot, since most modern distros use the same major >> (binary-compatible) version. The Python version may be a problem, but >> since TC explicitely depends on 2.5, it's not a real problem. > > Officially it's python >=2.4 currently, although 2.5 is shipped with > the Windows and Mac installers.
Indeed. I'll have to check, but I think there is no binary incompatibility between the 2.4 and 2.5 C APIs. >> When I think about it, even for Linux, the prerequisites are not much >> stricter than what is already required (Python 2.5, latest wxPython >> version or so). >> >> So deploying the binary extension module will work for 99% users, >> IMHO, without having them install anything else. People for whom it >> will not work (very old distros users, for instance) probably have the >> technical knowledge necessary to build the extension from source. > > Will building the extension module be a distutils command? E.g. will > "python setup.py build install" work for Linux users? Except maybe under MacOS. I'll have to see how distutils handles the whole PPC/Intel/universal stuff. > PS: I'm getting more and more excited about this. We may also want to > think about making syncing the primary persistence mechanism so we > could add different back ends that support multiple users more easily > (e.g. a database). Mmmh, why not. I still have to study the vcard spec in order to see if it allows "private" application-specific data. In the current prototype for instance, task parent-child relations are lost to the server, among other things.
