Re: [cdt-dev] A Builder Proposition

[Phil Muldoon <pmuldoon@xxxxxxxxxx>]

Alain,

One of the things we are looking at here at Red Hat is a development RPM
plug-in, that would merge in with some of the stuff you are proposing.
One of the aims for this plugin would be to be able to import SRPMs and
output RPMs as part of the build process, and to modify the build
process as it currently exists to fit this requirement. I then saw your
mail, and though neat, someone else is exploring the build area and how
it can be built upon, and possibly improved. In conjunction with your
discussion, I'll dip my toes in the water and expound on some points.
Hopefully this will get the ball rolling! 

Regarding your proposal, what are currently looking at, and would
probably have implications on:

>Passing Info from the UI to the builder:

Probably the quite a bit of work here, in the application of a spec file
editing and maintenace. Possiblity an extension to the editor to assist
spec file editing (syntax highlighting, etc).


>     * setting of arguments
>     * setting of Environment
>     * working directory where to execute the build process
>  - allowing different configurations(say: Build in debug mode, for a
particular architecture...)

All again would be context sensitive to what we are looking at. It
raises some interesting question, especially the differing architecure
targets.

I won't comment on the the CBuilder class layout yet as I am still
exploring that. However it looks like a pretty cool design. I especially
like the proxy method as explained. I just wanted to drop a quick like
to register our interest.

Regards

Phil Muldoon
Red Hat


On Wed, 2002-09-11 at 22:17, Alain Magloire wrote:

> 
> 
> The flow: a plugin implementing the extension point and the interface ICBuilderCommand,
> will register itself has a BuilderCommand to the CDT BuildModel for project xx.  It
> can also register itsef as info provider by implementing ICBuilderInfo for project xx.
> This is usually done via the wizards when creating a project or via property pages etc ..
> When the user invokes Eclipse IncrementalBuilder, for project xx, it will call the CDT
> builder which in turn will call the register ICBuilderCommand for project xx.
> 
> The idea is to have a builder for the C/C++ Projects on the eclipse side, this
> builder will serve as a proxy and call the "real" Builder providing relevant
> information like arguments(calling "make clean", in Directory project/src;
> 
> 	/**
> 	 * CBuilder is the CDT generic Eclipse builder it serves
> 	 * as a proxy calling the real builder since the Eclipse builder
> 	 * does not pass enough information.
> 	 */
> 	public class CBuilder extends IncrementalProjectBuilder {
> 
> 		IProject[] build(int kind, Map args, IProgressMonitor) {
> 
> 			// Retrieve the BuildModel from the CDT CorePlugin
> 			BuildModel model = CCorePlugin.getBuildModel();
> 
> 			// Get The buildCommand for this project.
> 			ICBuildCommand command = model.getBuilderCommand(getProject());
> 
> 			// Set the information: arguments/CWD/Environment/ etc ..
> 			command.setArguments( args );  // they ask for the argument "install"
> 			command.setWorkindDirectory( cwd ); // in "project/src"
> 			command.setEnviron(props);  // setting "PREFIX=/tmp/installation"
> 
> 			// Invoke the register builder
> 			return command.build(this);
> 		}
> 	}
> 
> 
> public interface ICBuilderCommand extends ICCommand {
> 	IProject[] build(IncrementatlProjectBuilder eclipseBuilder);
> }
> 
> public interface ICBuilderInfo {
> 	IPath[] getIncludePaths();
> 	IPath[] getSystemIncludePaths();
> 	IPath[] getLibaryPaths();
> 	String[] getLibaries();
> 	...
> 	void setBuilderConfiguration(ICBuilderConfiguration config);
> }
> 
> public interfave ICBuilderConfiguration {
> 	String getName();
> }
> 
> public interface ICCommand {
> 	String[] getArguments();
> 	void setArguments(String[] args);
> 	IPath getWorkingDirectory();
> 	void setWorkingDirectory();
> 	Properties getEnvironment();
> 	void setEnvironment(Properties env);
> }
> 
> 
> Lots of details are missing here: the way a plugin registers a Builder for a specific
> project, the persistency, the extension points.
> 
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/cdt-dev