hi,
i want to approach the compiler integration thing soon. Therefore, i want to discuss how we should realize that. There are several ways to approach this:
1) Don't use the builder framework and realize it like it is now (maybe move the tau stuff to its own plugin)
2) Use the builder framework. * allow several builder plugins to be installed at a time -> do we allow compilation using several compilers in one run -> should only one compiler be active
* allow only one builder plugin to be installed at a time
Lets assume we want 2). The first choice (allow several builder plugins to be installed at a time) requires our own extension point. The builder would be implemented in TRex UI and it would delegate its work to corresponding builder plugins. However, it requires a preference page where the compilers are selectable/chooseable and addition to the preference pages for the compiler options. This page would not be necessary if only one builder plugin would be allowed to be installed at a time.
Another thing to discuss is, what the builder is supposed to do. Tau currently has three options: Analyze, Compile, Create Executable. How should this be handled in a builder:
* Make the builder configurable, e.g. configure the builder not to compile * The builder always compiles everything
Then again, depending on the compiler, it may not be possible to differentiate the step compilation and create executable (this seems to be the case with danet). Concerning the executable building: currently, the exeutable is built from the currently active or selected file or something like that i suppose. This is probably not a good idea when the builder is used since the default Eclipse behavior is that we would expect the project to be built and not the active file. Hence, there must be a project property page or yet another navigator label decorator where modules with control parts can be selected for executable building.
I guess there are tons of other decisions that i am missing in these first thoughts, but it should be enough to start the discussion.
Benjamin Zeiss wrote:
hi,
i want to approach the compiler integration thing soon. Therefore, i want to discuss how we should realize that. There are several ways to approach this:
- Don't use the builder framework and realize it like it is now (maybe
move the tau stuff to its own plugin)
- Use the builder framework.
- allow several builder plugins to be installed at a time
-> do we allow compilation using several compilers in one run -> should only one compiler be active
- allow only one builder plugin to be installed at a time
Lets assume we want 2). The first choice (allow several builder plugins to be installed at a time) requires our own extension point. The builder would be implemented in TRex UI and it would delegate its work to corresponding builder plugins. However, it requires a preference page where the compilers are selectable/chooseable and addition to the preference pages for the compiler options. This page would not be necessary if only one builder plugin would be allowed to be installed at a time.
Another thing to discuss is, what the builder is supposed to do. Tau currently has three options: Analyze, Compile, Create Executable. How should this be handled in a builder:
- Make the builder configurable, e.g. configure the builder not to compile
- The builder always compiles everything
Then again, depending on the compiler, it may not be possible to differentiate the step compilation and create executable (this seems to be the case with danet). Concerning the executable building: currently, the exeutable is built from the currently active or selected file or something like that i suppose. This is probably not a good idea when the builder is used since the default Eclipse behavior is that we would expect the project to be built and not the active file. Hence, there must be a project property page or yet another navigator label decorator where modules with control parts can be selected for executable building.
I guess there are tons of other decisions that i am missing in these first thoughts, but it should be enough to start the discussion.
I would also suggest approach 2). In general it makes no sense to have two or more compilers active at a time. However, it might be nice to be able to switch between compiler at TRex runtime. It would also be nice to allows for different "kinds" of compilation as we currently support for TAU, i.e. analyze, compile, build full executable. However, different compilers may support different kinds.
With my restricted creativity this seems to require that each compiler integration shall provide its own preferences page compiler specific settings may be made (a file system path to the compiler, but also e.g. whether a "compile" triggered by the builder does just analysis, compile, build executables etc., or whether a makefile is used. This would really be compiler specific. I suggest therefore, that the extension point only supports a "compile" command it depending on a selection at a specific compiler preferences page, this might result in just an analysis or a full build etc.) On the root preference page of the TRex compiler section, the user may then select the compiler integration to use. Completely, disabling all compilers would also be nice, because our marker generation is as well called by the builder, and it would be nice to be able to restrict to building just metrics and markers.
(We should also have a look, how CDT deals with these issues.)
I have not thought much about building a whole project instead of just the active file. I am not even sure if all existing compilers require to designate a module with control part.
Just my quick remarks, Helmut
Hi,
I would also suggest approach 2). In general it makes no sense to have two or more compilers active at a time. However, it might be nice to be able to switch between compiler at TRex runtime. It would also be nice to allows for different "kinds" of compilation as we currently support for TAU, i.e. analyze, compile, build full executable. However, different compilers may support different kinds.
Exactly. I have just committed the very basic infrastructure that realizes this. A few details will probably change (e.g. the delegate must somehow get a reference to the project/files to be built). Currently, you can select your compiler from the project preferences. Depending on what you chose, a "Hello from Danet" or "Hello from Telelogic Tau" or something like that should appear. The compiler builder can be disabled from the project preference page just like the refactoring rule builder.
So i guess there'll be some global compiler preferences which should be grouped under "Compiler Integration" and there will also be project or even file specific preferences (e.g. for Danet, i will probably provide an option to specifiy the dependant files on a file basis as i currently don't want to generate a file dependency graph). It would probably make sense to mark those files with a special decorator.
The other two open things are: 1) How and where to specify what files containing which control parts are compiled 2) How to realize the different modes, i.e. analyze mode, compile mode, executable building mode
For 1) i would think they should either be selected just like the enable/disable action and then again be decorated differently.
For 2) i am not sure whether it should be a global settings (preference page) or a project specific (project property page) setting. Basically, both solution aren't too brilliant as this settings eventually has to be changed more often. Other possibilities are: * Forced popup on every build. This would kind of make the background building annoying in my opinion. * Setting direct setting through context or top-level menu. I could try to make three different entries and the active one gets a check.
If the latter should be chosen, i probably have to somehow extend the extension point to enforce the configuration this way through the trex.ui plugin. Otherwise it would be more likely that third party compiler plugins (which aren't likely to exist i guess) handle the modes differently.
Benjamin Zeiss wrote:
Exactly. I have just committed the very basic infrastructure that realizes this. A few details will probably change (e.g. the delegate must somehow get a reference to the project/files to be built). Currently, you can select your compiler from the project preferences. Depending on what you chose, a "Hello from Danet" or "Hello from Telelogic Tau" or something like that should appear. The compiler builder can be disabled from the project preference page just like the refactoring rule builder.
I have not tried it, but that sounds nice!
So i guess there'll be some global compiler preferences which should be grouped under "Compiler Integration" and there will also be project or even file specific preferences (e.g. for Danet, i will probably provide an option to specifiy the dependant files on a file basis as i currently don't want to generate a file dependency graph). It would probably make sense to mark those files with a special decorator.
The other two open things are:
- How and where to specify what files containing which control parts are
compiled 2) How to realize the different modes, i.e. analyze mode, compile mode, executable building mode
For 1) i would think they should either be selected just like the enable/disable action and then again be decorated differently.
This sounds reasonable. However, I am not sure whether this is requirement for all compilers or whether this is a Danet only requirement. (In this case, it should be part of the Danet preference page. On the other hand, e.g. in the TTworkbench you need to specify a "main module" as well.) In principle one could also think of an approach where the control part to use is just selected at test exution time. However, I do not know whether any tool uses this approach.
For 2) i am not sure whether it should be a global settings (preference page) or a project specific (project property page) setting. Basically, both solution aren't too brilliant as this settings eventually has to be changed more often. Other possibilities are:
- Forced popup on every build. This would kind of make the background
building annoying in my opinion.
Really annoying!
- Setting direct setting through context or top-level menu. I could try to
make three different entries and the active one gets a check.
If the latter should be chosen, i probably have to somehow extend the extension point to enforce the configuration this way through the trex.ui plugin. Otherwise it would be more likely that third party compiler plugins (which aren't likely to exist i guess) handle the modes differently.
Yes. One could even think of more than three entries. Hence, each compiler plugin should be able to contribute a menu entry. When selecting a different compiler from the project preferences, the displays entries shall be switched and the compiler plugin shall select a default mode.
Bye, Helmut
trex-devel@informatik.uni-goettingen.de