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

Lisandro Damián Nicanor Pérez Meyer perezmeyer at gmail.com
Tue Sep 10 20:04:43 CEST 2019


On 19/09/10 11:59, Eike Ziller wrote:
> 
> 
> > 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.

[snip]

> > - 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.

Actually I do see some value in letting the plugin be compiled as a dummy one.
If the error message is clear enough it would help both users and distro
maintainers in knowing that a certain feature which should be available
according to the release notes/blog it is not, and why. In that way users that
really need the feature can consider using precompiled binaries directly from
you. Users that prefer to stick with distro-packeges will just accept it and
move forward. Or even maybe help the patches become upstreamed :-) (it has
happened before).
 
> > 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.

Right, and seeing that you agree with the above I think this can be made
something of a rule (is quip used for this?). Something like:

  If some part needs a special feature/code/patch create explicit messages to be
  shown both at build and run time. Ideally add the long explanation in the
  README file.

If this is added right from the start the worst case scenario is that it might
become no longer true and it deserves a patch.

I'm working on this in the current proposed patch, build-testing right now.



More information about the Development mailing list