Re: A branch for FreeBSD 10's clang

> Thanks for making mtn work on FreeBSD.

My favorite OS must work nicely with my favorite DVCS. ;)

> The --variable thing itself works on Ubuntu 12.04 as well as on Debian
> jessie (testing). However, the sed command you added strips several
> required paths, here.

Oh, it's even easier than I thought, the `sed` can simply be avoided.

> The '2>&1' also strikes me as odd. Why would we want to add errors to
> the path? Shouldn't 'configure' better print this on stderr?

A remnant of the old "take debug output and mangle it" approach, I
removed it as well.

> I gave it a try and added a separate macro to detect the FreeBSD 10
> case, where we do not have the tr1 headers, anymore. Lapo, can you
> please test that?

Sure, where can I find it?

> Also, I'd be interested in a test run with CXX="clang++ -std=c++11". If
> that also fails on FreeBSD, that means they are *not* shipping TR1, but
> C++11 headers, but (by default) don't compile with C++11 enabled. Seems
> like a weird combination to me.

I know nothing about C++11 really (neither in FreeBSD nor in general),
but I can surely try that.

Compiles OK quite a lot fo files, then stops on:

src/cmd_ws_commit.cc:1183:19: error: no viable overloaded '='
        i->second = make_pair(false, "");
        ~~~~~~~~~ ^ ~~~~~~~~~~~~~~~~~~~~
/usr/include/c++/v1/utility:273:11: note: candidate function not viable:
no known conversion from 'pair<[...], typename __make_pair_return<char const
      (&)[1]>::type>' to 'const pair<[...], class attr_value>' for 1st
argument
    pair& operator=(const pair& __p)
          ^
/usr/include/c++/v1/utility:311:5: note: candidate function not viable:
no known conversion from 'pair<[...], typename __make_pair_return<char const
      (&)[1]>::type>' to 'pair<[...], class attr_value>' for 1st argument
    operator=(pair&& __p)
_NOEXCEPT_(is_nothrow_move_assignable<first_type>::value &&
    ^
/usr/include/c++/v1/utility:346:9: note: candidate template ignored:
couldn't infer template argument ''
        operator=(_Tuple&& __p)
        ^
src/cmd_ws_commit.cc:1192:26: error: no viable overloaded '='
      node->attrs[a_key] = make_pair(false, "");
      ~~~~~~~~~~~~~~~~~~ ^ ~~~~~~~~~~~~~~~~~~~~
/usr/include/c++/v1/utility:273:11: note: candidate function not viable:
no known conversion from 'pair<[...], typename __make_pair_return<char const
      (&)[1]>::type>' to 'const pair<[...], class attr_value>' for 1st
argument
    pair& operator=(const pair& __p)
          ^
/usr/include/c++/v1/utility:311:5: note: candidate function not viable:
no known conversion from 'pair<[...], typename __make_pair_return<char const
      (&)[1]>::type>' to 'pair<[...], class attr_value>' for 1st argument
    operator=(pair&& __p)
_NOEXCEPT_(is_nothrow_move_assignable<first_type>::value &&
    ^
/usr/include/c++/v1/utility:346:9: note: candidate template ignored:
couldn't infer template argument ''
        operator=(_Tuple&& __p)
        ^

>> I moved <iostream> from .cc to .hh, or std::streamsize was unrecognized
>> there.
> 
> IIRC iostream is quite a heavy include, so that's probably why it got
> moved to the .cc file. But if that fixes FreeBSD 10 for you, that's fine
> with me.

If there's any smaller header that still defines std::streamsize, that
should work too.  Mhh, ok, <ios> should suffice.

Current status of the tree, for reference:

mtn diff -r 8c090a8270d76f965aa87ecaae6b9c4b6edb7aca \
         -r h:net.venge.monotone.freebsd-10

-- 
Lapo Luchini - http://lapo.it/