[Development] Qt Creatror can require a patched Clang build?

[Eike Ziller]

> On 10. Sep 2019, at 13:18, Lisandro Damián Nicanor Pérez Meyer <perezmeyer at gmail.com> wrote:
> 
> Hi! Let me put some other perspective into this.
> 
> On Tue, 10 Sep 2019 at 07:35, Eike Ziller <Eike.Ziller at qt.io> wrote:
>> 
>> To put some perspective on this:
>> 
>> The ClangFormat plugin which this is about is an optional plugin, disabled by default,
> 
> But still being built even if the necessary preconditions are not
> being met without the slightest warning. And even worst, the user gets
> to "enable" it only to find a message that makes them think that some
> wrong step was done by your downstreams... which is not the case. I
> insist, patched non-official clang is just not right.
> 
>> that uses the clangformat library directly for code formatting.
>> It should build against upstream LLVM,
> 
> A *patched* LLVM with a patch that has not been even accepted
> upstream. And no, we shouldn't be asking to use *upstream* LLVM but
> the system's one should be more than enough as long as the version
> requirements are met.
> 
> Even more, it can't be *properly* built with creator's source code as-is.
> 
>> but will not load in that case (with a warning) even _if_ it was enabled explicitly.
> 
> A misleading warning for something a user can happily enable.
> 
>> Afaik Ivan tried to upstream the patch and it is lying around there, someone would need to push that forward again.
>> 
>> Similar functionality of “using clangformat to format code” is also available via the Beautifier plugin, which uses an arbitrary external clangformat executable. That is less tightly integrated (doesn’t format while typing), but has the advantage that you can freely choose the clangformat version.
>> 
>> So, to sum this up, the ClangFormat plugin is currently neither an essential component of Qt Creator, nor do you loose much in terms of functionality if you don’t have it.
> 
> But at the same time you are not playing nicely neither with your
> dowstreams nor with your users trough your downstreams.
> 
> What should really happen here:
> 
> - Every message should be clear on why something is not working. In
> this specific case it is not "just" that the libFormat library is not
> the right one, it's because it needs a *patched*, non-official version
> of it.

Sure, error messages can be improved.

> - This kinds of things should happen at build time with a proper test
> disabling building the plugin while clearly explaining whoever builds
> creator which is the underlying issue.

That would be preferable, yes.

> Don't get me wrong: I see your intention. But if we all play as a team
> we get to our users with the best experience possible. Having them
> filing bugs because of supposedly working functionality is not the
> right way forward. Let's just be clear and upfront and everything will
> work better.

It certainly was not the intention that an unofficial patch would be needed longer term.

> -- 
> Lisandro Damián Nicanor Pérez Meyer
> http://perezmeyer.com.ar/
> http://perezmeyer.blogspot.com/

-- 
Eike Ziller
Principal Software Engineer

The Qt Company GmbH
Erich-Thilo-Straße 10
D-12489 Berlin
eike.ziller at qt.io
http://qt.io
Geschäftsführer: Mika Pälsi,
Juha Varelius, Mika Harjuaho
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B