@Strohhut no problem, I was close to the end of my suggestions... So great it's not working ! Setting up a working android toolchain can be cumbersome 🙈 Son't forget to use the topic tools to set the topic to solved :)

Hi, I think you are looking for QMAKE_RPATHDIR.

@feistykittykat Don't know if I'm allowed to bump this bad boy up. Been struggling to use PVRVFrame or something similar to get openGL found on my machine, but I have no idea how to set it up for QT. Still not even sure if that's the source of my problem.

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

@ruisebastiao well this is a rather hacky workaround to fix something Qt has broken within a LTS version. The thing is that libmali uses a unified lib which contains all symbols for EGL, OpenGL ES etc. so it would be wrong to apply a single .so name. It worked fine in 5.12.0 so it's probably time to come up with a solution for this "use absolute paths" nonsense has introduced. it works once you duplicate the unified lib & patch it. So Qt needs to deal with this kind of libs instead of forcing users to patch stuff. https://forum.qt.io/topic/104015/cross-compilation-generates-full-paths-in-libqt5gui-so-for-libglesv2-so-and-libgl-so-then-cannot-be-found-in-execution-time/3

@raven-worx Thanks!

@kenchan - Again, thanks. I've successfully used -Wno-missing-braces on the analyzer and editor, so it 'works' for at least some versions of the compiler. As for 'warn_on'/'warn_off', I had no trouble verifying their existence/function once I found them in the .pro file, but I had no prior warning to look for such a thing. I've been looking for QMAKE_CXXFLAGS, not weird macros that are defined in some middle ground between the .conf files and the .pro files. I don't understand how the .conf files work, much less how to successfully invoke half of the options documented there and elsewhere. On the other hand, I think that I've solved my main issue with the discovery of the hidden 'warn_off' in my library's .pro file. I have compile warnings again. More than I'd like, true, and I don't seem to be able to turn off specific warnings, but fixing the autogenerated code should get rid of the majority of the offending bits, so I can at least have some confidence in my builds again.

If I rename new folder in new_old, for example, the problem disappears. I also tried, Qt5.8, already installed in my system, same problem. Maybe tomorow, I will try Qt5.12 and let you know.

Oops! It worked in my last attempt, although it look a long time. So, my problem was Emscripten's version after all. Here is the version that worked: emscripten-1.37.1 Note: I've used emsdk to install Emscripten and I had to install a matching LLVM/CLang version: clang-e1.37.1-64bit

@smhrambo deleting the *.pro.user file often helps when you do such moves...

@jsmolka said in Trouble compiling files with identical filenames: Is there any way to fix that and use multiple files with the same name inside my Qt project? Does it perhaps have something to do with the fact, that I am compiling into a bin dir inside my repository? Not with shadow building, no. When you generate a bunch of object files in the same directory, the object is named after the source file. So the identically named source's object file will overwrite the previous one (in order of building); it may even happen only partially if you're building on multiple cores. It's a known pitfall and you should name your files better as people have already suggested.

Hi and welcome to devnet, Because it's complex to integrate one build system with another. What 3rd party is it ?

@koahnig Which seems to be the default then.

@Kinesis There are only two options: Install a compatible Qt version on the second computer Deploy all needed libraries along with your program. You may want to have a look at linuxdeployqt Regards

@SGaist, could You provide an example please - fixed mylibrary.pro? Thanks!

@koahnig: thanks for sharing. The clean is definitely faster with jom, but apparently it looses later on time when starting for the different projects. All checks are with compilation on ram disk with 8 cores Interesting. As said, I'll do some more tests the next says and see how it behaves. For now jom is my winner. jom was not happy my environment settings MAKEFLAGS=-j8 ... but it does not need it on the other hand ;)

Remove the -j 8. The error is somewhere else. These are just warnings.

@kshegunov said in qmake install error detection on Windows: target.depends = baseLibs This was a very promising idea but unfortunately it looks like .depends does not work with other INSTALLS tagets

I found a solution with QMAKESPEC message("SPEC " $$QMAKESPEC) message("SPEC " $$basename(QMAKESPEC)) The output is for instance: Project MESSAGE: QMAKESPEC C:/Qt/5.4/mingw491_32/mkspecs/win32-g++ Project MESSAGE: SPEC win32-g++ or on linux Project MESSAGE: QMAKESPEC /home/bloblo/Qt/5.9.1/gcc_64/mkspecs/linux-g++ Project MESSAGE: SPEC linux-g++

@kshegunov I've tried that too ... but I see what I'm doing wrong. I guess you have to manually run qmake every time you delete the folder to test it or else it won't update the condition. I just kept rebuilding it, which didn't work. Thanks. Guess one of my previous conditions would have worked for this as well.

@SGaist yes, you were right! Qmake is saving absolute path internally, I think. So I moved all necessary files to required directory and everything is working, thank you! I'll post a screenshot with minimum necessary files and directories that needed to successful qmake's work without Qt. It requires an empty include directory! If you delete it QtCreator will not show your non-Qt Kit in the startup list of Kits for a new project!

Tested with Qt 5.9.2 and it's working as expected. Well, the script bash is called.

While I'm still not successful to expand $${LITERAL_DOLLAR}0 to the command line at compile, I did resolve the generated compile error by changing from awk to sed. [Work around] Change... myrcupdate.commands = awk \'NR==2 {$${LITERAL_DOLLAR}0=\"$${MY_DIR}\"} 1\' myrc.sample > .myrc to... myrcupdate.commands = sed -i \'\' \'2s%.*%$${MY_DIR}%\' .myrc

No problem. Good luck with your project!

@Mahesh-Kumar-Kodanda said in QT 5.9 for i.MX6Q and Integrity RTOS build error - unrecognised command line option »-std=c++11«: cross compile tool chain For which device? You already use one- why do you ask me to provide one? A cross compile tool chain is not specific to Qt or any other framework/library but to a device.

@koahnig If you promise not to tell anymore, i just discovered that it can actually autocomplete in .pro file :) Very handy. ;)

Just use QT += module That test is really only useful for code bases that should be built with both Qt 4 and Qt 5 since the widgets have moved to their own module in Qt 5.

@Wieland Thanks for the reference - that has worked for me. Also, thanks for the Qbs information - i hadn't seen this before but will look into it @SGaist - thanks for the info I had previously tried something similar but I think it may have been the escaping of quotes which caught me out.

I already wrote it: use out of source builds.

@Pamplemousse-MK-2 When you are entering this on each machine where the creator is used, it will apply to all projects on that machine. Eventually you need to check whether it is updated for all projects already loaded in created. New projects are taking over those system environment settings.

Hi, I may be wrong but AFAIK, Apple changed recently its policy about dynamic library in application bundle. Thus its likely related to that. You should bring this question to the interest mailing list, you'll find there Qt's developers/maintainers. This forum is more user oriented.

Good info, @SGaist thanks :-) That link goes straight to my bookmarks.

@SGaist Thank you very much! I haven't got around to test it properly yet - but I'm marking this as solved.