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

Well another three weeks and no news about this topic?

@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.

@Wieland: Thanks for the heads-up, I upvoted and subscribed for that bug report.

Ok, i found the solution.
I had to recompile qmake with pkg-config enabled.

My bad ! It was .qmake.conf that you can use for your common variables.

Ok. Thanks.

@Peppy Right now it just won't work without installation, however you can install it separately from Qt (just point QMAKEPATH to proper location)