Shared publicly  - 
 
I'm not the only one wishing to stop having to deal with qmake.
8
Alexander Neundorf's profile photoBenjamin Zeller's profile photoThiago Macieira's profile photoTim Murphy's profile photo
23 comments
 
What if I want to make my own version of chaining tool for makefile?
 
I am not glad to have a lot of JavaScript inside makefile... just create somthing less brutal...I think, I will use this one: http://ne-on.org/
 
Finally another new buildsystem...
That's what we needed...

Alex
 
Hey, me too, but I'm also not looking forward to learning one more system to do what I can already do nice enough with CMake.
 
For me CMake is "one more system to learn": it has its own fugly language, while qbs offers already familiar structured QML with JavaScript.
 
I am not fond of CMake language, but it gets the work done. I like the idea of using JavaScript, but for now the lack of configure checks makes qbs a lot less attractive than CMake.
 
My sentiment is completely predictable: Another build system? Another island where Qt uses one thing, and all the rest of the world something else? More situations where project teams need to port between build systems? I can sure see a better way to use the resources spent for that.
Nevertheless, good luck :-)
 
+Mirko Boehm That something else is different between the platforms that Qt aims to support: autotools do not work well on Windows, for example.
 
Mikhail: the first and obvious candiate for that something else would be CMake. This is cross platform. Kitware even offered on the qt list to add support for some json declarative syntax to cmake.
 
The CMake team offered to add a new language for the Qt developers that would allow a declarative input to CMake. It was rejected.
 
qbs #ftw, CMake is a mess i'm glad i don't have to use it.
 
CMake may be a mess (I do not think it is, but the syntax does show it's age, admittedly). But starting something from scratch in the Open Source world instead of building on top of something that exists is not the best way IMO. To me, CMake with a complete language on top is way > than anything new that will need to add what CMake already has (FindFoo packages, for example) over the next few years. Remember, build systems are build systems, not the product we are working on. This is as if every car mechanic would make his own electric screwdriver.
 
+Benjamin Zeller What exactly do you consider a mess ?
Let me know, we don't want CMake to be seen as a mess, so we'll fix what is messy.
 
I think it is disappointing that they refused to at least explore the addition of a declarative language with CMake team, and think it would have been a positive move for both communities had they collaborated. I agree wholeheartedly with +Mirko Boehm, but we have known this was coming for some time.
 
Yes, it's not a beautiful language.
It's a domain specific language for building software, you shouldn't try to write programs using it. IMO for that it's good enough.

It actually also has become more readable: while with cmake 2.2 you had to write:

IF( FOO AND BAR AND BLUB )
SET(srcs main.c foo.c)
ELSE( FOO AND BAR AND BLUB )
IF( SOMETHINGELSE )
SET(srcs main.c helper.c)
ENDIF( SOMETHINGELSE )
ENDIF( FOO AND BAR AND BLUB )

you can now do:

if( FOO AND BAR AND BLUB )
set(srcs main.c foo.c)
elseif(( SOMETHINGELSE )
set(srcs main.c helper.c)
endif()
 
Is there actually a way to do some formatting like <pre> (for indentation) here in these comments ?
 
No, but you can trick it with some other types of spaces.
 
i think there was some basic formatting support just cant remember where i saw it
 
A problem with things like cmake is the way they have frontends (the cmake language) and backends (gnu make) - not at all nice when you are trying to understand a build problem and it's very much harder to implement a lot of useful features which are limited by how the backend works. QML also has the nice property that it's a hierarchical language - when you realise that you need a new level of build configuration (e.g. a file that describes what packages to put on a particular ROM image for example) you can do it without writing a new parser and your new format can act as a container for existing files in a neat way that can "just work".

I see configure checking as a tremendous side issue - there's no need for it to be part of the build system - once a config checking tool has created some sort of config.h.

Trying to be the same or standard or whatever is a total waste of time - build tools are stone-age and need to get a lot better and this is a very good attempt at it.
Add a comment...