@naveen13 said in Can't we build Qt with /Zc:wchar_t- flag anymore?:

Is there any workaround without altering the Qt source file

No. You might provide a patch and see if it gets accepted though.

Attempt # 10 for building on windows [SUCCESS!!]

Started from scratch by re-downloading the source and used the subst command to make a new path to build with.

Created a virtual drive to avoid the PATH length limit: subst a: .\qt-everywhere-src-6.6.2\ created the build folder and ran the configure.bat like the following: PS a:\build> ..\configure.bat

Ran the command cmake --build . --parallel

Ran the install command afterwards

PS a:\build> cmake --build . --parallel

No issues and everything was installed.

Just comment the line, it worked for me (cstddef file).

@Norzka said in Problems with building qt from source (it doesn't generate lib files):

D:\Libraries\Qt\6.6.0\Build\plugins\styles\qwindowsvistastyle.lib

Hang on, why do you expect a .lib file for a plugin, that is supposed not to be linked to (it is loaded at runtime)? There should be a .dll, but not a .lib file.

Do you (try to) explicitly link against the plugin nevertheless, in your project file? Or do you somehow try a static build (which would require Qt to be built statically, too)?

@JoeCFD Where is it located in the relative /QT folder? /... like 5.12.5 , dist, Docs, Examples

@harveyab said in Show build kit at runtime:

use it for conditional compilation

If you want to use it for this you will need to know at compile-time, not at runtime.

Assuming (I don't know but would guess) that you cannot access the particular kit selected in Creator I would expect to have to test for compile-time defines which come from the kit chosen, e.g. compiler version like _MSC_VER.

so with help of someone from BugReport portal, the solution was extremly simple...
as you can see form the log:
eea6d5ef-d2db-4406-8d50-50e2ca9c185a-image.png
C and C++ compler is pucked up from PERL, not form MinGW,
so I have onlymoved MinGW environment variables PATH above the PERL and then all worked fine...

they also suggested to try specify:

-DCMAKE_CXX_COMPILER=C:/path/to/mingw/compiler/g++.exe -DCMAKE_C_COMPILER=C:/path/to/mingw/compiler/gcc.exe

but im not sure where to put this realy.

other option (im only thinking, was not suggested) is to use MingwDir parameter in configure

but not sure if the Qt is this smart enough to use this parameter as a compiler path for C and C++, this has to be tested realy

i resolved this. Perhaps someone will be useful. I had cmake 3.24-rc4 and they broke something with it. Here is the link: https://gitlab.kitware.com/cmake/cmake/-/issues/23759

Rolled back cmake to 3.23.3, everything works fine

@SGaist thk for trying to help

This has been fixed in a development release of Creator 8.0.0 beta 2, and can be found here. Marking as solved. Thanks for the help.

In Qt 6.4 (on macos) Debug build does not generate javascript file...

@Christian-Ehrlicher
Got it working by myself now, but thanks anyhow for the quick reply.

The problem was that i called cmake from within the source not the build dir so it ran cmake for a fresh new build that wasn't already setup from within Qtcreator and did not know where to search for Qt stuff.

This is my script now:

cd C:\Build\myQtApp\build_r cmake -S Y:/ -B C:/Build/myQtApp/build_r "-DBUILD_TYPE_1:BOOL=ON" "-DBUILD_TYPE_2:BOOL=ON" cmake --build C:/Build/myQtApp/build_r --target all -j2 ... cmake -S Y:/ -B C:/Build/myQtApp/build_r "-DBUILD_TYPE_1:BOOL=OFF" "-DBUILD_TYPE_2:BOOL=ON" cmake --build C:/Build/myQtApp/build_r --target all -j2

The boolean parameters BUILD_TYPE_1 and so on are used inside cmake to add a preprocessor defines that are then used to switch between different build configurations just in case anybody wants to know.

In cmake:

if(BUILD_TYPE_1) message(STATUS "Build Type: Type 1") add_definitions(-DBUILD_TYPE_1) endif()

in c++

#ifdef BUILD_TYPE_1 ... #endif

Hi,

AFAIK, it has nothing to do with macOS.

Usually the -- means that what follows will by passed as is to a process started by the script / command / other that you are invoking.

@Dmitriano ANDROID_PLATFORM is correct with NDK 21.3.6528147 and NDK 22.1.7171670 but with NDK 23.1.7779620 it is not.

@jsulm
Thank you very much! This is exactly the problem, I set up mingw in the environment variable, which caused me to compile MSVC Qt using MINGW

@jsulm Ok, i will check it

thanks for trying to shed some light on this.

As I said, I have already installed the vulkan SDK (the "official" one from LunarG as I am trying to build for windows). I have even added the include directory directly in the *.pro file, and have observed that when opening the qt3d project with QtCreator, it can correctly resolve the vulkan libraries, so I think this is not the problem. I will try your suggestion of putting the vulkan headers directly in the qt directory and see if that gets me anywhere..

@Kyeiv said in Could not resolve all artifacts for configuration ':classpath':

OpenJDK 9.0.4

You need to use Java 8, see here.

Versions higher than 8 might cause issues for the Android SDK command-line tools.