Bug 153816 - Support for multiple build consoles
Summary: Support for multiple build consoles
Status: RESOLVED FIXED
Alias: None
Product: CDT
Classification: Tools
Component: cdt-core (show other bugs)
Version: 4.0   Edit
Hardware: PC Linux
: P3 enhancement (vote)
Target Milestone: 4.0 M5   Edit
Assignee: Anton Leherbauer CLA
QA Contact:
URL:
Whiteboard:
Keywords: contributed
Depends on:
Blocks:
 
Reported: 2006-08-14 15:29 EDT by Jeff Johnston CLA
Modified: 2009-01-09 15:03 EST (History)
4 users (show)

See Also:


Attachments
CDT UI patch to support secondary build consoles (8.44 KB, patch)
2006-08-14 15:31 EDT, Jeff Johnston CLA
no flags Details | Diff
CDT UI patch to support multiple build consoles (10.07 KB, patch)
2007-01-30 17:22 EST, Jeff Johnston CLA
bjorn.freeman-benson: iplog+
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jeff Johnston CLA 2006-08-14 15:29:52 EDT
Currently the CDT creates a build console that is used to display the results of make.  In dealing with Autotools projects, there is a separate step to configure and create the Makefile.  The results of this configure can be pages in length and is useful information should something go wrong.

To save this information, we created a sub-console page.  Initially we hijacked the internal CDT BuildConsole code to do this and simply change the submenuid when creating the menu.

From BuildConsolePage.java (createControl):

		MenuManager manager = new MenuManager("#MessageConsole", #MessageConsole); //$NON-NLS-1$ //$NON-NLS-2$
 
We essentially just changed the 2nd parameter to get a 2nd console.  This 2nd console can be displayed by hitting the console icon in the view.

Rather than copying the internal code, I looked into adding support directly into the CDT.  The results is the patch attached.  Note that the patch was designed to leave existing BuildConsole usage as-is.

With the patch, any builder can simply add a sub-console to save the results.  The following code is our C Configure console implementation that uses the org.eclipse.cdt.core.CBuildConsole extension point along with the attached CDT patch applied.  Note how simple the implementation is.  The results of the configure step are saved and available for inspection by the user.  Conceivably, any number of sub-consoles could be easily added for other uses.

Comments?

/*******************************************************************************
 * Copyright (c) 2002, 2004 QNX Software Systems and others.
 * All rights reserved. This program and the accompanying materials
 * are made available under the terms of the Eclipse Public License v1.0
 * which accompanies this distribution, and is available at
 * http://www.eclipse.org/legal/epl-v10.html
 *
 * Contributors:
 * QNX Software Systems - Initial API and implementation
 *******************************************************************************/
package com.redhat.eclipse.cdt.autotools.internal.ui;

import org.eclipse.cdt.core.ConsoleOutputStream;
import org.eclipse.cdt.core.resources.IConsole;
import org.eclipse.cdt.ui.CUIPlugin;
import org.eclipse.cdt.ui.IBuildConsoleManager;
import org.eclipse.core.resources.IProject;
import org.eclipse.core.runtime.CoreException;

public class CConfigureConsole implements IConsole {
	IProject project;
	IBuildConsoleManager fConsoleManager;
	
	private static final String MENU_ID = "com.redhat.eclipse.cdt.autotools.configureConsole";  //$NON-NLS-1$
	private static final String CONTEXT_MENU_ID = "CAutotoolsConfigureConsole"; //$NON-NLS-1$
	
	public CConfigureConsole() {
		String consoleName = ConsoleMessages.getString("ConfigureConsole.configureConsole"); //$NON-NLS-1$
		fConsoleManager = CUIPlugin.getDefault().getSubConsoleManager(consoleName, 
				MENU_ID, CONTEXT_MENU_ID);
	}
	
//	/**
//	 * Constructor for ConfigureConsole.
//	 */
//	public CConfigureConsole() {
//		fConsoleManager = AutotoolsPlugin.getDefault().getConsoleManager();
//	}
//

	public void start(IProject project ) {
		this.project = project;
		fConsoleManager.getConsole(project).start(project);
	}
	
	/**
	 * @throws CoreException
	 * @see org.eclipse.cdt.core.resources.IConsole#getOutputStream()
	 */
	public ConsoleOutputStream getOutputStream() throws CoreException {
		return fConsoleManager.getConsole(project).getOutputStream();
	}

	public ConsoleOutputStream getInfoStream() throws CoreException {
		return fConsoleManager.getConsole(project).getInfoStream();
	}

	public ConsoleOutputStream getErrorStream() throws CoreException {
		return fConsoleManager.getConsole(project).getErrorStream();
	}
}
Comment 1 Jeff Johnston CLA 2006-08-14 15:31:40 EDT
Created attachment 47864 [details]
CDT UI patch to support secondary build consoles
Comment 2 Andrew Overholt CLA 2007-01-29 15:01:30 EST
Anyone have time to take a look at this?  We're trying to get the GNU Autotools project patch-clean (ie. no patches to the CDT itself).
Comment 3 Andrew Overholt CLA 2007-01-29 15:24:50 EST
Changing to 4.0.
Comment 4 Anton Leherbauer CLA 2007-01-30 05:12:36 EST
Could you update the patch based on current HEAD? It does not apply cleanly. 
Furthermore,
- it should be warning free (non-externalized strings, etc.)
- refactor the two almost identical BuildConsoleManager.startup methods
- a single id for menuId and contextMenuId should be sufficient (only the id to register the context menu is actually relevant)
- define a constant for the default contextMenuId and keep it the same as before (menu ids are API)
- the provided contextMenuId should be used as is (ie. without prefixing the cdt.ui plugin id)
- why "sub"console? there is no super console (only a default)
- add yourself to the contributors list in the copyright notice
Thanks!
Comment 5 Jeff Johnston CLA 2007-01-30 17:22:32 EST
Created attachment 57870 [details]
CDT UI patch to support multiple build consoles
Comment 6 Jeff Johnston CLA 2007-01-30 17:30:31 EST
(In reply to comment #4)
> Could you update the patch based on current HEAD? It does not apply cleanly. 
> Furthermore,
> - it should be warning free (non-externalized strings, etc.)
> - refactor the two almost identical BuildConsoleManager.startup methods
> - a single id for menuId and contextMenuId should be sufficient (only the id to
> register the context menu is actually relevant)
> - define a constant for the default contextMenuId and keep it the same as
> before (menu ids are API)
> - the provided contextMenuId should be used as is (ie. without prefixing the
> cdt.ui plugin id)
> - why "sub"console? there is no super console (only a default)
> - add yourself to the contributors list in the copyright notice
> Thanks!
> 


New patch created that applies to HEAD.  Tested on M4 with simple ManagedMake hello world project to verify console works fine.  The patch has been cleaned up (rewritten) significantly thanks to your excellent comments.  I preserved the old context menu id as requested (including spelling error for Conole instead of Console).  I re-commented it to be "multiple build console support" which is more appropriate and easier to understand.  The CUIPlugin just has one extra method for getting a console manager using a name and id.  The default getConsoleManager method is still around and calls the new method with appropriate defaults for name and id.

Let me know if there are any other problems.

Thanks.
Comment 7 Anton Leherbauer CLA 2007-01-31 05:16:28 EST
Thanks for the update, that's exactly what I had in mind.
I have applied the patch with 2 minor changes:
- renamed the context menu id constant to DEFAULT_CONTEXT_MENU_ID
- moved the resource string for the console name
Comment 8 Doug Schaefer CLA 2008-06-03 14:58:03 EDT
assigning
Comment 9 Doug Schaefer CLA 2008-06-03 14:58:33 EDT
done