On Thu, May 31, 2012 at 2:54 AM, Vojtech Kral <vojt...@kral.hk> wrote:
> 1. Compiler switches:
> The fact that you want to enter a compiler switch
> manually is itself suspicious. Why do you want to do that?
>
Vojtech:
I have built IDEs, so I fully understand (in a technical sense) all of the
issues you have raised concerning cross-platform build options. I disagree
with you.
First: even in the cross-platform build case, there are reasons to have
per-file and/or per-target switches. Some examples:
1. All sorts of -D options, for example to selectively enable debugging
features.
2. Multiple targets built with different options.
3. Multiple targets in the same project that use distinct compilers,
for example cross compile vs host compile
4. Unusual input files that may require control over low-level
runtime decisions on particular platforms
and on and on. Even if the only case is [1], you still need some mechanism
to add specific compiler switches on a particular sub-build. I understand
that the syntax for specifying switches varies from compiler to compiler.
That is a syntax problem only, and it is solvable. I also understand that
*some* switches are entirely target-dependent. That is also a simple
problem to solve. What we should focus on here is the *conceptual* issue.
Your point of view seems to be that QtCreator is intended to support
multi-platform development. That is the great power of Qt, and I like it
very much, but it is foolish to take this as a reason to *narrow* the
capabilities of Qt. If I choose to use Qt as my project and build
management system for a single platform project, why should that be wrong?
Personally, I believe that QMake is too simple for large-scale and/or
complex projects involving many libraries and/or many binaries. The QMake
CONFIG concept is overloaded in an unfortunate way, and the ability to
specify multiple targets in a single QMakefile (possibly compiled with
different options) is weak. I think that this can (and should) be resolved
by a successor to QMake.
In that successor, I see no reason why the user should not be allowed to
specify compile-specific and link-specific options, perhaps even on a
per-platform basis.
But I *definitely* agree that this is beyond the scope of QMake, and
probably CMake.
Do you want to see an example? If you want, you can check out
> https://github.com/kralyk/eldorado/blob/master/CMakeLists.txt
> (It's a project I'm partly working on.) You can go through all the
> CMakeLists.txt
> files (there is not just one, there a more with each add_subdirectory()
> command)
> and you can see for yourself that it gets a bit more complicated than a
> GUI dialog...
>
I haven't had time to look at this yet, but it's always helpful to look at
other people's complex examples. My sense is that a full-featured build
system really requires a browser for the build rules.
Until I worked with a whole-project build system while I was (briefly) at
Microsoft, I was not a fan of them. I thought they were too complicated to
maintain. The experience of using one has changed my mind.
My sense is that the qtcreator list may not be the right place for this
discussion, and I don't want to be rude to people here. Is there a more
appropriate list?
shape
_______________________________________________
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator
