libdrizzle in Visual Studio

Thanks to Jobin's work with mingw and getting libdrizzle to compile on Windows at all, I have been able to get it working in Visual Studio natively. The code is in trunk now.

The approach I took, which is how I'm going to approach Windows and Visual Studio for all of our stuff, is to not worry with analogues to things like configure on Windows. Windows is a very different platform from Linux, and there is no need to attempt to duplicate Linux process there. To that end, the goal at least for now will be static VS Solution files and a set of instructions of how to get depends installed so that the Solution can find them. 

I'm excited to start poking at Garrett Serack's CoApp Project, which has some tools do do tracing of things like make to help with the initial project creation... and I fully expect to take advantage of his work in terms of creating installable packages.

Jobin has started working on Drizzle itself and has the drizzle client working so far.

2 comments

libdrizzle - now with windows

Recently, Jobin took up the mantle of starting to poke at Windows support for Drizzle. We decided that step 1 is getting libdrizzle building on Windows - not to mention we could solve a few systemic "how to go about it" problems on a much simpler codebase.

We decided to go the mingw route - for two reasons.

 

  1. on windows we wouldn't have to solve the build problem yet
  2. on linux we can cross-compile, and then I can spend less time connecting to a windows machine 

 

I'm happy to say that the branch implementing support for building under mingw has been merged in to trunk - so please go hammer at it and tell me that I'm an idiot.

If you're on linux and want to play, you'll need mingw32 and mingw32-pthread. You may notice that mingw-pthread isn't in the Ubuntu archive... that's ok - I added a package for it in the drizzle-developers ppa (add-apt-repository ppa:drizzle-developers/ppa) Once you're set with that, it's as simple as:

 bzr branch lp:libdrizzle
 cd libdrizzle 
 ./config/autorun.sh
 ./configure --build=x86_64-unknown-linux-gnu --host=i586-mingw32msvc
 make

And you're off to the races. Now, as for actually doing anything with it, well, I'm expecting some windows person to fill in details on that.

Next up - building under Visual Studio. (oh, and getting Drizzle itself working)

4 comments

O, hai intltool!

Almost no one will ever notice anything about this, but I'm excited, so I thought I'd share.

Instead of using the build infrastructure installed by gettextize to handle message translations, we're now using the more modern replacement, intltool.

Unless you're actually hacking on build, this will mean nothing - translations are still done via launchpad - Drizzle still uses gettext() to translate strings. It's purely a tooling change which means the build is less brittle and I'm slightly less ornery. Oh, and we have many less random generated files committed to bzr. I like deleting files.

2 comments
Tags: mysql drizzle

Changes in Option Processing

Change is in this air this summer in Drizzle-land. One of our GSoC students, Vijay Samuel, has been hard at work replacing the options processing system we inherited from MySQL, my_getopt, with one based on boost::program_options. We've been merging his work in to trunk for a while now, and he's made really excellent progress, so it's probably about time to point out how the new system will be different from the MySQL one. There are three main changes afoot here, and I'm actually pretty pleased with all three of them:

 

  1. Plugin Option Prefixing
  2. Dashes v. Underscores
  3. Config Files

 

A few of these changes are still in the middle of their transition, so I'm just going to describe the finished system, but we've essentially got all of the client programs and most of the plugins done at this point. 

Plugin Option Prefixing

In the old system, when a module registered a new option or variable, we would concatenate the module's name on to the front of the option name with a "_". So, for instance, the mysql_protocol module has an option for setting the port, which wound up being named "mysql_protocol_port". In the new system, boost actually understands grouping and namespacing of options, and we decided to take advantage of that by mapping a plugin module to a group. This means that the concat character is now a "." (that's a dot if your eyesight is bad)

Dashes v. Underscores

In addition to that, boost doesn't know anything about the long-standing MySQL tradition of going out of the way to allow you to do things as many ways as humanly possible. To Boost, the strings "mysql_protocol" and "mysql-protocol" are, well, different. We considered writing a parser plugin for it to do normalization for us, but then we made the other decision.

Dashes and Underscores are different.

Now this may royal screw some people who may have enjoyed making art by listing an option like "auto-increment_increment" before, and to those people I'm sorry, because I really do like injecting art into day to day life. Nonetheless, from this day forth let the decree be heard...

Options have all been normalized to use no underscores and to use only dashes.

On the off chance you can't follow the logic there, that means that the command line option for setting the MySQL protocol port in Drizzle is now: --mysql-protocol.port=3306

Config File Changes

But wait, there's more...

First of all, we changed from having one master config file for everything with sections in it for different programs to having one config file per program. drizzled will read "/etc/drizzle/drizzled.cnf". The command line clients will also read a few more, since you might want to repeat yourself - so drizzleddump will read ~/.conf/drizzle/drizzledump.cnf, ~/.conf/drizzle/client.cnf, /etc/drizzle/drizzledump.cnf and /etc/drizzle/client.cnf, with files listed first in that list overriding values in files later in the list. (In case you're wondering about the ~/.config part, it's part of the freedesktop.org Base Directory Specification. Since we didn't have a system for this before, it seemed sensible enough to just follow the standard for user/client utilities here.

The files are still mostly ini-style files, except they do not require a base [section] header. So just stick "datadir=/var/lib/drizzle" into /etc/drizzle/drizzled.cnf and you're off to the races. However - remember that grouping thing I mentioned before- in the boost world, section headings translate to option prefixes joined by, you guessed it, a dot. This means you can do:

datadir=/var/lib/drizzle 
[innodb]
buffer-pool-size=100G
log-file-size=1M 
And be good to go. We're also thinking about having /etc/drizzle/${plugin_name}.cnf added for each plugin... but haven't actually looked at what that will look like yet, so don't hold me to that.
4 comments
Tags: mysql drizzle

NoSQL gaining ground on Your Mom

While sitting around with Stewart, Eric, Max and Beer at the MySQL Conference and Expo, Stewart thought it would be funny if someone would do a graph showing the trend of Google searches comparing NoSQL and Your Mom. Always wanting to make Stewart laugh, I ran over to Google Trends to see if it could make a graph.

NoSQL vs. Your Mom

Given all the hype these days, you might think that Your Mom would stand no chance against the Juggernaut of NoSQL. But I was quite surprised to see that Your Mom really stuck it to NoSQL. Giving NoSQL some credit, it is making some progress.

Surely then it's a bogus test. I'm graphing tech jargon against a phrase in the common vernacular. It must be the case, given that MySQL is being replaced with NoSQL everywhere, surely adding MySQL in to the trends mix would just make me a sad little Fail Whale.

NoSQL vs. Your Mom vs. MySQL

Oops. MySQL still seems to be considerably more popular than Your Mom. Perhaps suppositions made while sitting in the Hyatt aren't always correct.

606 comments
Tags: mysql drizzle