In August Productions

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)

Even the most casual of acquaintances knows that I really, really hate software that doesn't understand how we do things out here in the Open Source world. We have tools, really amazing ones, called ... "Package Managers" which allow us to "Install" software and describe the "Relationships" between elements. Apparently they can't seem to figure out how to deal with software dependencies and instead they opt for the "copy into tree and fork" method:

Google is forking existing FOSS code bits for Chromium like a rabbit makes babies: frequently, and usually, without much thought. Rather than leverage the existing APIs from upstream projects like icu, libjingle, and sqlite (just to name a few), they simply fork a point in time of that code and hack their API to shreds for chromium to use. This is akin to much of the Java methodology, which I can sum up as "I'd like to use this third-party code, but my application is too special to use it as is, so I covered it with Bedazzler Jewels and Neon Underlighting, then bury my blinged out copy in my application.". A fair amount of the upstream Chromium devs seem to have Java backgrounds, which may explain this behavior, but it does not excuse it. This behavior should be a last resort, not a first instinct. What should happen is this:

[google] hey, it sure would be nice if we could use sqlite in chromium for our local db needs.

[google] hmm, the sqlite API doesn't mesh 100% with how I'd like chromium to use it

[google] hey sqlite upstream, there are a few places where we'd like to see API improvements 
            so chromium can leverage it for our use-case

[sqlite_upstream] hey google, so cool that you want to use our code.

* sqlite_upstream looks at google's proposed changes to sqlite *

[sqlite_upstream] interesting, you could try using the foo_bar function for your camel launching
needs, but the rest of the changes seem okay

* sqlite_upstream commits changes to the source tree in commit rev 12345 *

[sqlite_upstream] Our next release will support that.

[google] yay! we'll tell people to either apply our patch or use commit rev 12345 or newer. 

As much as I appreciate Google's attempt at openness documented yesterday - and it REALLY is great and many steps in the right direction, it would be great if they'd also learn some of the process we already use out here. If they think it sucks and want to improve on it, then great - but start from what's there, don't just ignore it and hope we don't notice.

I keep running in to issues with how folks use config.h, so I thought I'd clear up any confusion folks have. For those who haven't been following along at home, the autotools (i.e. autoconf and autoheader in this case) generate a file called config.h which contains a bunch of defines to help control the build based on what things exist or don't exist on your system. There are two main rules for this file that lots of folks get wrong:

1. config.h should ALWAYS be the first thing included by EVERY non-header C/C++ file in your project.
2. config.h should NEVER NEVER NEVER NEVER NEVER NEVER be installed.

Why?

For the first point, you must ensure that config.h is included first, because it sets behaviors. It must be included before any system headers because it may contain things that control the behavior of the system headers. It must be included before any local headers because it's going to define things like HAVE_SYS_STAT_H which will let you know if it's safe to include sys/stat.h (it is, by the way - it exists everywhere you care about - but that's not the point here) There is nothing, and I do mean NOTHING to be gained by including it anywhere else, in any other order, or in fact, even about putting any extra effort into thinking about where it might be cool to include config.h. The ONLY thing you will accomplish is making your software more fragile.

For the second point, it must never be installed because it unconditionally sets a bunch of defines based on the state of the machine where configure was run. That state has nothing to do with the state of the machine where your headers are installed, so the settings found in config.h are at best coincidentally correct, and at worst out-right lies. In addition, it's probably not just you using autotools for your project. autoconf and automake are, for better or for worse, pretty much the most common build system out there. So if your are shipping a config.h and your shipped headers are including it, and someone is trying to use autotools in their project which consumes your code... FAIL. Symbols will collide and all manner of pain will ensue.

*NOTE* Renaming config.h to something else does not mitigate this. The problem is the common non-prefixed name of config.h defines... like PACKAGE or VERSION.

Now, you might respond that your public headers need defines from config.h to operate properly. There are two answers to this. One is that you need to redesign your public headers, as they are unclean. (and nobody likes dirty headers) Two is that, for your project, if every non-header file includes config.h before they include anything else,  then the defines will be quite happily present in scope when any of your headers are read. Be warned though - don't count on this too heavily in your public headers ... because then you'll be counting on someone out there having run the same set of autoconf checks you did. (Yes. Proper public headers are tricky)Don't forget that many OS features have defined and standard feature check macros you can test without having to do an autoconf test for the feature.

In short though - just include config.h FIRST in all of your implementation files and NEVER under ANY circumstances install it, and you'll be golden.