Hi,
This actually goes farther than I was thinking but definitely in the same direction. The problem is how to deal with external build systems like autoconf, qmake (another good one!), and the Android build system which has a complex framework of Makefiles
(probably similar to qmake), as well as several other build systems, or even simple makefiles. With these systems, I can see a custom UI for each for dealing with settings users of these systems typically change, e.g. configure settings. And we can even look
at setting things like CFLAGS based on a similar UI and maybe even the same build definitions that the MBS has.
[[ejs]] That sounds good, as long as the MBS build definition model usage is optional. I'm not sure CDT has to provide "the" model for generating such UI, just "a" model. My intent was that support for these
external build systems would be separate plugins, integrating as loosely as possible with CDT. A model for flexible XML-driven UI need not be part of CDT at all, for example.
I think the biggest addition we could add is templates to the new Project wizard for specific project types that can provide a flexible UI for settings, generate the appropriate files and set up the appropriate listeners for resource or code model changes.
Our existing template engine might not be functional enough to handle this (or we want to use this opportunity to do a new one that's easier to use).
[[ejs]] IMHO, the CDT template engine should have little or nothing to do with project UI or setting up the listeners for resource/model changes (if I understand your meaning) -- consider importing or converting
existing projects that aren't built from templates. Probably the build model itself should do this work (via extensions I mentioned).
The CDT project wizard would be most useful as an aggregation of reusable parts, which allow such flexible UI to be generated in a vendor-specific way (perhaps by extensions mentioned in templates) without
requiring that the templates themselves be the only way to use the flexible UI.
Consider that some vendors do not use the CDT project wizards or templates. (For instance,we have a Maemo IDE integrating both CDT and Pydev as well as one that only uses Pydev. Since Pydev has no template
project model and also does not build on CDT, we needed an independent template engine and project wizard in order to provide a unified project creation UI in both products.) I think it's best to keep these areas of functionality as loosely coupled as possible.
As with Leo, I haven't thought about the CModel and how it would reflect build info, other than a long time wish I've had to have build configurations represented there which could add to the tree or filter or decorate the content based on build information.
[[ejs]] Well, if you were originally working to compete with Visual Studio, it seems this would have been one of the first tasks ;) The Navigator view properly serves as the filesystem viewer, IMO. The current
Project Explorer seems to serve the same purpose, except for some extra top-level decorated folders.
For instance, in CDT 5.0.2, I imported a Make builder project with a lot of stuff and replaced the default project root Source folder with one pointing to a deeply embedded source directory. The folder and
file decorations changed a little, yes, but the same number of files and directories are visible. Even if I set Source folder filters to add a root folder which filters out exclude all the other content but that source folder, the same content (number of files
and directories) shows up afterwards.
So, I went to Customize View > Context and turned off everything but CDT elements. Same content.
I was finally able to muck with the Filters in the Project Explorer to hide non-C elements, empy parent folders, and empty folders, but a lot of empty directories are still left behind (because they're not
actually empty, though their content has been filtered to make them look empty).
But this approach of starting from the filesystem and whittling it down is backwards, IMHO. If the user's project is driven by a given build script, then I argue, that script really represents the project
for the user. We'd like a way for the content of that/those scripts to drive the structure of the C/C++ content in the Project Explorer (or CModel, if that is necessary) rather than starting from the filesystem or MBS/indexer settings and adding filters.
Greate ideas, Ed. I hope you have the time to help with this effort. We'll have to set up a meeting to kick this off. Feel free to write up a proposal and I'll do the same.
[[ejs]] Thanks :) My time is tight for the next few weeks, but I can provide feedback on the proposed extension points and
the use cases to consider if you start sooner.
-- Ed
________________________________
Sent: Friday, May 22, 2009 2:25 PM
To: CDT General developers list.
Subject: Re: [cdt-dev] RIP Wascana, Build System discussion
On Fri, May 22, 2009 at 12:14 PM, <Ed.Swartz@xxxxxxxxx> wrote:
Hi all,
Regarding building outside CDT, here some ideas based on use cases in our embedded (Symbian and Linux) products, which could make CDT more friendly to external build systems.
We use, variously, autotools (though not Jeff's autotools builder, for reasons mentioned by Doug), qmake, make, and Symbian's build system, but want stronger and more unified UI integration. We've had to do a lot of custom and repetitive work
for this.
What if, instead of a completely hands-off model, like the standard make model where the user manually edits Makefiles in an editor, or a completely automated model like MBS that involves full control of compiler/linker invocation, there were an
external build model that provides architecture for wrapping existing build systems, such as autotools, qmake, scons, etc. and integrating the build system's model into the UI?
The goal of such a model, as others have mentioned, would be to let the user switch back and forth between the IDE and the command line freely and to let the user share projects from source control with developers not using IDEs. But unlike standard
make or managed make, it should automate the updating of build scripts from resource changes and update build configuration data from build script changes, without completely taking over the work of the build system or relying on build-time parsing to gather
configuration data.
In addition to the build support, there should be UI integration support for a custom common project navigator model derived from the build scripts. I.e. the external build system should be able to influence or control the way the CDT
project navigator model is generated. We're still hammering out UI issues with presenting the project model that's really built versus the tree of files that happen to be living in the project directory. CDT's source folders alone don't cut it as an organization
strategy :) We've resorted to ancillary views for this, reinventing the wheel to attach copy/rename/move/build actions, support filtering, etc (gahh).
The builder support, I think, would be minimal: a custom command-line builder, similar to the standard make builder, which controls the build by invoking the external tool with build scripts/files from the project. It could handle
incremental/full/clean builds similarly to standard make as well, with appropriate vendor configuration.
Extensions would be implemented and invoked by CDT to (1) handle synchronizing changes between the resource model and the build scripts by interpreting resource change events, (2) generate build configuration data and indexer settings by
parsing build scripts, (3) react to modification, creation, and deletion of build scripts, (4) analyze resource change events to determine whether a recompile or relink or reindex is needed, and (5) generate/modify the CDT's project navigator model.
These extensions, in fact, need not be tied whatsoever to the external build model.
Of course, a lot of work must go into the implementation of the extensions, to handle parsing and rewriting build scripts. But by being standard extensions to CDT, standard implementations could be written once (e.g. managed make + standard make,
autotools, qmake, etc).
Would it be appropriate for CDT to provide support like this? Were you thinking something along these lines?
This actually goes farther than I was thinking but definitely in the same direction. The problem is how to deal with external build systems like autoconf, qmake (another good one!), and the Android build system which has a complex framework of Makefiles
(probably similar to qmake), as well as several other build systems, or even simple makefiles. With these systems, I can see a custom UI for each for dealing with settings users of these systems typically change, e.g. configure settings. And we can even look
at setting things like CFLAGS based on a similar UI and maybe even the same build definitions that the MBS has. Automatically dealing with new/deleted resources and adding them to the build is a key requirement as well. And letting users change the appropriate
files externally is also a must.
I think the biggest addition we could add is templates to the new Project wizard for specific project types that can provide a flexible UI for settings, generate the appropriate files and set up the appropriate listeners for resource or code model changes.
Our existing template engine might not be functional enough to handle this (or we want to use this opportunity to do a new one that's easier to use).
As with Leo, I haven't thought about the CModel and how it would reflect build info, other than a long time wish I've had to have build configurations represented there which could add to the tree or filter or decorate the content based on build information.
Greate ideas, Ed. I hope you have the time to help with this effort. We'll have to set up a meeting to kick this off. Feel free to write up a proposal and I'll do the same.
