I can’t document everything from scratch since I don’t have a machine that’s “virgin” enough for me to document that. This machine has been touched by Fink, MacPorts, Rudix, and several hand-build packages; I’m not sure if MacFUSE installs the necessary stuff for pkg-config.

But, let’s presume you:
a) installed macfuse,
b) fetched pkg-config source code from freedesktop.org (I took 0.25)
c) built it and installed it (./configure, make, sudo make install)
d) switched to pristine Python 2.6 that Apple ships with Snow Leopard.

I’m also obviously using Snow Leopard, so no guarantees about other OS X versions.

Ok, and now come the tips…

Fixing pkg-config spec

You need to screw around with /usr/local/lib/pkgconfig/fuse.pc. Last line should be:

Cflags: -I${includedir}/fuse -D_FILE_OFFSET_BITS=64

change that into:

Cflags: -I${includedir}/fuse -D__FreeBSD__=10 -D_FILE_OFFSET_BITS=64

Now for something undocumented. We’re still not done fixing fuse.pc. Apart form adding above reference to FreeBSD, add this (source: Erik Larsson):

Cflags: -I${includedir}/fuse -D__FreeBSD__=10 -D_FILE_OFFSET_BITS=64
-D__DARWIN_64_BIT_INO_T=0

Attempting to build fuse-python-hg

Hopefully you fetched it from upstream Mercurial repo: http://mercurial.creo.hu/repos/fuse-python/hg since that’s what I did. Current tip is changeset 111:c490d831ae11 — if something breaks for you, try switching to that changeset.

So now you run:

/usr/bin/python setup.py build

(full path to Python specified, since you want to be sure you’re running Apple’s Python)

Now you get a few interesting errors:

running build
running build_py
running build_ext
building 'fuseparts._fusemodule' extension
gcc-4.2 -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -fwrapv -Os -Wall -Wstrict-prototypes -DENABLE_DTRACE -arch i386 -arch ppc -arch x86_64 -pipe -I/usr/local/include/fuse -I/System/Library/Frameworks/Python.framework/Versions/2.6/include/python2.6 -c fuseparts/_fusemodule.c -o build/temp.macosx-10.6-universal-2.6/fuseparts/_fusemodule.o -D__FreeBSD__=10 -D_FILE_OFFSET_BITS=64
In file included from /System/Library/Frameworks/Python.framework/Versions/2.6/include/python2.6/Python.h:58,
from fuseparts/_fusemodule.c:35:
/System/Library/Frameworks/Python.framework/Versions/2.6/include/python2.6/pyport.h:513:23: error: osreldate.h: No such file or directory
fuseparts/_fusemodule.c: In function ‘Fuse_main’:
fuseparts/_fusemodule.c:1009: warning: assignment from incompatible pointer type
fuseparts/_fusemodule.c:1011: warning: assignment from incompatible pointer type
In file included from /System/Library/Frameworks/Python.framework/Versions/2.6/include/python2.6/Python.h:58,
from fuseparts/_fusemodule.c:35:
/System/Library/Frameworks/Python.framework/Versions/2.6/include/python2.6/pyport.h:513:23: error: osreldate.h: No such file or directory
fuseparts/_fusemodule.c: In function ‘Fuse_main’:
fuseparts/_fusemodule.c:1009: warning: assignment from incompatible pointer type
fuseparts/_fusemodule.c:1011: warning: assignment from incompatible pointer type
In file included from /System/Library/Frameworks/Python.framework/Versions/2.6/include/python2.6/Python.h:58,
from fuseparts/_fusemodule.c:35:
/System/Library/Frameworks/Python.framework/Versions/2.6/include/python2.6/pyport.h:513:23: error: osreldate.h: No such file or directory
fuseparts/_fusemodule.c: In function ‘Fuse_main’:
fuseparts/_fusemodule.c:1009: warning: assignment from incompatible pointer type
fuseparts/_fusemodule.c:1011: warning: assignment from incompatible pointer type
lipo: can't open input file: /var/folders/mc/mcBRWcxRFySy2lZ7jzugjU+++TI/-Tmp-//ccXQWCqD.out (No such file or directory)
error: command 'gcc-4.2' failed with exit status 1

Heh, would you look at that — we’re missing a file.

/System/Library/Frameworks/Python.framework/Versions/2.6/include/python2.6/pyport.h:513:23: error: osreldate.h: No such file or directory

Now how are we going to fix that? Motokazu Nishimura has simply touch’ed this file. Let’s do that — I would suggest you do remove it afterwards.

The-Evil-MacBook:fuse-python-hg ivucica$ /usr/bin/python setup.py  buildrunning build
running build_py
running build_ext
building 'fuseparts._fusemodule' extension
gcc-4.2 -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -fwrapv -Os -Wall -Wstrict-prototypes -DENABLE_DTRACE -arch i386 -arch ppc -arch x86_64 -pipe -I/usr/local/include/fuse -I/System/Library/Frameworks/Python.framework/Versions/2.6/include/python2.6 -c fuseparts/_fusemodule.c -o build/temp.macosx-10.6-universal-2.6/fuseparts/_fusemodule.o -D__FreeBSD__=10 -D_FILE_OFFSET_BITS=64
fuseparts/_fusemodule.c: In function ‘Fuse_main’:
fuseparts/_fusemodule.c:1009: warning: assignment from incompatible pointer type
fuseparts/_fusemodule.c:1011: warning: assignment from incompatible pointer type
fuseparts/_fusemodule.c: In function ‘Fuse_main’:
fuseparts/_fusemodule.c:1009: warning: assignment from incompatible pointer type
fuseparts/_fusemodule.c:1011: warning: assignment from incompatible pointer type
fuseparts/_fusemodule.c: In function ‘Fuse_main’:
fuseparts/_fusemodule.c:1009: warning: assignment from incompatible pointer type
fuseparts/_fusemodule.c:1011: warning: assignment from incompatible pointer type
gcc-4.2 -Wl,-F. -bundle -undefined dynamic_lookup -arch i386 -arch ppc -arch x86_64 build/temp.macosx-10.6-universal-2.6/fuseparts/_fusemodule.o -L/usr/local/lib -lfuse -liconv -o build/lib.macosx-10.6-universal-2.6/fuseparts/_fusemodule.so

Ok, let’s remove that file — it’s always a bad idea to modify stuff in /System on Mac!

The-Evil-MacBook:fuse-python-hg ivucica$ sudo rm /System/Library/Frameworks/Python.framework/Versions/2.6/include/python2.6/osreldate.h

How to switch to Apple’s Python?

Any installer that I had didn’t touch Python that was installed by Apple. So probably all you need to do is switch back to using “python” executable installed in /usr/bin.

export PATH=/usr/bin:$PATH

Note, if you’ve overridden anything else commonly used from /usr/bin by placing path of alternative program before /usr/bin, that will be restored now as well. For example, if you have non-system ls (for whatever reason), and you added that by placing /usr/local/bin before /usr/bin… well, now you’re back to Apple’s original variant.

Where to get various libs?

While google-docs-fs manual already specifies which libs you need, they didn’t mention where to get ’em EXACTLY, and which version&variant.

pkg-config

grab 0.25 from http://pkg-config.freedesktop.org/releases/. Then: tar xvvfz pkg-config-0.25.tar.gz; cd pkg-config-0.25; ./configure; make; sudo make install

MacFUSE

grab latest release from http://code.google.com/p/macfuse/downloads/list. Just install it through GUI.

Fuse-Python

After installing Mercurial for OS X through GUI, fetch Fuse-Python by doing:

hg clone http://mercurial.creo.hu/repos/fuse-python/hg fuse/python

Install it as explained in section “Attempting to build fuse-python-hg”, above.

gdata-python-client

Grab gdata-2.0.12.tar.gz from http://code.google.com/p/gdata-python-client/downloads/list

tar xvvfz gdata-2.0.12.tar.gz
cd gdata-2.0.12
sudo /usr/bin/python setup.py install

Installing google-docs-fs

I’ve worked on a few fixes for google-docs-fs. They’re available in my repository clone. You can fetch it by doing:

 hg clone https://ivucica-gdocsfs-mac.googlecode.com/hg/ ivucica-gdocsfs-mac

To build, do as you would with mainline:

/usr/bin/python setup.py build

I’m not sure you should do this, but you can install systemwide:

sudo /usr/bin/python setup.py install

I’ll instead keep on running from the development directory, thank you very much 😉

Note that my clone will almost certainly not be updated later on; you could also pull-and-merge from the main repository, and pray that there are no conflicts.

Testing

Initially I didn’t bother getting gmount script to work. Unless you use my clone, it probably won’t work. You could test by going to google-docs-fs directory, and:

/usr/bin/python gmount.py username@gmail.com somedir/

If you use my clone, then use

./gmount username@gmail.com somedir/

To see debug info, add “-d” to end of that command line.

I am happy to report that I got google-docs-fs to work acceptably on my Mac in changeset c4da54c09b5c in my clone 🙂

Major issues

1. Don’t bother using any Mac program that utilizes NSDocument APIs to save directly to the gmount’ed volume. TextEdit, for example, will fail. It requires ability to move around/write randomly-named filenames, something google-docs-fs does not support.
2. google-docs-fs is EXTREMELY slow; every operation is done directly on server, and not queued for later execution. This means you should most definitely turn off icon previews in Finder as soon as you can, and you should do your work elsewhere, only using google-docs-fs as a handly way to do uploading to Google Docs. Forget about directly working on the remote volume.

10/10/2013: Updated formatting and nothing else

–
via blog.vucica.net