> On 10. Sep 2019, at 13:18, Lisandro Damián Nicanor Pérez Meyer > <perezme...@gmail.com> wrote: > > Hi! Let me put some other perspective into this. > > On Tue, 10 Sep 2019 at 07:35, Eike Ziller <eike.zil...@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.zil...@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 _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
