Fix git lldb build

[Keno]

LLVM_LLDB_TAR should only be set if we're not pulling from git. Also add a couple of comments to show which if the endif corresponds to since I found that confusing in fixing this. cc @maleadt to make sure this doesn't break his use case. Fixes an issue brought up in JuliaInterop/Cxx.jl#4

[tkelman]

I've found all those ifeqs really tricky to keep track of too, the comments do help. LGTM, the AppVeyor failure is due to status.julialang.org being down (cc @staticfloat)

[maleadt]

Thanks for the CC. Although a fresh SVN checkout of LLVM/LLDB still doesn't build flawlessly for me (because of pthread not being linked in, as @Keno reported upstream), this PR hasn't caused any other regressions for me.

[timholy]

You probably did this too, but JuliaInterop/Cxx.jl#27 (comment) helped for me.

[tkelman]

Crap. This actually broke from-scratch windows builds, because one of the ifeqs moved around. This:

ifeq ($(USECLANG),1)
LLVM_FLAGS += --enable-cxx11
else
LLVM_CXXFLAGS += -std=c++0x
endif
ifeq ($(LLDB_DISABLE_PYTHON),1)
LLVM_CXXFLAGS += -DLLDB_DISABLE_PYTHON
endif

was formerly under an ifeq ($(BUILD_LLDB),1), now it isn't.

[Keno]

That's correct, those are not lldb specific. They might be llvm 3.5 specific however. What's the error message?

[tkelman]

See http://buildbot.e.ip.saba.us:8010/builders/package_win8.1-x64/builds/52/steps/shell_2/logs/stdio for the whole log, the error was:

/home/vagrant/buildbot/slave/package_win8_1-x64/build/deps/llvm-3.3/lib/Support/raw_ostream.cpp: In member function ‘llvm::raw_ostream& llvm::raw_ostream::operator<<(double)’:
/home/vagrant/buildbot/slave/package_win8_1-x64/build/deps/llvm-3.3/lib/Support/raw_ostream.cpp:229:24: error: ‘_fpclass’ was not declared in this scope
   int fpcl = _fpclass(N);
                        ^
/home/vagrant/buildbot/slave/package_win8_1-x64/build/deps/llvm-3.3/lib/Support/raw_ostream.cpp:232:15: error: ‘_FPCLASS_NZ’ was not declared in this scope
   if (fpcl == _FPCLASS_NZ)
               ^

It's something to do with these flags, because when LLVM's configure runs we get this:

cd llvm-3.3 && \
mkdir -p build_Release && cd build_Release && \
export PATH=/home/vagrant/buildbot/slave/package_win8_1-x64/build/deps/llvm-3.3/python2_path:$PATH && \
../configure --prefix=/home/vagrant/buildbot/slave/package_win8_1-x64/build/usr --build=x86_64-pc-cygwin --libdir=/home/vagrant/buildbot/slave/package_win8_1-x64/build/usr/lib --host=x86_64-w64-mingw32 LDFLAGS=-Wl,--stack,8388608 F77="x86_64-w64-mingw32-gfortran -march=x86-64 -m64" CC="x86_64-w64-mingw32-gcc -march=x86-64 -m64" CXX="x86_64-w64-mingw32-g++ -march=x86-64 -m64"  --disable-profiling --enable-shared --enable-static --enable-targets=host --disable-bindings --disable-docs --disable-assertions --enable-optimized --with-extra-ld-options="-Wl,--stack,8388608" LDFLAGS="" --disable-shared --disable-threads CXXFLAGS=" -std=c++0x" CPPFLAGS=" -D__USING_SJLJ_EXCEPTIONS__ -D__CRT__NO_INLINE" --with-python="/usr/bin/python"
../configure: line 1991: -std=c++0x: command not found