All I have to share now is Drizzle client tools (both drizzle command line and drizzledump) for MS Windows are available for Download.
If you have time, please try it and give me feedback.
(Consider this as a temporary location for hosting the binary packages. In future, we shall move to sacred location.)
Kept postponing this post because there is a real dragon is under hatching (CoApp).
See Monty's post.
Help of those tools are required for moving forward because of our dependancy on list of libraries.
Current build is using MinGW.
All started with, Toru's question on my previous blog post. :)
Question was "Does this survive through the tests?" (libdrizzle patches on windows)
Answer is : This is the productive way I can test my libdrizzle patches for windows.
Patches for this windows build of clients are on the way to main trunk.
I am trying to keep the patches as small chunks to ensure proper review and required rework in this earlier stages itself.
Tuesday, August 24, 2010
Wednesday, August 4, 2010
Drizzle on Windows - Challenges ahead
Since Drizzle is Open, I am sure that one day someone will take the mantile to deepest.
As you already know, Drizzle is effectively making use of other opensource libraries available.
(Drizzle developers tell that is because they are lazy. But personally i consider that it is because they (we) are open to the environment and we respect and trust on expertise of other opensource communities)
But same philosophy works against a "builder" and "porter" on non open platform (say windows).
many of this opensource libraries need to be built on (ported???) windows.
Best example is google protobuffer itslef.
latest tarball release of protobuffer won't compile on windows.
(simple googling told me that google already corrected this issue in the branch)
But it is an alarm bell! These powerful libraries are not very well used / tested on Closed Grave yards.
I downloaded tarballs of most of the libraries on which drizzle is dependent on.
all these tarballs expect me to run ./configure and make.
!!!!(puzzled!)...in my language... "dog gets an unbroken coconut as food" (trasilated version)
I think, since windows relys on binary distributions, they are not exepcting us to "make" it.
But there are dedicated people who maintain binary versions; but getting latest version is challenge.
Mingw (Msys) team are doing an amazingly well job here.
No wonder, most of binary versions of these libraries are build on Mingw
I hope thats the way to go deeper.
As you already know, Drizzle is effectively making use of other opensource libraries available.
(Drizzle developers tell that is because they are lazy. But personally i consider that it is because they (we) are open to the environment and we respect and trust on expertise of other opensource communities)
But same philosophy works against a "builder" and "porter" on non open platform (say windows).
many of this opensource libraries need to be built on (ported???) windows.
Best example is google protobuffer itslef.
latest tarball release of protobuffer won't compile on windows.
(simple googling told me that google already corrected this issue in the branch)
But it is an alarm bell! These powerful libraries are not very well used / tested on Closed Grave yards.
I downloaded tarballs of most of the libraries on which drizzle is dependent on.
all these tarballs expect me to run ./configure and make.
!!!!(puzzled!)...in my language... "dog gets an unbroken coconut as food" (trasilated version)
I think, since windows relys on binary distributions, they are not exepcting us to "make" it.
But there are dedicated people who maintain binary versions; but getting latest version is challenge.
Mingw (Msys) team are doing an amazingly well job here.
No wonder, most of binary versions of these libraries are build on Mingw
I hope thats the way to go deeper.
Subscribe to:
Posts (Atom)