I create a CDT eclipse plugin with specific build configuration. I use the setBuildCommand()
and setBuildArguments()
functions which call to a batch file.
My current code is:
ICProjectDescriptionManager mngr = CoreModel.getDefault().getProjectDescriptionManager();
ICProjectDescription des = mngr.createProjectDescription(project, false);
ManagedProject mProj = new ManagedProject(des);
Configuration cfg = new Configuration(mProj, null, "my.configuration.id", "MyConfiguration");
cfg.setBuildCommand("script.bat");
cfg.setBuildArguments(arg1 + " " + arg2);
I would like to get a return code from that batch file but I can't find a way to get it.
Any idea? Maybe you know how to add a marker to the project which will hold the information?
correct me if I'm wrong, but programatically creating a CProject definition is bad mojo. My answer will then be with using the 'standard' plugin.xml + Activator model (like when you make a new plugin project from template).
I think you're looking for an IErrorParser, which can parse the output from your BAT file.
MyExErrorParser.java
import org.eclipse.cdt.core.*
import org.eclipse.core.resources.*;
public class MyExErrorParser implements IErrorParser {
public MyExErrorParser() {
}
@Override
public boolean processLine(String line, ErrorParserManager eoParser) {
IProject p = ResourcesPlugin.getWorkspace().getRoot()
.getProject("hello_world");
p.getFile("main.c");
if(line.contains("my_error_id_str")) {
int err_lvl = IMarkerGenerator.SEVERITY_ERROR_RESOURCE;
ProblemMarkerInfo marker = new ProblemMarkerInfo(p , 5, "bad",
err_lvl,
"foo");
eoParser.addProblemMarker(marker);
return true;
}
return false;
}
}
Ideal
when 'processLine()' gets called, you have the opportunity to check the environment var %ERRORLEVEL% (or $? in linux)
I can't for the life of me figure out how to get the *currentBuilder.*Environment() map which you would use to check that. But your var should be there
I am guess the Environment() path is a monsterous rat-hole of time to try to figure out. XXX
Proposed
Supplemental
Here is a toolchain that exercises the above code. This example calls a shell script as its build command, with no arguments. I think this may be more of what you're ultimately after? Either way, it will be many times over easier to extend/maintain then the programmatic-implementation you used.
<?xml version="1.0" encoding="UTF-8"?>
<?eclipse version="3.4"?>
<plugin>
<extension
point="org.eclipse.cdt.managedbuilder.core.buildDefinitions">
<projectType
buildArtefactType="org.eclipse.cdt.build.core.buildArtefactType.exe"
id="Toolchain.projectType1"
isAbstract="false"
name="Justin">
<configuration
artifactExtension="o"
buildArtefactType="org.eclipse.cdt.build.core.buildArtefactType.exe"
cleanCommand="rm -rf"
id="Toolchain.configuration1"
name="Debug">
<toolChain
errorParsers="exErrorParser"
id="Toolchain.toolChain1"
isAbstract="false"
name="Example Toolchain"
supportsManagedBuild="true"
targetTool="Toolchain.tool1">
<builder
command="make"
errorParsers="exErrorParser"
id="Toolchain.builder1"
isAbstract="false"
isVariableCaseSensitive="false"
name="Builder">
</builder>
<tool
command="/home/jmreina/example.sh
commandLinePattern="${COMMAND}"
errorParsers="exErrorParser"
id="Toolchain.tool1"
isAbstract="false"
name="Example Tool">
<inputType id="Toolchain.inputType1" multipleOfType="false" primaryInput="true" sources="c"></inputType>
<outputType id="Toolchain.outputType1" outputs="txt" primaryOutput="true"></outputType>
</tool>
</toolChain>
</configuration>
</projectType>
</extension>
<extension
id="id1"
name="name"
point="org.eclipse.cdt.core.ErrorParser">
<errorparser
class="MyExErrorParser"
id="exErrorParser"
name="MyExParserName">
</errorparser>
</extension>
</plugin>