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 > > _______________________________________________ Qt5-feedback mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
