[LLVMdev] unit-tests for standalone clang

[NAKAMURA Takumi]

Resend ... damn llvm-dev :(

2014-01-29 NAKAMURA Takumi <geek4civic at gmail.com>:
> I suppose I introduced (2). In clang/CMakeLists.txt,
>
>       set(UNITTEST_DIR ${LLVM_MAIN_SRC_DIR}/utils/unittest)
>       if(EXISTS ${UNITTEST_DIR}/googletest/include/gtest/gtest.h
>           AND NOT EXISTS
> ${LLVM_LIBRARY_DIR}/${CMAKE_STATIC_LIBRARY_PREFIX}gtest${CMAKE_STATIC_LIBRARY_SUFFIX}
>           AND EXISTS ${UNITTEST_DIR}/CMakeLists.txt)
>         add_subdirectory(${UNITTEST_DIR} utils/unittest)
>       endif()
>
> It'd be my fault if it didn't work.
>
> I don't know your prerequisites. Let me know your configurations.
> I guess the build tree were confused about gtest among llvm binary
> tree, llvm source tree and distro's gtest.
>
> I think it'd be good thing if our unittests would work with public gtest.
>
> ...Takumi
>
>
>
> 2014-01-29 Saleem Abdulrasool <compnerd at compnerd.org>:
>> When building a standalone clang (which I believe most of us don't do, I
>> certainly do not do this when developing), I noticed a build failure and
>> fixed the particular issue in the build (SVN r200096).
>>
>> I agree with David here that if we are supporting a standalone build, we
>> should ensure that it works correctly and builds identically (as much as
>> possible) to the non-standalone version so that we do not end up
>> accidentally introducing subtle bugs into the build.
>>
>> Digging further into the issue (thanks dblakie!) it seems that the problem
>> is exhibited due to a small change to the bundled copy of google-test in the
>> LLVM repository.  That change was made in 2009 by Jeffery (SVN r81093) to
>> assist in printing out types more conveniently by adapting std::ostream to
>> LLVM's raw_ostream.
>>
>> We have a few options here:
>>
>> 1) have gtest be part of the installed LLVM image
>> 2) duplicate gtest into clang
>> 3a) remove the change to google-test and adapt the unit-tests appropriately
>> (which is what I did in the previously mentioned change for the cases that I
>> found).
>> 3b) move the required machinery for supporting google-test into libSupport.
>>
>> I wanted to bring this up on this list in order to facilitate a discussion
>> to determine the best course of action.
>>
>> My personal preference would be for 3a.  We should adapt the tests to
>> perform the necessary conversions to print out information as necessary.
>> This would also help reduce divergence from googletest which is a bonus IMO.
>>
>> --
>> Saleem Abdulrasool
>> compnerd (at) compnerd (dot) org