[Development] Qt 6 buildsystem support requirements

[Иван Комиссаров]

> 21 июля 2018 г., в 23:04, Thiago Macieira <thiago.macieira at intel.com> написал(а):
> 
> On Saturday, 21 July 2018 10:39:49 PDT Иван Комиссаров wrote:
>> 1. IDE integration. I really need the IDE know the correct CXX flags for
>> each separate file in my project - that is includes, c++ version and so on.
>> Currently i’m using a generated CMake file at my work and the integration
>> with Qt Creator is awful, i’m using IDE just as a simple text editor -
>> syntax highlighting breaks because IDE can’t find some headers (however,
>> goto definition works for them).
> 
> That's already more than what we have for qmake, so I wouldn't put this as a 
> requirement. It's a nice-to-have.

But only qmake works fine with new clang model, other build systems pass incorrect parameters to clang so it can’t compile my files (code model complains about missing std:: classes/functions, however the code compiles so project file is correct)

> 
> The point is that the tool has to be at least in feature parity with qmake and 
> that includes cross-compilation and IDE support.
> 
>> Yes, CMake has much more users than QBS, however, how many of them will
>> volunteer to work with CMake’s Qt Creator integration? 5 people? 10?
> 
> 5 people would be more than what we currently have for either qmake or qbs 
> today, so seems ok.

That’s true, but despite huge CMake community, Qt Creator’s CMake integration still is not in feature-parity with qmake.
I had a discussion with one of QBS developer about iOS integration in Qt Creator and he told that Qt Creator uses some qmake hacks that are not viable for QBS (yet). Hacking CMake may be much trickier as codebase is not controlled by Qt community.

> 
>> So the question is - is it easier to port QBS to be built without Qt or to
>> use CMake with Qt?
> 
> Again, solving the build is easy. Please look into the requirements at (2). 
> THAT is a lot harder. And all I'm asking is for experience. I don't want Qt to 
> be the guinea pig.

I used QBS and CMake for building debian packages in 2015 at one of my previous works. All you need for QBS is to use usual makefile based debian/rules files and replace «make install» with «qbs install».
Here’s the actual code i used to build my tool (except i replace real package/tool names with «projectname») https://pastebin.com/RbPL8GAq <https://pastebin.com/RbPL8GAq>
That’s it. You pointing too much attention to the Linux distros and maintainers, which is very important, but you are using wrong arguments. Give those maintainers a good tool and they will be happy. And the «good tool» is not the same as «tool has been used for at least 2 years». People has been using plain makefiles for decades, people has been using autotools for years. But i guess anyone agrees that autotools sucks.
The same is for CMake - people are using it because they don’t have any alternative. QBS can become that alternative. In case if it will not be buried alive.
Common, how you can compare the tools if you didn’t even used QBS? I’ve been using qmake since 2011 i’ve been using CMake since 2013, i worked both with CMake/QBS to create debian packages, i had to work with GYP in 2016, now i’m using QBS for all of my projects. So i can compare tools not by providing abstract requirements, but from the experience of using all those tools.
 
> 
> More to the point: I will not be part of the experimentation. Give me a mature 
> tool.

The autotools are mature:)

PS: BTW, in first letter i forgot to mention that the company i’m working right now ended up with writing it’s own build tool just because CMake didn’t fit all requirements we need from a build tool. We’ve been using CMake, then we wrap all the CMake mess in a set of small macroses (PROGRAM(name), LIBRARY and so on) and then replaced cmake with the tool that understands only those macroses. I don’t know exact reasons why CMake was dropped (when i came to the company, the only thing left from CMake was the project file names - CMakeLists.txt), however it’s true that CMake has a lot of tricky parts when you start using it.

The same is true for Google - why do you think they are experimenting with GYP and GN? CMake just doesn’t fits them very well (neither it will fit Qt or anyone else), but i guess they have no alternative (yet).

> -- 
> Thiago Macieira - thiago.macieira (AT) intel.com
>  Software Architect - Intel Open Source Technology Center
> 
> 
> 
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20180722/e9850296/attachment.html>