> Why? The internal one would not be used for building. Of course you'd > lose the benefits of the integration and would need custom run > configurations and so on; that just follows from diverging from the > default workflow.
Hmm ... that sounds feasible, but still inconvenient to some extend. I'm thinking of a much tighter integration, like the IB integration in Visual Studio. Consider this use case: - The developer uses the internal Qbs build for all normal actions (building "small" changes, deploying, running), just because the Qbs-QtCreator integration is so nice - For long running builds however, the developer would like to use IncrediBuild instead, which speeds up compilation notably That's the way we work with IncrediBuild in Visual Studio. Now I wanted to provide a similar approach with QtCreator. All I need would be kind of an API to force writing the current state of the buildgraph to disk, locking it in some way, and later restoring the externally modified buildgraph from disk. The additional runtime effort of such a solution would be low compared to a build which would take 30 minutes or more the other way. So why not giving it a try? On the other hand, let me evaluate the approach you've suggested, and see how well it works in our environment. Thomas
_______________________________________________ QBS mailing list QBS@qt-project.org http://lists.qt-project.org/mailman/listinfo/qbs
