need to bootstrap somehow

similarly to compilers, build tools face a somewhat fundamental problem: you need one to build one ...

as we are aiming at becoming qt's own build tool, we should not keep relying on qmake for the build (though it would be possible to carve out the bootstrap of qmake as well, thus making the build chain qmake => qbs => qt).

direct self-hosting (using qbs to build qbs) would be possible, but it has the downside that we'd need to maintain backward compatibility for all features we use, which is a bit annoying until we stabilize somewhat. also, we'd certainly upset some purists by extending their "binary bootstrap set" (though this is arguably stupid).

one possibility is using the autotools. for windows we'd require mingw+msys, which seems a perfectly justifiable requirement.
the downside is that hacking support for moc into automake is no joy.
also, it is a bit of a defeat not to be self-hosted at all. and having two build systems in parallel (like cmake does) is ugly.

what we could do instead is using the autotools (specifically autoconf), but substituting automake by qbs with a makefile generator. we'd define a pseudo platform which has various @MACRO@ strings instead of proper commands and arguments, so autoconf could be used for configuring the actual build. the autoconf dependency is a deviation from true self-hosting, but i don't expect a whole lot of configure magic being necessary for qbs in the first place.
we'd distribute the qbs-made Makefile.ins along with the autoconf-made configure, as is typical for autotools projects. assuming the generator output is stable and somewhat optimal, we could check the makefiles into git as well, thus solving the bootstrap problem not only for the users, but also for us.

another possiblity is writing a "mini-qbs" in perl, either as a native build tool or a makefile generator. this seems like an utter waste of resources, though.

a very non-appealing possibility is maintaining makefiles by hand. this is annoying enough for qmake already, and that one is really small compared to qbs (including qt dependencies). also, it would imply maintaining two build systems as well if we want any meaningful IDE support.

note: we need to bootstrap moc as well if we want to use any of Q_OBJECT's features. that's probably no big deal, as we'd build a bootstrap version of qt for us anyway.