[Development] Qt 6 buildsystem support requirements

[Jean-Michaël Celerier]

Sounds like you have a configuration problem in Qt Creator. I've been using
qtc with the clang code model and CMake projects for over a year on various
C++11/14/17 projects and everything works fine.

$ echo '#include <string_view>\nint main() { std::string_view s("foo"); }'
> main.cpp ; echo 'project(foo CXX)\nset(CMAKE_CXX_STANDARD
17)\nadd_executable(foo main.cpp)' > CMakeLists.txt

results for me in correct completion of std::string_view in qtc.



-------
Jean-Michaël Celerier
http://www.jcelerier.name

On Sun, Jul 22, 2018 at 12:57 PM, Иван Комиссаров <abbapoh at gmail.com> wrote:

>
> 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
> 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
>
>
>
> _______________________________________________
> 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/e2d80442/attachment.html>