[cdt-dev] RIP Wascana, Build System discussion

[cdtdoug@xxxxxxxxx]

I'm abandoning Wascana, at least for now. If you haven't seen my blog entry, please take a look: http://cdtdoug.blogspot.com/2009/05/wascana-is-over.html. I have little time to spend on CDT and I'd prefer spending it on the infrastructure to support things I actually work on. I don't spend much time in Windows any more. As I said in the blog entry, if anyone wants to carry the torch for CDT on Windows, I'd be happy to provide guidance.

That brings up something radical that crossed my mind. I started this whole build model thing for two reasons. One, to allow us to create modeling tools that work with build settings (big business there ;) and to equal Visual Studio's managed build system, which as I abandon Wascana, doesn't matter as much to me anymore. It really looks like we don't have enough investment to keep the build model going and to fix all of the issues with it. I'm wondering if a new approach is required.

Alain's work on the Makefile editor to provide a good parser for it opens some doors. And given the power of gnu make, I wonder if building a strategy around a good makefile editor, a la the plugin.xml or Android manifext.xml editors, and a good template engine to create Makefiles with enough information to build certain types of projects, would be a more practical approach. Gnu make is available on our three major platforms, Windows, Linux, Mac, but we need to confirm availability for other platforms. Also the vast majority of our users use gcc, and we could continue to rely on gcc generated dependencies and abandon the internal builder entirely. The build definitions can still be used to provide info to customize the Makefile editor and to provide scanner Info.

This is something that just jumped into my head in the last couple of days and needs to be fleshed out. It still needs a story for people using non-gnu tooling. And there are some good things in the current system we should keep, like the scanner provider stuff (but in a simpler way), resource specific build info, build exclusions, configs, flexible UI.

But at this stage of the game, I think it's important that we pick a solution that is practical given that we have such little commercial interest in CDT's managed build solution. Everyone still has their own build system, so why are we investing in something big that most CDT users don't need.

Please let me know what you are thinking and we can discuss further in upcoming conference calls. I'll continue to flesh out this story so we can make an decision on it. Unless you all think it's crap in which case, I can drop it.

Thanks,
Doug.