Hi Denis, 2013/7/30 Denis Shienkov <[email protected]>: >> So let's hammer down the scope: >> >> Are we discussing a generic infrastructure in Qt Creator that can be >> used to define all possible optimization levels of the different >> supported compilers and then pass them on to the different build >> system supported by QtC >> >> --or-- >> >> are we discussing how to set the optimization property from qbs? >> >> My understanding after your first mail was that we are talking about >> the first. Now I think we are talking about the second. > > > Most likely it is a talk about pair of QBS & qbsprojectmanager...
My question is not which code will need changing but what you actually want to do. > Because I mean not only display of "standard" names of options of > optimization (which "hard coded" in QBS at present), but also about CXX, C, > ASM and LINKER flags. I.e. it is more global and complex issue. So this is the 3rd use of the two options given above: A generic infrastructure to set up compiler/linker/asm flags with a specific implementation for qbs? >> You can also set them via the command line and via the "Properties" >> field in the build settings of Qt Creator. > > > Yes, of course. > > In principle, has no value where to enter these options: or in command line, > or in the file of the project or somewhere. The main problem that the user > shall "advanced skills" and perfectly know options/flags of the compiler > which uses. I think there is a lot of value for those advanced users. We seem to be in agreement that this is not for more average users. >> I agree that this is not the ideal UI for setting all the different >> properties. We should get a list of all properties defined in the >> project (and the modules used by it) from Qbs, together with the set >> of possible values. > > > Agree. > > But the set of possible values we can store/contain in "database" of > qbsprojectmanager plugin . IMHO, we not need to query possible values from > QBS, we need to query only present settings from the current project (from > *.qbs file). I do *not* want to have a properties DB in the QbsPM plugin! That will be outdated as soon as it is commited:-) All the information has to come from qbs somehow, incl. the defined properties, their value range (if applicable) as well as a (optional?) description that can be shown to the user. The good thing is that qbs already has "PropertyOptions" defining all that. So it is a question of defining a API to retrieve this information from qbs. > I suggest to enter a certain entity/class like "OptionsDisplayer" (for > qbsprojectmanajer) which would have the virtual method > > ... > QWidget *OptionsDisplayer::createWidget() const = 0 Why? Qbs will return a return a list (maybe a tree) of properties with type, a description and maybe a list of allowed values. That can be visualized like e.g. the properties of QWidgets in the Qt Designer. Why do you think special widgets will be needed for certain areas of this? Basically I am thinking a bit along the line of what cmake-gui does. See http://www.cmake.org/cmake/help/runningcmake.html ? I actually wanted to wait a bit and see what the probes found in qbs develop into (they can be used to find libraries, etc.): Those might have an impact on how the UI should work... > PS: Yes, I know that at present in qbsprojectmanager isn't implemented yet a > display/showing of used tollchain (e.g. as for qt4projectmanager plugin) . > But on future it will be implemented (I hope) ? I have no plan for that yet. Basically the kit already defines the toolchain being used (well, the compiler), so why have another UI for that? Creator already pushes its kit definition into qbs, defining the tool chain and Qt version etc. and makes them available to the commandline qbs client, too. >> This will allow to set "qbs.optimization" to "fast" or "space" or >> whatever. > > Not only it, but is possible also set and other options... Yes. That was the idea:-) >> It will _not_ allow to specify settings at the granularity shown in >> your screenshot: You can just show the settings of qbs, not the exact >> flags that will end up in the call to the compiler. > > Granulation of optimization options which I provided - only for an example > (btw I take an example from Code::Blocks - there granulation). I simply > wanted to show a place in which where I plan to insert OptionsWidget. Ah, ok. > PS: I simply curious to know: what do you (and others) think about idea to > add UI for display (in user-friendly form) of options of the > compiler/linker. For qbsprojectmanager plugin of QtCreator. A nice way to set all the properties (which includes qbs.optimization, etc. as well as paths to libraries used and other more high-level things) is essential and the place you picked in your screenshot seems very reasonable to put this. I think the actual implementation will look more like the property editor in Qt Designer than in your screenshot though. I just want to limit the information displayed to what is available from qbs (no API for that yet, but the information is already available to qbs) and do not want to have the QtC plugin ship a database of common settings. Projects will define their own properties, and those can not be covered in a QtC database and the database will be impossible to keep up to date anyway. Best Regards, Tobias _______________________________________________ Qt-creator mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/qt-creator
