|Re: [cdt-dev] build console code location|
As I already stated my opinion on a few occasions, Build Console should not belong to cdt.core but to one of build packages. In my opinion the most approprate place is cdt.make package. My reasoning is following:Guys, please help resolving this problem, because I'm completely blocked making patcheswhile build console is in cdt.ui.The current hierarchy goes like that:cdt.core|cdt.make.core <- cdt.make.ui|cdt.managedbuilder.core <- cdt.managedbuilder.uiThe console is used in both make.core and managedbuilder.core via IConsole interface. As far as I see IConsole is only used for Build Console notion.Currently managedbuilder took over "new" manaded builds and Makefile project build (which is just a flavor of a managed project). However, old style projects and their build live dormant in cdt.make plugins. Although you cannot create those in vanilla CDT installation, they are pretty much alive and still being used by some third party plugins. (As a side note: We can say that we don't support those but we should still keep them operational.)So, in my opinion, Build Console belongs to cdt.make.* packages.As far as architecture, I stated my vision in bug 296935 New CDT Build System:Doug provided several good examples how the build model would be used. I'd like to provide in some sense a counter-example to illustrate some thoughts about architecture:There is a certain category of users who need indexer code navigation but are not interested in any build. They just use CDT for editing C/C++ files. I would go that far as state that well engineered architecture would allow to do that without installing build plugins and any overhead related to build system.One corollary of that is that cdt.core plugin currently is bloated with features which should really be in other plugins. Just look at its size. Such features as error parsers, build console etc. should be in build plugin(s) rather then in core. I am thinking of a build system as being multi-layered where each next layer is built on top of another. One layer is core which provides core functions but none of related to build. Next one would provide general build facilities such as build console, error parsers, unmanaged build, scanner discovery (in that view it would be cdt.make plugin which is sadly declared dead). Finally, managedbuilder plugin which provides the means of generating makefiles. Different managedbuilders like Ed's middle ground builder could be created as well.Doug, since I think that may contradict the direction you are taking for the new new build it would be nice if you (and anyone interested) could comment on that before we started moving.
Thanks,Andrew2009/11/30 Dmitry Kozlov <ddk@xxxxxxxxxxxxxxxx>As Andrew Gvozdev wrote to me commenting one of build console patchesBut configuration is part of cdt.managedbuilder.core. So to apply all my console enhancements and
"- The name of build output file is being set in Builder Settings Tab (which is
good). However, the Builder Settings are per configuration, so the file name
needs to be stored per configuration as well. It should not be kept in
.project. .project/.cproject could be shared via code repository and I don't
think output file name normally belongs there."
to confirm all Andrew's wishes I need console to depend on
cdt.make.ui and cdt.managedbuilder.core. So there are two possible locations for buildconsole code:
top-level separate package or part of cdt.managedbuilder.ui.
Guys, please help resolving this problem, because I'm completely blocked making patches
while build console is in cdt.ui.
Dmitry Kozlov wrote:
we were discussing run command toolbar addition to build console toolbar.
The idea is to add fields to build console toolbar which enables to run
build command or some other command.
This code requires build console to depend on make.core because we need
MakeBuilderUtil.getBuildDirectory(project, info) and
to get working directory for command (working in other directory have no
and error parser:
StreamMonitor streamMon = new StreamMonitor(new
SubProgressMonitor(monitor, 100), cos, last.intValue());
ErrorParserManager epm = new ErrorParserManager(project,
workingDirectoryURI, this, info.getErrorParsers());
ConsoleOutputSniffer sniffer =
stdout, stderr, project,
workingDirectory, null, this, null);
Will it be accepted by upstream if I move all build console code to
cdt-dev mailing list
cdt-dev mailing list
cdt-dev mailing list
Back to the top