I couldn’t find a list of the results of FileSystem.supportedFileAttributeViews() on various operating systems, so I made one:

• UnixFileSystem/BsdFileSystem/MacOSXFileSystem: “basic”, “posix”, “unix”, “owner”
• LinuxFileSystem: Unix + “dos”, “user”
• SolarisFileSystem: Unix + “acl”, “user”
• WindowsFileSystem: “basic”, “dos”, “acl”, “owner”, “user”

If you’re like me (and condolences if you are), you’ve often started a local Git repository for a new project, and then later wanted to create a shared upstream repository on another computer. (GitHub walks you through this, but let’s assume you want to manage the shared repository yourself.) Before I knew Git very well, I did this clumsily by copying the .git directory and tweaking its config file and permissions (which was especially difficult when moving from a Windows desktop to a Linux server). But that is very un-Git; here’s a much better method:

On the upstream server, go to where you want the repository to be located and create a bare, shared repository:

$ cd /var/git
$ git init --bare --shared myrepo.git

Then on your local machine, simply add a remote for the new shared repository and push the local repository up to it with the -u option:

$ git remote add origin ssh://myuser@myserver/var/git/myrepo.git
$ git push -u origin master

The -u option is short for --set-upstream. From the git-push man page:

For every branch that is up to date or successfully pushed, add upstream (tracking) reference, used by argument-less git-pull(1) and other commands.

Now with just two Git commands, your local repository acts just like you’d cloned it from your new shared repository.

Note: If you have a group of users that you want to be able to modify the repository, ensure that it is owned by that group and is group writable. For example:

$ chgrp -R git /var/git
$ chmod -R g+rwx /var/git
$ ls -ld /var/git
drwxrwx--- 22 git git 4.0K Jul 16 12:00 /var/git

After much googling, I could not find any tools for converting a UTF-8 string into an escaped C/C++ string literal suitable for pasting into an ASCII source file. Therefore I produced this Perl script which seems to provide a fairly readable escaped string:

use strict;
chomp;
print '"';
my $prev_esc = 0;
print map
    {
        if (ord $_ > 0x7f) {
            $prev_esc = 1;
            sprintf('\\x%lx', ord $_);
        } else {
            my $need_break = $prev_esc && /[0-9A-Fa-f]/;
            $prev_esc = 0;
            ($need_break ? '" "' : '') . $_;
        }
    }
    split('', $_);
print '"' . "\n";

Run it with the Perl -n option, and it will output an escaped string literal for each line input:

$perl -n utf8esc.pl
Grüße aus Bärenhöfe
"Gr\xc3\xbc\xc3\x9f" "e aus B\xc3\xa4renh\xc3\xb6" "fe"

Hit Ctrl-D on a blank line to exit.

Unfortunately, C/C++ seems to have the strange rule that all hex characters following a “\x” apply to that escape sequence, even though the maximum value allowed is 0xff. Therefore it is necessary to break the string into separate segments.

Building Boost for 64-bit Windows turns out not to be completely straightforward. These instructions assume you’re using Visual Studio 2008 and running from a VS 2008 x64 Command Prompt.

First, running bootstrap.bat appears to fail:

Building Boost.Jam build engine

Also, you can file an issue at http://svn.boost.org
Please attach bjam.log in that case.

Actually, it’s not failing to build, it’s just trying to copy the executable from the wrong path. All you need to do is copy tools\jam\src\bin.ntx86_64\bjam.exe to the top-level Boost directory.

Next, you need to install any of the optional libraries you want to support. For Python support, you can install the Windows AMD64 MSI Installer, and then add the install directory (C:\Python26 by default) to your PATH. For Graphviz parsing support, download and unzip Expat 2.0.1 and my VS 2008 x64 project files, then use Batch Build in VS 2008 to build the x64 targets. You’ll also need to rename the Expat library reference in Boost’s libs\graph\build\Jamfile.v2 from “expat” to “libexpat”.

Finally, run the following commands to build Debug and Release DLLs, setting the Expat paths appropriately and the -j option to the number of processor cores you have:

set EXPAT_INCLUDE=C:\expat-2.0.1\lib

set EXPAT_LIBPATH=C:\expat-2.0.1\win64\bin\Release
bjam -j3 --stagedir=stage64 --without-mpi toolset=msvc address-model=64 variant=release link=shared threading=multi runtime-link=shared stage > build-shared-multi-release64.log

With any luck, in about 5-15 minutes, you’ll have a set of DLLs and import libraries in stage64/lib. The build generates lots of output and warnings, which is the reason for redirecting the output to a file, but you’ll want to check the beginning and end of each log to make sure it built everything you expected.

I couldn’t find any instructions for building Expat for 64-bit Windows (x64), so I updated the 32-bit projects files myself: expat-vs2008-x64.zip. See my projects page for brief usage instructions.

Update: With the March 2012 release of Expat 2.1.0, Expat now supports building with CMake, and these build files are no longer necessary. After installing CMake and downloading and extracting the Expat tarball, just do the following to build solution and project files for Visual Studio 11 (aka 2012) Win64 from the Developer Command Prompt for VS2012:

C:\dev\expat-2.1.0>md build

Time Elapsed 00:00:03.38

expat.dll will be in the Release directory. CMake supports generating project files for versions as old as Visual Studio 6, so this approach completely replaces the need for building project files by hand.