[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cdt-dev] build console code location
|
Maybe it's not a problem any more ( I was not monitoring changes in this
area last time), but I guess that a placing of console code in UI
plugin could be a cause of a big pain for those who implement headless
application with console output.
Alex
On 13/12/2009 1:45 PM, Doug Schaefer wrote:
As the new build system takes shape, we can eventually move it to the
cdt.build.ui plugins. The relationship between the make and
managedbuilder plugins right now is a little tough to figure, so I'd
prefer not to make the change now.
Doug.
On Sun, Dec 13, 2009 at 1:35 PM, Andrew Gvozdev <angvoz.dev@xxxxxxxxx
<mailto:angvoz.dev@xxxxxxxxx>> wrote:
Guys, please help resolving this problem, because I'm
completely blocked making patches
while build console is in cdt.ui.
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:
The current hierarchy goes like that:
cdt.core
|
cdt.make.core <- cdt.make.ui
|
cdt.managedbuilder.core <- cdt.managedbuilder.ui
The 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 <https://bugs.eclipse.org/bugs/show_bug.cgi?id=296935>:
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,
Andrew
2009/11/30 Dmitry Kozlov <ddk@xxxxxxxxxxxxxxxx
<mailto:ddk@xxxxxxxxxxxxxxxx>>
As Andrew Gvozdev wrote to me commenting one of build console
patches
"- 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."
But configuration is part of cdt.managedbuilder.core. So to
apply all my console enhancements and
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
Dmitry Kozlov wrote:
Hi,
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
to use
MakeBuilderUtil.getBuildDirectory(project, info) and
MakeBuilderUtil.getBuildDirectoryURI(project, info)
to get working directory for command (working in other
directory have no
sense)
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 =
ScannerInfoConsoleParserFactory.getMakeBuilderOutputSniffer(
stdout, stderr, project,
workingDirectory, null, this, null);
Will it be accepted by upstream if I move all build
console code to
cdt.make.ui?
---
Dmitry
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx <mailto:cdt-dev@xxxxxxxxxxx>
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx <mailto:cdt-dev@xxxxxxxxxxx>
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx <mailto:cdt-dev@xxxxxxxxxxx>
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
