[Qt5-feedback] Build system requirements for Qt5

[Bill Hoffman]

On 6/7/2011 6:23 AM, Oswald Buddenhagen wrote:

>>>
> while the general sentiment is true, this does certainly not apply to
> the above example, which is rather common code. it would be ok to forbid
> nesting, so the scope conditionals could be presented as a flat list,
> but that's about it.
>
>>> What we want from the above is the full listing of source files (to present in
>>> the project listing).
>>>
>>
>> Then, you would have some other cmake file that used that list and took
>> out the files that were not used on the current system.
>>
>> if(NOT WIN32)
>>      remove_sources(sources win.c)
>>
> this is insane. ide integration must not come at the cost of manual
> usability.

Agreed, it was a bit insane.  It would be really helpful if you could 
post some pseudo code that showed the use case of win32 sources and some 
sources that depend on some system introspection value. What does that 
input look like, and how does it work?
>
>> Certainly, before any new
>> system gets started,  it would be nice to spec out the functionality
>>
> we did. after implementing it, cmake wouldn't be cmake any more. so why
> bother?
(You did what?)
> but there is certainly room for borrowing some code or at least
> algorithms - cmComputeLinkInformation.cxx for example is a bonanza of
> well-researched obscure stuff.

CMake might still be CMake, but with a dual "UI".  I think what we are 
talking about is providing a new input specification to CMake.  It 
certainly would not be in the best interest of CMake for you to fork 
some of the c++ code out of CMake and create a new build system. I don't 
think it would be in the best interest of Qt either.  I think both 
projects would benefit from a combined effort where you can leverage the 
CMake testing, user base, development community.   CMake is full of 
obscure stuff that has been tested and well researched. CMake will 
continue to "grow" more code like that in the future as well.

-Bill