[cdt-dev] MBS vs Std Make builder brainstorming

[Alain Magloire <alain@xxxxxxx>]

Bonjour,
  This an informal resume of a brainstorming session on the builders in the
CDT.  It was to clear some confusion on the history of old code and some
feature that the MBS did not take advantage of.

The notes are excerpt also from Leo && Mikhail emails:
 
* The IPathEntry framework and its goals [Alain]
* The demise of the IScannerInfoProvider extension
* The lack of integration of the IPathEntry in the MBS

	- Source folders: [Leo] MBS may be able to re-use some of the Std
	 Make UI implementation in the "C/C++ Project Paths" dialog

	- Object folders: [Leo] MBS may be able to re-use some of the Std
	 Make UI implementation in the "C/C++ Project Paths" dialog

	- Libraries: [Leo] MBS already has a "libs" option type that
	 identifies the option where the user enters additional libraries.
	 However, I think we also need to define an option type,
	 "libPaths" to identify the option where the user enters library
	 paths.  Otherwise, we may not be able to find the libraries.
	[Mikhail] There is a PR# 100844 for this and I will hopefully come
	up with some proposal regarding this in a few days...

	- Macros: [Leo] we support per-project, but not per-file
	[Mikhail] We could easily fix this by uncommenting some lines in 
	the ManagedBuildInfo.getOptionValues(). Looks like the per-file
	macro path entry calculation was accidentally commented along
	 with commenting per file includes (see my next comment).

	- Include paths:  MBS supports per-project, but not per-file.
	[Mikhail] pointed out that he had tried to implement per-file
	include paths, but they showed up in the C/C++ 	View at the
	project level. We felt that this is OK as long as there are
	no duplicates.  A PR was created to track this issue.

	- Prerequisite projects:  [Alain] explained that the CDT concept
	of a prerequisite project is a superset of the platform
	referenced project.  When the user creates an MBS
	project and sets referenced projects, we should assign both the
	CDT prerequisite project setting as well as the platform
	referenced project setting.  We should add a CDT prerequisite
	project UI to the MBS property pages.  We may be able to
	re-use some of the Std make UI implementation in the 
	"C/C++ Project Paths" dialog.  When building, we should use
	information from the perquisite project in order to
	automatically include the referenced project in the build.
	For example, it the referenced project is a library, add its
	location to the library path and its include file location(s)
	to the include path.

	[Mikhail] As I understand, the base idea of implementing this is
	to implement the mechanism of setting the MBS option values from
	the provided path entry values, e.g. if some include path entry
	is added to the project, the MBS "include" option should be
	added that path value.

	Also I[Mikhail] remember some conversation on the cdt-dev some
	times ago, when it was argued that the path entry <-> mbs option
	values data exchange mechanism should work in both directions,
	that is if e.g. some include option value is modified, the include
	path entries should be updated with respect to the modification
	(implemented currently), and also if some e.g. include path entry
	is added/removed from the project, MBS include option values
	should be updated.

	There are some things that remain unclear for me regarding
	making path entry <-> option values mechanism work properly
	in both directions:

	1. As Doug mentioned, the path entry framework does not support 
	configurations, so if some path entries are changed should the 
	changes be reflected to all configurations or only to the default
	one (currently used for building)?

	2. I still don't understand completely the mechanism that should
	be used in order to make the path entry -> option values
	mechanism work properly, namely:

	-how MBS will be notified that the path entries set is changed?
	 Should it register the listener?

	-since MBS provides the path entries itself based on the current
	 option values, how to distinguish between the values provided
	 by MBS and the newly added/removed values?

	-if the compiler defined in a tool-chain does not contain e.g. 
	 options that represent macros to the compiler, will the caller
	 of the path entry mechanism be notified somehow that the added
	 macro path entries will have no effect?

	- IIncludeEntryFile & IMacroEntryFile:  These correspond to the
	 gnu  switches -include file and -imacros file.  MBS needs to
	 investigate whether these represent a generic concept that
	 should be in the tool-chain definition, or something specific
	 to gnu.

* Doug brought the issue of using the MBS build model instead of the
IPathEntry scheme.  The main problem is the current framework (IPathEntry)
does not deal with different configurations. 

* UI inconsistency, we left for another day because we wanted to gain
 more insight on the problem before committing.
 [Mikhail] There is a PR# 102014 that could be used for tracking this. 
 Please see my last comment to that PR.. Comments/suggestions are
 welcome..

* Another UI issue was the different Variable views.  The MBS comes with
one so is the Platform.  Again this was left for another day.

* The MBS could not be run headless because of the conversion framework
 that requires a UI (Basically a dialog that say OK).  A possible simple
 solution was to move this conversion in the UI plugin (but the question
 is when is it trigger ?).  Another possibility was to provide an
 extension point for the query, basically the same scheme as the
 debugger(see IStatusHandler) for more.
 

In conclusion, folks would look at the IPathEntry scheme and see if we
should change it, enhance it, use something better etc ...  The idea
is to provide an interface that will serve as the communication API
for all the components of the CDT (Core Model, Debugger, Indexer,
search, etc ...) since they all need information that the builders
harvested, but can not be dependent of a builder in particular.

 
Points that was left due to lack of time:

 

* Binary Content type
* The faith of the .cdtproject framework for using the new project
 settings part of Eclipse-3.x (cdtpropject and the ICDescriptor
 framework was created because we could not have project specific
 settings in the old days).
* UI consistency (on going)
* Moving to higher level the notion of configurations.