On Tue, Oct 20, 2009 at 7:01 AM, Dmitry Kozlov
<ddk@xxxxxxxxxxxxxxxx> wrote:
Thank you guys for your interest and for many useful ideas. I want to sum up all questions and comments and provide some answers.
1. Run build button from console. I just trying to reuse existing build mechanism as it is used in TargetBuild class.
If you want to do builds from the console perhaps combobox listing existing make targets would be appropriate?
2. I will make preference in build console whether to show make arguments text field. If you can tell me for what kind of projects it should be enabled/disabled please advice and I will make this determined automatically.
It should not be only make arguments but user rather should be able to specify the whole command. Then, sometimes there is a need to run several commands at one shot. Inability to do so is pretty annoying in Make Targets View.
The feature should be enabled for all projects.
These make args provided by user are not used to update project configuration but work as one-shot deal just for make which is run pressing Run Build button at console toolbar.
Do you intend to persist the entered command to be able to rerun later?
3. Saving console now is implemented as saving current console content but not full build output. It is very good idea to use tee. I will take a look at this. Olexiy, you can help with this if you want.
It is probably better to specify where to save outputs before the build started, not afterwards. It would also avoid the problem of not full output.
4. I want to reuse error parsers to partition console output, but this is not implemented yet. I'm familiar with 50124 implementation and I will look at 203727, many thanks for this information. I'm not intended to use my own error parsing as it is done in 50124.
It is the general answers, but there are some technical problems which I want to discuss separately:
1. There a problem with TargetBuild: it is from cdt.make.ui, but console is in cdt.ui so using this results cyclic dependency between cdt.make.ui and cdt.ui because cdt.make.ui already depends on cdt.ui. In my current prototype implementation I copypasted TargetBuild to cdt.ui and slightly modified it. Are there other ideas how to cope with this without copy-past?
Copy-paste does not sound like a reasonable solution to me. There must be a better way.
2. To partition console output according errors I expected to reuse markers at Problems view, created by existing error parsers, but I failed to find public API to markers and this code unfortunately is part of platform, not the CDT. So there are 2 questions: 1) any idea how to do this without platform modification, 2) is it easy to check in appropriate platform modification motivated by needs of CDT project, can somebody help with lobbying this?
ErrorParserManager keeps the list of errors (markers) collected during a build. It is private but we could add a getter for the greater good. It is not hard to add build output line number in the marker properties too.
A couple more ideas:
- Currently builds lock the whole workspace. Perhaps it is reasonable to have an option to run such console command without locking and refresh? There are many workflows which would benefit like remote compilation. This would also help with a problem with markers appearing only after build is finished mentioned by Olexiy.
- Console View could have an options menu which many other views sport - the little triangle at top-right corner of a view. It open console preferences or other options.
Andrew
Dmitry
