On 07/27/2018 02:22 PM, Lisandro Damián Nicanor Pérez Meyer wrote: > Don't get me wrong: I also don't like build depending on LLVM [1], but it > became a hard dependency. Again, I haven't looked at the code yet (I'm over > the transition now), so I'm purely guiding myself from what one of my co > maintainers did (and he happens to be in vac). > > But what can we do if it became a hard dependency?
I'm 99% sure it's not a hard dependency. It's a documentation utility. >>> I haven't looked at the code but it seems that this dependency is now >>> required in order to build qdoc, so reducing the severity to wishlist. >> >> Well, it's a documentation tool. It should just be possible to disable >> the documentation tool on the affected architectures. > > It's the tool to generate documentation. Exactly. And documentation is built in arch:all only anyway. >>> I don't know if it's possible at all to build everything but qdoc. And the >>> effect of this could be many packages starting to FTBFS. >> >> Unlikely. I don't know any project that has a hard dependency on >> documentation. > > No no, not the documentation itself, but the tool to create it! Yes, but you can (and should(!)) build documentation in the binary-arch-indep target. > If for some reason a package build it's doc on an arch-specific build it will > FTBFS. Then this package is clearly buggy. Documentation is arch-independent and should never be built per architecture. > But on a second thought you might want to tackle those packages yourself. If > you like that idea well, we need a patch to disable qdoc compilation probably. You don't need to disable QDoc completely. Just use it in a reasonable way. >>> The only way around I see is submitting patches upstream to avoid clanf >>> usage. Remember they need to go directly to upstream, we can't forward >>> then >>> except for very small changes. >> >> Strange policy. Lots of people here take patches from the bugtracker and >> forward them upstream. In fact, that's what the official Debian >> documentation says. > > Yes, but upstream has a CLA in which you don't give copyright permissions > *but* allow the Qt Company to use the submitted code in their proprietary > version, your code remaining FLOSS for every other aspect. *sigh* CLAs suck > The way they enforce that is by making the real coders push their work to > their gerrit instance, for which you previously have to agree to the CLA. Yes. I know the deal. >> Either way, there are plans to make LLVM available on more targets, there >> are already branches working on alpha, m68k, riscv64 and more. Until then, >> it would be nice if Qt wouldn't have a hard dependency on it solely to >> build documentation. > > Again: I would *love* to. But to the best of my knowledge now, we can't. Of > course, I'll be delighted to learn I'm wrong :-) I will take care of that - like always :P. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
