Community
Participate
Working Groups
It used to be editable, I think, now it is read-only. Øyvind
Sorry Oyvind, but we decided to revert to the more basic functionality for 2.1 and 3.0. Even with the relatively simple GCC option set, there were a lot of bugs in the round-trip parsing, and the issue you raised surrounding option re- ordering from the widget made me think that we need to properly spec out this functionality and use cases. Until we can do that and consider how to support all of the other toolchain definitons we hope to see added to the CDT, I am afraid that we have to sacrifice this functionality. That said, I know you have thought about this a lot, so feel free to weigh in on this decision in the bugzilla 68232 entry or on the dev list. Thanks for all your dilligent feedback on the MBS!
First of all: I agree completely with your action on this one, given the state of affairs. (Better to do something simple and correct, than something feature rich that can't be trusted. Right?) >Sorry Oyvind, but we decided to revert to the more basic functionality for >2.1 and 3.0. Even with the relatively simple GCC option set, there were a lot >of bugs in the round-trip parsing, and the issue you raised surrounding >option re-ordering from the widget made me think that we need to properly >spec out this functionality and use cases. I'm not convinced it is a good idea to try to implement round tripping. How can you possibly know that the code is correct and complete? Ick! :-) > Until we can do that and consider >how to support all of the other toolchain definitons we hope to see added to >the CDT, I am afraid that we have to sacrifice this functionality. Hmmm... how about this: - Either CDT has its way with the options - Or, the user controls *all* options in managed make Managed make is cool for demo stuff, but I'd like to see it work in a production environment as well. E.g. eCos (open source OS) managed make would be cool. Øyvind
As discussed in the weekly meeting -- all enhancements requests that had a target milestone of 3.0 but were assigned to an inbox owner (which is an invalid combination), have been moved to Target Milestone "--".
I'd like to join the original requester in asking to support the editable "All options" field. It would greately facilitate porting the projects to/from Eclipse. I'm not sure what is meant by "round-tripping" (parsing all the options and populating particular option fields?) and maybe it's hard to implement but there could be a choice for a user to make whether to use the regular fields or edit them directly in the "All options". Please consider adding this feature, perhaps for 3.1?
(In reply to comment #4) > I'd like to join the original requester in asking to support the editable "All > options" field. It would greately facilitate porting the projects to/from > Eclipse. I'm not sure what is meant by "round-tripping" (parsing all the > options and populating particular option fields?) and maybe it's hard to > implement but there could be a choice for a user to make whether to use the > regular fields or edit them directly in the "All options". Please consider > adding this feature, perhaps for 3.1? There are several reasons why this could not be implemented easily with the current Managed Build System. Here are some of them that come to my mind immediately: 1. MBS does not always know how the command is generated from the options since ISVs can provide the custom command line generator. So MBS can not always figure out how option values should be parsed/generated given a command. 2. MBS does not maintain the information about the option order in the command line, so in case you specify option “a” followed by option “b” in the “all options” filed, there will be no guarantee that they appear in the same order in the command line. 3. Command line generators currently generate commands with some syntax specific to the builder/shell the tool to be used with (space and special character escaping, etc.). MBS does not know how to reverse-engineer this syntax to the real option values. There are no particular plans for implementing this currently, but you are welcome with any ideas and/or suggestions. As for the easy integration, one approach that could be used is the “project custom build steps” functionality planned to be implemented in the future. The project custom build steps will allow to specify in UI the commands and options to be used for building some particular resource type (e.g. .c files). This is similar to the already available resource custom build steps functionality that allows specifying commands for individual resources currently (see the bug# 88922 for more detail). The project custom build steps should allow easy integration of the tool-chain/project by specifying commands and options to be used for building the project resources. Thanks, Mikhail
Hi. I've got a patch that implements this functionality. Rather than attempt to create one single parser that understands all options for tools it is better to create a framework to allow MBS tool-chain providers to provide a parser on a tool by tool basis through a well defined interface. This interface takes a command, a configuration and a tool and is supposed to reflect the tool settings the command represents into the configuration supplied. All the MBS To aid the MBS tool-chain writer the schema specification of MBS tool options has been extended to allow synonyms of commands, this information gives the command-parser writer Options of the form: --option or -o can specified as having synonyms of -s or --synonym (for example). Further for Enumerated options of the type --option=argument there is a facility to have a synonymous arguments independent of option. Further attached is an example implementation of this for the GNU toolchain the CDT provides by default (gnuOptionParser.patch). This depends on the existence of the org.apache.commons.cli library, unfortunately this library isn't really functional enough so modifications have been made by myself. I appreciate this will require various legal reviews, so the facility to allow parsing for a tool is decoupled from the GNU implementation (which logs the dependency). This parser uses the existing MBS specification of tool options to set up the parser and ought be reasonably reusable by tool-chain providers. Suggestions/queries are welcome. I'm attaching the patch to org.eclipse.cdt.managedbuilder.core and org.eclipse.cdt.managedbuilder.ui patch now and will attach the modified Apache library project and modifications to org.eclipse.cdt.managedbuilder.gnu.ui tomorrow. Chris Mead.
Created attachment 62248 [details] Modifications to facillitate "All Options Parsing" for MBS tools.
> will attach the modified Apache > library project and modifications to org.eclipse.cdt.managedbuilder.gnu.ui > tomorrow. I'm thinking we may be too late to have the IP review of the Apache library done in time for feature freeze. We may need to hold this off to CDT 4.1.
Created attachment 62370 [details] Contains modifications of org.eclipse.cdt.managedbuilder.gnu.ui
Created attachment 62371 [details] Modified org.apache.commons.cli to work as plugin and more robust functionality.
Created attachment 62372 [details] Modified org.apache.commons.cli to work as plugin and more robust functionality.
