[cfe-dev] [RFC] Add include-what-you-use tool to clang-tools-extra

[Volodymyr Sapsai via cfe-dev]

On Fri, Sep 8, 2017 at 11:40 AM, Manuel Klimek <klimek at google.com> wrote:

> On Fri, Sep 8, 2017 at 8:36 PM Volodymyr Sapsai <vsapsai at gmail.com> wrote:
>
>> Currently include-what-you-use is considered to be competing with Clang
>> tools, existing and potential.
>
>
> By whom? Why?
>

I don't have official legal evaluation of the situation but employers tend
to disapprove employees working on competing products. From my limited
experience restrictions can be pretty broad, prohibiting to work on
products or services in the same area or competing with your employer's
current or reasonably anticipated products or services. I believe it is
reasonable to anticipate a tool like include-what-you-use among other Clang
tools. So for anybody working on Clang as a part of their job, contributing
to IWYU might be problematic.

What is the experience of others? Is it better to leave resolving such
matters to individual contributors or to make a project easier to
contribute to?

Thanks,
Volodymyr


> It would be great to resolve this competition issue. One of the ways to
>> achieve it is to make IWYU one of Clang tools. I'll be glad to learn about
>> other options. So far I don't know any.
>>
>> Thanks,
>> Volodymyr
>> On Fri, Sep 8, 2017 at 06:27 Manuel Klimek via cfe-dev <
>> cfe-dev at lists.llvm.org> wrote:
>>
>>> On Fri, Sep 8, 2017 at 11:15 AM Kim Gräsman <kim.grasman at gmail.com>
>>> wrote:
>>>
>>>> On Thu, Sep 7, 2017 at 6:03 PM, Robinson, Paul via cfe-dev
>>>> <cfe-dev at lists.llvm.org> wrote:
>>>> > Reimplementing the tool using the tooling available in the LLVM
>>>> project
>>>> > would seem more appropriate to an LLVM-project tool. J
>>>> >
>>>> > I am not really familiar with the original IWYU tool, but one thing I
>>>> > remember from James' work is that it would be fairly easy to implement
>>>> > different policies.  For example, minimizing the number of #includes,
>>>> versus
>>>> > always directly including the header that declares everything
>>>> actually used
>>>> > in the source.  That kind of flexibility is great.
>>>>
>>>> I think exploring a new IWYU would be interesting and rewarding. It
>>>> would be nice if such an initiative could build on the IWYU test suite
>>>> in some form, I suspect that the easy cases are easy to get right, and
>>>> that some of the complexity in the current IWYU comes from the edge
>>>> cases.
>>>>
>>>> That said, some/much(?) of the IWYU complexity is probably incidental,
>>>> and it would be nice to clean that up.
>>>>
>>>> I'm not sure the most productive way to do that is to start from
>>>> scratch, though.
>>>
>>>
>>> I fully agree. My main point is: I don't think putting it into
>>> clang-tools-extra in its current form is the right approach. I don't know
>>> any better way to incrementally get it into the form it would need to get
>>> into clang-tools-extra other than through incremental patches to
>>> clang-tools-extra, given that many folks just read the mailing list for
>>> patches, and if we try to go around the usual approach (for example by
>>> doing reviews in the current location) important feedback / objections
>>> might drop in only when the full thing goes in in the end.
>>>
>>> That said, I perhaps also don't find it super important for iwyu to be
>>> in clang-tools-extra - it'd most certainly be nice, and make me happy on a
>>> principled basis, but given the current state of the world, I'd rather wait
>>> a bit how things play out than try to force it.
>>>
>>> Perhaps I'm missing something?
>>>
>>> Cheers,
>>> /Manuel
>>>
>>> _______________________________________________
>>> 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/20170912/ad90445d/attachment.html>