[Qt5-feedback] Qt5's qmake

[Peter Kümmel]

On 17.05.2011 09:25, André Pönitz wrote:
> On Monday 16 May 2011 22:56:07 ext Peter Kümmel wrote:
>> On 12.05.2011 22:08, Aaron J. Seigo wrote:
>>> On Thursday, May 12, 2011 08:19:43 Charley Bay wrote:
>>>> My vote would be a new tool, from the ground-up, using greater heuristics,
>>>> emphasizing simple/clean project configuration definitions.
>>>
>>> A configuration tool that is cross platform and which has comprehensive
>>> support for the various needs of real world applications, both proprietary and
>>> open source, is not trivial to say the least.
>>>
>>> Also, I'm not sure Qt really needs to be in the business of creating and
>>> maintaining such a tool. There is enough else to be done.
>>>
>>> Instead of reinventing the wheel to little end, despite the allure of thinking
>>> we can do it better than anyone else has before us ;) , I highly recommend
>>> adopting a known, proven and widely used tool.
>>>
>>> This would save on human resources, communicate the "right" things as to Qt
>>> being open and not a NIH driven effort and allow existing knowledge that
>>> exists around such a tool to be repurposed.
>>
>> But what ever you choose, when the tool already exists it doesn't fit 100% your needs.
>> I assume in the short it is maybe cheaper to re-event the wheel than to fight with
>> existing build systems.
>>
>> A other approach which came to my mind is inspired by GCC:
>>       the difference between frontend/backend.
>>
>> As frontend a new build language based on JS could be invented which fits all needs.
>> But then, as backend existing tools are used, for each job the best tool on the system.
>>
>> There is a 'configure' and 'generator' step needed to get a 'compile-system':
>>
>> configure     generator       compile-system
>> ---------    -------------     --------------
>> autoconf      autotools          Makefile
>> cmake          cmake             Xcode
>> ...              gyp           Visual Studio
>>                  qmake             ninja
>>                    ...             nmake
>>                                     ...
>>
>> So the idea is to support some tools to get the best results on one system, e.g:
>>
>> configuring
>> - autotools for Unix
>> - cmake for Windows
>>
>> generator
>> - gyp for XCode
>> - qmake for qtcreater
>> - cmake for MSVC
>>
>> And for something special a new tool could be introduced.
>>
>> This has the "advantage" not being forced to make a final decision to use
>> only one tool or to start over. New systems could be plugged-in others which
>> have proved wrong could be dropped and replaced by newer ones.
>
> There's nothing wrong with "someone" maintaining "things", but distributing
> limited resources over 20 different build systems does not exactly like a step
> into the right direction. Getting one system into a shape that makes it
> painlessly usable for both Qt and Qt Creator will be challenging enough.

"usable for both Qt and Qt Creator" is qmake good enough for this only?

I assume it's less work that to start from scratch.
First I would only support cmake as back-end, so only the mapping
JS->CMakeScript would be needed, which should be not that hard.

Then this would happen:

- user writes JS build code, nothing else
- calls the new build system
- system generates CMake code
- cmake generates Makefiles, Xcode, ...

cmake could be embedded so it looks like one tool only.

>
> Andre'
>
> PS: I actually wonder why _you_ propose that. We both know pretty well how a
> project that can't make basic decisions like that wastes energy over and over
> again, don't we?
>

I also haven't found the perfect build tool, and this was a idea which I never saw.

Peter

>
>