[cfe-dev] BUILD_SHARED_LIBS=True breaks some tests

[Kim Gräsman via cfe-dev]

Can you dig out more details around why it fails? We have a recurring
request to add a dependency on clangSerialization from IWYU because it's
missing under BUILD_SHARED_LIBS. I wonder if this might be an in-tree repro
of that problem.

Thanks,
- Kim

On Wed, Jan 9, 2019, 00:04 Chris Bieneman via cfe-dev <
cfe-dev at lists.llvm.org wrote:

>
>
> On Jan 8, 2019, at 2:44 PM, Joel E. Denny via cfe-dev <
> cfe-dev at lists.llvm.org> wrote:
>
> On Tue, Jan 8, 2019 at 5:14 PM David Greene <dag at cray.com> wrote:
>
>> "Joel E. Denny via cfe-dev" <cfe-dev at lists.llvm.org> writes:
>>
>> > Do other Clang developers find BUILD_SHARED_LIBS=True useful? Do you
>> > see the above failures? Should there be a bot to test that build
>> > configuration?
>>
>> I don't use BUILD_SHARED_LIBS=True
>
>
> One point I'd like to understand is why more people don't use it.  Were
> you not aware of it, or is it just not beneficial enough to you?  I was
> very happy to reduce a nearly 4-minute rebuild after a minor change to ~31
> sec.  Especially when I have to do that repeatedly, that time difference
> can determine whether I decide to switch contexts or stay focused.
>
>
> How much of that rebuild time is actually link time? I'd guess most. What
> linker are you using? ld64, lld and gold are all much faster than bfd, so
> the performance implications may be smaller to other people. Also, using
> `BUILD_SHARED_LIBS` has a significant impact on execution performance of
> the final binaries, which impacts test execution speed. So if you aren't
> struggling with link time, it can be overall better to generate faster
> loading binaries for the test suite.
>
> There are a lot of tradeoffs on performance, but I've strongly advocated
> that BUILD_SHARED_LIBS should never be used when building distributions for
> performance reasons, which means it is only really supported as a developer
> workflow.
>
> Additionally BUILD_SHARED_LIBS is problematic with some of LLVM's design
> patterns, like cl::opt's global registration, which can deter its
> usefulness.
>
> Hope this helps explain why it is less widely used than you might have
> anticipated.
>
> -Chris
>
>
>
>> but if that's a supported option, it
>> should be tested.
>>
>> This argument will, of course, lead to an explosion of builders, as the
>> set of combinations of cmake variables is very large.  It would be
>> useful to gather the various configurations people use and see if there
>> is a set of common-ish combinations that is small enough to regularly
>> test.
>>
>> We build with RTTI and exceptions enabled and I'll bet there are others
>> out there that do the same.  But AFAIK there are no bots testing those
>> options.
>>
>
> To reduce the configuration space, we could consider combining orthogonal
> options under a single builder.  That could make debugging some fails a
> little harder, but it might be worthwhile as it would provide more coverage
> with less builders.
>
> Thanks.
>
> Joel
>
>
>>
>>                              -David
>>
>> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20190109/e80dd209/attachment.html>