基于eclipse嵌入式开发平台整合方案

balancesli写著 '基于eclipse嵌入式开发整合方案

author : balancesli email : balancesli@thizlinux.com.cn

目的：

为进行嵌入式linux产品开发整个过程提供一个高效的开发平台。

为产品最终提供的用户在“开发支持平台上”提供最大的支持。

技术难点：

Host端操作系统的选取linux, windows, cygwin

开发平台地选取，

2.1 是否支持CVS版本控制 2.2 界面交互是否友好(图形化的编辑界面) 2.3 开发套件是否可以支持多种目标机系统(x86, MIPS, PowerPC, ARM, StrongARM, Xscal等). 2.4 平台是否提供基于(C/C++), 的编译、调试、交叉编译调试环境, 目标码生成的大小及其执行效率考察. 2.5. 开发平台的无关性支持

解决方案：（解决技术路线和具体方案）

由以上评估决定采用基于Eclipse开放的工作平台.

由于Eclipse IDE平台的开放性及其友好的交互界面, 可以很好的以插件的方式植根于Eclipse作为软件开发平台.

充分利用Eclipse的CVS版本控制接口提供基于CVS的版本控制和资源配置管理.

3. 采用CDT(C/C++ Devekopment Toolkit), 并以GCC, GDB为编译调试引擎, Project化的程序管理开发. (CDT本身作为一个Eclipse平台插件, 它提供了非常高效的编辑环境, 完全可以作为嵌入式开发的一个RAD工具, 大幅度提高了开发效率) Note : CDT开发环境最好采用Linux系统平台

4. CDT 依赖于三个 GNU 工具链：GCC、GDB 和 Make或相关的支持交叉编译的工具。

CDT支持自动生成Makefile和标准Makefile NOTE : 分析CDT源码, 是否可以通过其内部的改造来完成一些特定的需求. 难度在于Java代码的熟悉程度和分析.

最终CDT解决方案模型:

UI(用户接口)

Makefile generator(Makefile 生成器 ) 它为Project工程中每个子目录生成对应的Makefile

CDT Elf Parser(二进制解析器)

Tool Integrator(GNU工具链集成器)

工具链配置管理模型图(Build Model schema)

Managed build system Overview 通过以上的模型可以很好的定制7型PDA开发平台ToolChain的整合.

注意在安装CDT插件后，Welcome.xml 中已经有了一个很明显的阐述 The CDT project provides a set of plugins that implement a C/C++ IDE. It adds a C/C++ Perspective to the Eclipse Workbench that supports C/C++ development with a number of views, wizards, a powerful editor, and a debugger. The CDT is designed to provide an extensible architecture, that will provide support for integration of tools provided by Independent Software Vendors. 提供了一个非常灵活的体系。。 Build Model Grammar Elements relation schema 如下: ManagedBuildInfo

: 由以上模型图: 可以完全的推断出CDT的ToolChain管理的设计思想. Design idea is very important!

猜想在CDT中的这些ToolChain的配置管理信息最终交给MakefileGenerator来生成对应的Makefile文件, 再由Make工具完成编译. 这里我们就可以很好过渡到 org.eclipse.cdt.make.core org.eclipse.cdt.make.ui 这两个包是如和操纵Make工具的了???

在Source中与其对应的类模型如下: Class Target Class Configure Class Tool Class ToolReference Class Option Class OptionCategory >>>>>>> 通过阅读源代码

源代码特点 :以C开头的是类定义(class),以I开头的是接口定义(interface) 但从源代码的组织上看大部分的功能定义一般先封装到一个接口定义里，如: Ixxxxxx 其次由一个对应的类来实现其所定义的接口内方法. Cxxxxxx Cxxxxxx Ixxxxxx 至于包关系只要从各个插件的名称就可以明白！！！在Java language 中每个类对应一个文件, 每个接口对应一个文件类关系以下为 org.eclipse.cdt.managedbuilder.Core org.eclipse.cdt.managedbuilder.ui 两个 public class BuildObject implements IBuildObject public class Configuration extends BuildObject implements IConfiguration public class Option extends BuildObject implements IOption public class OptionCategory extends BuildObject implements IOptionCategory public class Target extends BuildObject implements ITarget public class Tool extends BuildObject implements ITool, IOptionCategory class Buildobject ====>> class Configuration class Option class OptionCategory class Target class Tool 接口关系 public interface IBuildObject public interface IConfiguration extends IBuildObject public interface IOption extends IBuildObject public interface IOptionCategory extends IBuildObject public interface ITarget extends IBuildObject public interface ITool extends IBuildObject interface Buildobject ====>> interface Configuration interface Option interface OptionCategory interface Target interface Tool 杂项 public class ManagedBuilderCorePlugin extends Plugin public class ToolReference implements ITool public class OptionReference implements IOption public class BuildException extends Exception 异常类 public interface IManagedBuildInfo ManagedBuildInfo.java (cdtsrcorg.eclipse.cdt.managedbuilder.coreinternalcore) public class ManagedBuildInfo implements IManagedBuildInfo, IScannerInfo

ManagedBuildInfo //标准工程standard C project public class MakefileGenerator public class ManagedCProjectNature implements IProjectNature MakeProjectNature.java (cdtsrcorg.eclipse.cdt.make.corecore) public class MakeProjectNature implements IProjectNature //可管理Make工程Managed C project ManagedCProjectNature.java (cdtsrcorg.eclipse.cdt.managedbuilder.corecore) public class ManagedCProjectNature implements IProjectNature CProjectNature.java (cdtsrcorg.eclipse.cdt.corecore) public class CProjectNature implements IProjectNature public class ManagedBuilderUIImages public interface ManagedBuilderHelpContextIds public class ManagedBuilderUIPlugin extends Plugin public class GeneratedMakefileBuilder extends ACBuilder public class ManagedBuildManager extends AbstractCExtension implements IScannerInfoProvider ======================================================================= TabFolderOptionBlock.java (cdtsrcorg.eclipse.cdt.uiuidialogs) public abstract class TabFolderOptionBlock MakeProjectOptionBlock.java (cdtsrcorg.eclipse.cdt.make.uiinternalui) public class MakeProjectOptionBlock extends TabFolderOptionBlock ManagedProjectOptionBlock.java (cdtsrcorg.eclipse.cdt.managedbuilder.uiinternalui) public class ManagedProjectOptionBlock extends TabFolderOptionBlock ++++++++++++++++++++++++++++++++++++++ 另外一个包的 IMarkerGenerator.java (cdtsrcorg.eclipse.cdt.corecore) public interface IMarkerGenerator ？？？ public abstract class ACBuilder extends IncrementalProjectBuilder implements IMarkerGenerator ACBuilder.java (cdtsrcorg.eclipse.cdt.corecore esources) public abstract class ACBuilder extends IncrementalProjectBuilder implements IMarkerGenerator 由以上可以断定其设计思想还是以Plugin.xml配置文件中所包含的节点元素(Node Element)抽象出一个BuildObject类模型暂且认为构件模型抽象类吧！！！

public interface IbuildObject { // Schema element names public static final String ID = "id"; public static final String NAME = "name";

public String getId(); public String getName(); } 大多与ToolChain管理配置的UI的交互界面都是调用SWT, JFace来实现这样一来就可以定制特定的ToolChain到CDT的Build Model 这里的Build Model与其对应的Plugin.xml配置文件的DOM节点模型都有很形象的对应在阅读源代码的过程中是否可以通过包所对应的Plugin.xml配置文件来推出每个插件内的总体设计模型? ? ? ? ?.?

org.eclipse.cdt.make.core包分析: ???class MakefileCodeScanner Makefile代码扫描器 after read source, 一个Makefile文件包含一些规则(rule), 宏定义(macro definition), 再就是注释(Comment) 他们都被统称为指示符(directive), 简单的说每种指示符用于说明一个元素它归属于什么角色. 这样可以对Makefile元素的进行一下大致的抽象划分. Public interface IDirective {

} public abstract class Directive implements IDirective public interface Directive ==?

1. public interface ICommand extends IDirective public class Command extends Directive implements ICommand 2. public interface IComment extends IDirective public class Comment extends Directive implements IComment

3.public interface IConditional extends IDirective public abstract class Conditional extends Parent implements Iconditional { public class Else extends Conditional public class Ifdef extends Conditional public class Ifeq extends Conditional public class Ifndef extends Conditional public class Ifneq extends Conditional } 4.public interface IEmptyLine extends IDirective public class EmptyLine extends Directive implements IEmptyLine

interface IMacroDefinition extends IDirective { public class MacroDefinition extends Directive implements IMacroDefinition public interface IVariableDefinition extends ImacroDefinition public class VariableDefinition extends MacroDefinition implements IvariableDefinition

public class DefineVariable extends VariableDefinition public class OverrideDefine extends DefineVariable public class ExportVariable extends VariableDefinition public class OverrideVariable extends VariableDefinition public class TargetVariable extends VariableDefinition }

6.public interface IParent extends IDirective public abstract class Parent extends Directive implements IParent public interface IInclude extends IParent public class Include extends Parent implements Iinclude

public interface IMakefile extends Iparent { public abstract class AbstractMakefile extends Parent implements IMakefile :public abstract class AbstractMakefile extends Parent implements IMakefile public class GNUMakefile extends AbstractMakefile implements IGNUMakefile public class NullMakefile extends AbstractMakefile public class PosixMakefile extends AbstractMakefile public interface IGNUMakefile extends IMakefile } 7.public interface IRule extends Iparent public interface IInferenceRule extends IRule public class StaticTargetRule extends InferenceRule implements IInferenceRule

public interface ISpecialRule extends IRule { public abstract class SpecialRule extends Rule implements ISpecialRule

public interface IDefaultRule extends IspecialRule public class DefaultRule extends SpecialRule implements IdefaultRule

public interface IDeleteOnErrorRule extends IspecialRule public class DeleteOnErrorRule extends SpecialRule implements IdeleteOnErrorRule

public interface IExportAllVariablesRule extends ISpecialRule public class ExportAllVariablesRule extends SpecialRule implements IexportAllVariablesRule

public interface IIgnoreRule extends ISpecialRule public class IgnoreRule extends SpecialRule implements IignoreRule

public interface IIntermediateRule extends ISpecialRule public class IntermediateRule extends SpecialRule implements IintermediateRule

public interface ILowResolutionTimeRule extends IspecialRule public class LowResolutionTimeRule extends SpecialRule implements ILowResolutionTimeRule //ITargetRule | IInferenceRule | IspecialRule

public interface INotParallelRule extends ISpecialRule public class NotParallelRule extends SpecialRule implements INotParallelRule

public interface IPhonyRule extends IspecialRule public class PhonyRule extends SpecialRule implements IphonyRule

public interface IPosixRule extends IspecialRule public class PosixRule extends SpecialRule implements IposixRule

public interface IPreciousRule extends ISpecialRule public class PreciousRule extends SpecialRule implements IpreciousRule

public interface ISccsGetRule extends IspecialRule public class SccsGetRule extends SpecialRule implements IsccsGetRule

public interface ISecondaryRule extends IspecialRule public class SecondaryRule extends SpecialRule implements IsecondaryRule

public interface ISilentRule extends IspecialRule public class SilentRule extends SpecialRule implements IsilentRule

public interface ISuffixesRule extends IspecialRule public class SuffixesRule extends SpecialRule implements ISuffixesRule } es public interface ITargetRule extends IRule public class TargetRule extends Rule implements ITargetRule public class GNUTargetRule extends TargetRule

8.public interface ITerminal extends IDirective public interface IVPath extends IDirective

总之通过以上分析Eclipse 的CDT插件, 完全证明CDT提供了一个非常灵活，而又易扩展的toolchain管理体系，这样一来是完全可以通过以上提供的方案对其进行改造使其支持交叉编译生成基于特定体系CPU的Code.