@kkoehne said in Qt6, qmake: Does 'QT += openglwidgets' imply 'QT += opengl'?:

@Yuni said in Qt6, qmake: Does 'QT += openglwidgets' imply 'QT += opengl'?:

If it works and it's unspecified behavior, then it may not work on other machines or for future Qt versions.

Build and module dependencies usually don't change in a minor Qt version. For major Qt versions, things might get rearranged ... but then again there's no SC guarantee there in the first place :)

I think it's good practice to explicitly declare all the dependencies that you explicitly rely upon though. But this is arguably a matter of taste.

I would guess qopenglwidget.prf fetches qopengl.prf - you can take a look into them by your own.

For QT variable, it's actually .prifiles: mkspecs/modules/qt_lib_qopenglwidgets.pri, mkspecs/modules/qt_lib_qopengl.pri ...

I see, thank you so much! I'll declare them explicitly then.

I've found the .pri files (without the leading 'q', that is, so e.g. qt_lib_opengl.pri) and openglwidgets indeed has a dependency on opengl, explaining why the project compiles without the explicit declaration.

@SGaist i just used an older version of qt(5.12 instead of 6.1.2), and it worked

If you chose a CMake project, a CMakeLists.txt file will be used. You have to choose qmake as build system to get a .pro file.

@Christian-Ehrlicher said in Why it is generating multiple library files instead of single file?:

why does your user has to link to all 4 files, esp. when three of them are (correct) symlinks?

Sorry for silly question. I misunderstood about symbolic link. I got my answer user need to add libSquidstatLibrary.1.0.0.dylib file.

Thank you.

we would like to install different builds on the same machine and the place were would do that distinction would be on the .pro file, to then generate different values for the "version" value of "info.plist" file.

We already have a portion of code that we can probably use to do something similar:

codegen.commands = python "\"$${PATH}/Dir1/test.py\"" !isEmpty(VARNAME) { message($$VARNAME) codegen.commands += VarName=$$CONFNAME }

I think we are getting there

Hi,

What are these "minor things" ?

@SGaist Thank you, I will try it!

After so many attempts without luck, the first attempt I try after writing this reply is a dfferent error :)

So the boost is no longer my problem.

For other people that my face the same problem as me, in the includepath just add: '$(BOOST_ROOT)'

See here for qmake language reference.
Basically the $ $ operator applied to environment variables will be evaluated at qmake run, while the $ when the generated makefile is processed.

Another post recently linked back to this one, so I wanted to augment this with a couple more relevant links for setting up a manageable, maintainable qmake SUBDIRS structure:

https://www.toptal.com/qt/vital-guide-qmake

https://wiki.qt.io/QMake-top-level-srcdir-and-builddir

Which helped me set up a working example: https://github.com/219-design/qt-qml-project-template-with-ci/blob/6af6488d74e1dc97a/main_gui.pro

HI and welcome to devnet,

you can create your own "Project Wizard". Read here how to do

Thanks for your answer
It's actually a dll but I get what you are saying.
I tried adding

target.files = $$DESTDIRNAME/*.dll target.files += $$DESTDIRNAME/*.lib target.files += $$DESTDIRNAME/*.pdb

where DESTDIRNAME is the same value as DESTDIR but no change

Can you show a mockup of your project tree structure ?

You can put the name of mkspec you are used for the given platform. I think for Raspberry it's something like linux-rasp-pi-g++. Open the mkspecs/devices folder in your Qt installation and check it out or open the Kits propertties page in Qt Creator and see which mkspec your kits are using.