I’m experimenting with Wine for Mac, and one thing I have noticed is that it is a pain to compile from source. In fact, that is the only way you can get Wine for Mac as there are no prebuilt binaries. For starters, you need to compile libraries that Wine depends on, which isn’t too bad with the help of MacPorts, but it gets a little complicated with Snow Leopard. Everything compiled via MacPorts is 64-bit on Snow Leopard, and Wine currently only compiles in 32-bit. To solve this, add the “+universal” variant at the end of all the packages you install (i.e. “sudo port install fontconfig +universal”). In some cases, a package will not build in 32-bit mode (in particular the mpg123 library). I was more or less able to get Wine working following the steps outlined on the Wine wiki: http://wiki.winehq.org/MacOSX/Building, but programs I ran on it didn’t look that great. For whatever reason, I was missing xrender, which I think attributed to applications looking bad. I tried installing it with MacPorts, but then I had two versions of X11 on my system, which was causing conflicts when I tried compiling Wine. No good. Each person who compiles Wine has the potential to have different dependencies, which may lead to different behaviors when running Wine. For instance, when I was running Steam, none of the buttons were rounded, and checkboxes weren’t showing up. I almost reported this as a Mac related bug, when the cause was me missing a library somewhere.

What I came up with as a potential solution to this problem involves a program called WineBottler. It is probably the closest thing there is to a distributable binary of Wine, and works great out of the box. This application confirmed my theory that I was missing a library for running Steam. WineBottler had all the libraries to make Wine run well, but it didn’t have the latest version. What I ended up doing was downloading the latest source using git, configuring the build and linking to those libraries included with WineBottler, and installing the newer build over the binaries originally shipped with WineBottler.

1. Download the latest version of WineBottler and install it.
2. Start out by getting the Wine source outlined here: http://wiki.winehq.org/GitWine
3. If you’re on Snow Leopard, run the following commands:

   $ export CFLAGS="-arch i386 -m32";
   $ export CXXFLAGS="$CFLAGS"

4. Set the CPPFLAGS environment variable:

   $ export CPPFLAGS="-I/usr/X11/include -I/Applications/Wine.app/Contents/Resources/include"

5. Set the LDFLAGS environment variable:

   $ export LDFLAGS="-L/usr/X11/lib -L/Applications/Wine.app/Contents/Resources/lib"

6. Configure Wine:

   $ ./configure --prefix=/Applications/Wine.app/Contents/Resources

7. Build Wine:

   $ make depend && make && make install

Referencing the already compiled libraries from Wine.app allow us to build newer versions of Wine without having to worry about having all the correct libraries. Setting the prefix when we run ./configure automatically copies all the newly built binaries over to Wine.app. So now when I open the Wine config for Steam, I now have the latest version of Wine (it was originally 1.1.34):

One potential downside to this is that you may not be able to debug Wine with this setup. I know there is an option in WineBottler to output errors to a log file in ~/Library/Logs/Wine.log, but I’m not sure how verbose it is. And you can’t run “make test” without setting DYLD_FALLBACK_LIBRARY_PATH. I’ve tried doing both in the command line without success thus far.

One direction I hope Wine starts moving towards is removing these dependencies in favor of libraries that are already included in OS X. This would make creating prebuilt binaries much easier, and open Wine up to those who are less technically inclined. I think the Wine maintainers recognize that to some extent, and have listed implementing a Quartz Driver a priority for Wine’s 1.2 release. I personally don’t know what Quartz does/doesn’t allow, but it is conceivable to remove x11 and freetype as required libraries because TrueType rendering is natively supported on the Mac (Apple created it). As I learn more about Wine, I will try and post more information that new developers might find useful.

The purpose of this article is to help both new and existing users get correctly setup with IMAP Gmail. I feel that the default settings in Mail.app and Google’s recommended client settings (found here) are not adequate, and lead to a lot of headaches. Typically, I would have sent mail from my client not show up in Gmail on the web, and mail I deleted from my client still present on the web client! This is not useful if you are trying to have total access to email regardless of location/platform.

To give an overview, Gmail makes heavy use of “labels” in terms of classifying mail. You can specify your own labels as well, but each folder is essentially a “label”. If you’re using an email client, what will usually happens when you delete a message is that it will delete the “label”, but the original message will still be in “All Mail”. This is especially dangerous if you heavily use your client. You would assume messages are getting deleted, when in reality they’re piling up in “All Mail”! I had the unfortunate experience of having this happen to me, and it was not easy to get everything back in order.

1. If you haven’t already done so, enable IMAP in your Gmail settings.
2. Add a new account to Mail.app following these instructions.
3. The next step is to configure the mailbox behavior. I have found that the following settings have worked well for me.
   
4. Next, you want to setup what is called an IMAP prefix under “Advanced”. Another issue with Gmail over IMAP is that folders like “Sent”, “Inbox”, “All Mail” from the web interface are under this [Gmail] folder. Setting the IMAP prefix gets rid of this.
   
5. The last, and most important step to this process is re-mapping the Gmail IMAP folders to behave as default folders in Mail.app. For instance, we selected to store deleted messages on the server and move items to the trash when deleted. By mapping the Gmail “Trash” folder to be the default location for trash, actions on the client are reflected on the web. We want “Spam” from Gmail to be mapped to “Junk” in Mail, “Sent Mail” to “Sent”, “Drafts” to “Drafts”, and “Trash” to “Trash”. To do this, select the Gmail folder in the sidebar you want to map, then go to “Mailbox -> Use This Mailbox For” and select the appropriate equivalence to the selected Gmail folder.
   
   Once you have remapped each folder, they will disappear from the Gmail heading in the sidebar and reappear under their respective section near the top (i.e. Junk, Trash, Sent).

And that’s how you setup IMAP Gmail! These settings may not be perfect, but it addresses the main issue of properly deleting mail and making sure everything is consistent across mediums. If something isn’t clear, or you know of a setting that would make this setup better, feel free to either contact me or post a comment.