Creator uses g++ although I have specified arm-linux-g++
-
In this case, is there a way to put it into my .pro file, so I am not dependent on the .user file?
(The .pro file is shared among our team. The .user file is private to each developer) -
No, you can not put the mkspec into the .pro-file.
You could try using a .shared file. That is basically a shared preset file that can contain anything that is also contained in the .user file. I am not sure how much that really helps, the whole thing is rather new and not used widely yet. We would appreciate feedback on this:-)
By the way: How do you share the tool chains?
-
Thanks for the info!
I do not currently share the tool chains. Right now, I just try to get it running on my machine. But I am already thinking ahead. Not having to make changes in each and every Creator project would reduce potential errors.
Once I have it running here, I might try out the shared project file.
-
This used to work correctly on Qt Creator versions prior to 2.3. It was broken in that version and although it has been reported as such it has not been fixed as yet. The basic problem is that prior versions used to use qmake to determine the mkspec whereas Qt Creator 2.3+ insists on overriding that mkspec with the incorrect one. The only solution at this time is to add the -spec argument manually for each project.
-
Oh great.
I want a big, fat checkbox somewhere in Creator options, called "Stick to what the .pro file and Creator settings say. No overrides"
It's not like it's the first time Creator tries to outsmart me. -
Well, the reason I have creator now use the mkspec that the tool chain suggests is that this allows to switch toolchains. This was not possible at all in Qt Creator <2.3 (or was that 2.2?). Then the tool chains were used to decide how to parse the output only and changing them did not change the mkspec used to build (so the tool chain was actually not switched). Lots of people complained about that, so I added switching the mkspecs. Now we get much fewer people complaining because this does break some cross-compiling setups.
Having said that, I do need to do something to improve the situation for the cross-compiling people. I am thinking of not overriding the mkspec of QMake if the compiler set in the toolchain is not used in the toolchain's mkspec... The problematic bit is getting the information on what is set in the mkspec in the place where I need to decide which mkspec to suggest. I'll might find the time to look into this later this week. Anyone volunteering to test? ;-)
-
Qt4iOS: http://codereview.qt-project.org/#change,15027 is something for you:-) It allows overriding the suggested mkspec of a tool chain.
I still want a review for that one though before I can commit it to master.
-
Ok, took a few days to get to test this, but I can confirm that the mkspec now defaults to 'default' instead of trying to guess the mkspec (which surely would be easy enough by just examining where 'default' points to?). The new 'toolchain->mkspec' and 'unconfigured project' settings will remove a few steps when setting up a new project... Thanks! :)
-
The patch is in master now. Thanks for the testing!