Wednesday 30 May 2012

Organizing OSS on Windows

In my old days as a developer, the development environment was a simple affair. I had an IDE, and it would take care of most of my equally simple needs.

The first time I had to deal with installing/configuring additional components/libs was with Delphi. But even that was simple. Same thing with C++ Builder. The most complex thing I remember doing back then was installing SGI STL. And even that was simple.

These days... as I said, if you're working on Windows, you either use Visual C++, or you're in for a whole lotta work. Thankfully, you're also in for a whole lotta learning.

So, after installing or building perl, OpenSSL, zlib, libssh2, Boost, mingw, msys, git, msysgit, msmtp, etc, my HD is a bit of a mess. You can't properly plan for what you don't know, and I never found (in truth, never looked for, either) a guide on how to organize these things on Windows.

So, I've decided to roll my own. It all boils down to 3 points:
  • Includes
  • Binaries
  • PATH (for additional utilities)

I'll start with two main folders
  • tool
  • lib

tool will have stuff like perl, mingw + msys, git, msysgit, or msmtp. These are not libraries, they're tools necessary for the job. Where possible, I'll have a main folder for each tool (e.g., msmtp), which will contain a folder for each different version (e.g., msmtp-1.4.27, msmtp-1.4.28). It's important to keep track of your PATH (on System, on Windows Control Panel), to make sure it's pointing to the version you want.

lib will follow the same principle. Taking libssh2 as an example, I would have a main folder, say libssh2, and sub-folders for libssh2-1.4.1 and libssh2-1.4.2. When dealing with libraries, we have to take care of the include and lib paths. Include is rather simple, but lib has several options - dynamic vs. static and debug vs. release.

gcc (and that's 3 consecutive paragraphs starting in lowercase) uses dynamic linking, by default. This means if the lib path contains both a dynamic and a static version of the same lib, it'll use the dynamic (and, naturally, it'll require it at runtime). So, where possible, I'll try to have two lib folders - one with dynamic libs (both debug and release), and another with static libs (also, both debug and release).

Another advantage of having your own main folder above the lib's/util's main folder is that it gives you a handy and - hopefully - uncluttered location for any notes you may find useful (e.g., how to configure msmtp to use your gmail account to send e-mail). Yes, I know there's a plethora of utilities to store these notes and to sync with more cloudy devices than you care to imagine. This is just another alternative.

And that pretty much covers it all for now. When I do get around to clean up this mess, I'll post the results here.

No comments:

Post a Comment