llvm dev - Mar 2011 - [LLVMdev] [cfe-dev] Announcing: LLVM 2.9 RC2 Testing Phase

On Mar 25, 2011, at 8:44 AM, Michel Alexandre Salim wrote:
> And in Fedora's Rawhide development tree (not in our upcoming F-15
> release, since third-party packages won't be ready in time for our May
> release):
> 
> http://koji.fedoraproject.org/koji/buildinfo?buildID=235848
> 
> The RPMs should install fine on F-15, and you can always rebuild with
> rpmbuild.
> 
> By the way, any reason LLVM ships with a bundled Google Test (gtest)
> utility?
> 
So that people can run the unittests. :)

	make unittests


-bw

On 03/25/2011 09:13 PM, Bill Wendling wrote:
> On Mar 25, 2011, at 8:44 AM, Michel Alexandre Salim wrote:
>
>> And in Fedora's Rawhide development tree (not in our upcoming F-15
>> release, since third-party packages won't be ready in time for our
May
>> release):
>>
>> http://koji.fedoraproject.org/koji/buildinfo?buildID=235848
>>
>> The RPMs should install fine on F-15, and you can always rebuild with
>> rpmbuild.
>>
>> By the way, any reason LLVM ships with a bundled Google Test (gtest)
>> utility?
>>
> So that people can run the unittests. :)
>
> 	make unittests
>
That's the obvious answer :) And that reminds me, I need to enable it in 
our builds.

I guess I ought to clarify -- any reason one can't use the gtest tool as 
shipped by Google, rather than the embedded one? Either way would 
comply, I think, with our packaging guidelines -- but if it had been a 
bundled third-party library then it would have been problematic.

Thanks,

-- 
Michel

On Mar 25, 2011, at 1:17 PM, Michel Alexandre Salim wrote:
> On 03/25/2011 09:13 PM, Bill Wendling wrote:
>> On Mar 25, 2011, at 8:44 AM, Michel Alexandre Salim wrote:
>> 
>>> And in Fedora's Rawhide development tree (not in our upcoming
F-15
>>> release, since third-party packages won't be ready in time for
our May
>>> release):
>>> 
>>> http://koji.fedoraproject.org/koji/buildinfo?buildID=235848
>>> 
>>> The RPMs should install fine on F-15, and you can always rebuild
with
>>> rpmbuild.
>>> 
>>> By the way, any reason LLVM ships with a bundled Google Test
(gtest)
>>> utility?
>>> 
>> So that people can run the unittests. :)
>> 
>> 	make unittests
>> 
> That's the obvious answer :) And that reminds me, I need to enable it
in
> our builds.
> 
> I guess I ought to clarify -- any reason one can't use the gtest tool
as
> shipped by Google, rather than the embedded one? Either way would 
> comply, I think, with our packaging guidelines -- but if it had been a 
> bundled third-party library then it would have been problematic.
Hasn't been tested as far as I know, but otherwise if it works for you...

-eric

On Fri, Mar 25, 2011 at 1:17 PM, Michel Alexandre Salim <
salimma at fedoraproject.org> wrote:
> I guess I ought to clarify -- any reason one can't use the gtest tool
as
> shipped by Google, rather than the embedded one?
>
A few reasons come to mind:

1) We've had to patch GoogleTest several times to make it work with LLVM
&
Clang.
2) It's more stable to used a locked version checked in and released with
LLVM & Clang.
3) The GoogleTest developers and maintainers (I'm one of them) recommend and
encourage this. We've considered removing support for installing it at all,
and may still do so. It just doesn't make a lot of sense outside the context
of a particular source tree and build system, often requires custom
modifications to the build system to use, and avoids pain when GoogleTest
APIs change between versions.

Still, as Eric said, if it works for you...
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20110325/de94116f/attachment.html>