Bug 520163 - C/C++ Scanner Discovery Problems cause headless build to fail
Summary: C/C++ Scanner Discovery Problems cause headless build to fail
Status: RESOLVED FIXED
Alias: None
Product: CDT
Classification: Tools
Component: cdt-build-managed (show other bugs)
Version: Next   Edit
Hardware: PC Linux
: P3 normal (vote)
Target Milestone: 9.4.0   Edit
Assignee: Jonah Graham CLA
QA Contact: Andrew Gvozdev CLA
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-07-25 11:38 EDT by Nobody - feel free to take it CLA
Modified: 2017-07-27 11:03 EDT (History)
2 users (show)

See Also:


Attachments
make_not_found_error_warning.png (142.15 KB, image/png)
2017-07-27 06:49 EDT, Jonah Graham CLA
no flags Details
disable_make_error_parser.png (103.45 KB, image/png)
2017-07-27 06:49 EDT, Jonah Graham CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Nobody - feel free to take it CLA 2017-07-25 11:38:34 EDT
My CDT project (a shared lib) have 4 configurations (ReleaseArm, DebugArm, ReleasePPC, DebugPPC).

In each configuration I set a relative path to the toolchain : ${WorkspaceDirPath}/xtool.
I work with 2 workspaces: one for ARM and one for PPC.

I need to build only ReleaseArm configuration on the command line. For that I use:

eclipse  --launcher.suppressErrors -nosplash \
 -application org.eclipse.cdt.managedbuilder.core.headlessbuild \
 -data ARMworkspacePath \
 -import ARMworkspacePath/myProject
 -cleanBuild myProjectName/ReleaseArm

the build success.
But eclipse do some check on the PPC configuration and failed (because the PPC xtools are not found).

Why eclipse do these check on unwanted configuration ?
How is it possible to disable these check ?

Thanks,
Fred


Here is the output:

Unable to find full path for "powerpc-e500mc-linux-gnu-gcc"
Unable to find full path for "powerpc-e500mc-linux-gnu-g++"
Unable to find full path for "powerpc-e500mc-linux-gnu-gcc"
Unable to find full path for "powerpc-e500mc-linux-gnu-g++"
16:37:28 **** Rebuild of configuration ReleaseArm for project myProjectName ****
Info: Internal Builder is used for build
arm-linux-gnueabihf-g++ -std=c++0x ...
...
Info: Parallel threads used: 4

16:37:30 Build Finished (took 1s.982ms)

Eclipse:
JVM terminated. Exit code=1
/usr/lib/jvm/java-8-oracle/jre/bin/java
-Dorg.eclipse.cdt.core.console=org.eclipse.cdt.core.systemConsole
-Dosgi.requiredJavaVersion=1.8
-XX:+UseG1GC
-XX:+UseStringDeduplication
-Dosgi.requiredJavaVersion=1.8
-Xms256m
-Xmx1024m
-Declipse.p2.max.threads=10
-Doomph.update.url=http://download.eclipse.org/oomph/updates/milestone/latest
-Doomph.redirection.index.redirection=index:/->http://git.eclipse.org/c/oomph/org.eclipse.oomph.git/plain/setups/
-jar /home/fred/Dev/Tools/eclipse/neon//plugins/org.eclipse.equinox.launcher_1.3.201.v20161025-1711.jar
-os linux
-ws gtk
-arch x86_64
-launcher /home/fred/Dev/Tools/eclipse/neon/eclipse
-name Eclipse
--launcher.library /home/fred/.p2/pool/plugins/org.eclipse.equinox.launcher.gtk.linux.x86_64_1.1.401.v20161122-1740/eclipse_1618.so
-startup /home/fred/Dev/Tools/eclipse/neon//plugins/org.eclipse.equinox.launcher_1.3.201.v20161025-1711.jar
--launcher.appendVmargs
-exitdata 1c6801a
-product org.eclipse.epp.package.cpp.product
-application org.eclipse.cdt.managedbuilder.core.headlessbuild
-data /home/fred/Dev/Sources/ARMworkspace
-build myProjectName/ReleaseArm
-vm /usr/lib/jvm/java-8-oracle/jre/bin/java
-vmargs
-Dorg.eclipse.cdt.core.console=org.eclipse.cdt.core.systemConsole
-Dosgi.requiredJavaVersion=1.8
-XX:+UseG1GC
-XX:+UseStringDeduplication
-Dosgi.requiredJavaVersion=1.8
-Xms256m
-Xmx1024m
-Declipse.p2.max.threads=10
-Doomph.update.url=http://download.eclipse.org/oomph/updates/milestone/latest
-Doomph.redirection.index.redirection=index:/->http://git.eclipse.org/c/oomph/org.eclipse.oomph.git/plain/setups/
-jar /home/vseusr/Dev/Tools/eclipse/neon//plugins/org.eclipse.equinox.launcher_1.3.201.v20161025-1711.jar
Comment 1 Jonah Graham CLA 2017-07-27 06:49:04 EDT
For historical reasons I don't fully know, the scanner is run against all configurations, hence your error markers, which in the IDE Problems view show up like this:

Type Error | Program "pathtogcc" not found in PATH

The way that this error is created is by running the string 'Error: (Program "pathtogcc" not found in PATH)' through the RegEx error parsers. The regex that picks this up is "GNU gmake Error Parser 7.0" with the regex of "Error:\s*(.*)".

I don't have a proper solution, but I can provide a workaround, depending on how you want to go about this.

1) Add a new regex that demotes this error pattern to a warning. (See make_not_found_error_warning.png attachment)
2) Disable the GNU gmake error parser in the project. Note that this will cause other make errors to not be seen. (See disable_make_error_parser.png)
Comment 2 Jonah Graham CLA 2017-07-27 06:49:30 EDT
Created attachment 269563 [details]
make_not_found_error_warning.png
Comment 3 Jonah Graham CLA 2017-07-27 06:49:48 EDT
Created attachment 269564 [details]
disable_make_error_parser.png
Comment 4 Jonah Graham CLA 2017-07-27 06:58:20 EDT
(In reply to Jonah Graham from comment #1)
> 2) Disable the GNU gmake error parser in the project. Note that this will
> cause other make errors to not be seen. (See disable_make_error_parser.png)
Scratch Option 2, that doesn't work.

AbstractBuiltinSpecsDetector.runForLanguage(IProgressMonitor) has this bit of code that forces the GMake error parser to be used.

// Using GMAKE_ERROR_PARSER_ID as it can handle generated error messages
ErrorParserManager epm = new ErrorParserManager(currentProject, buildDirURI, markerGenerator, new String[] {GMAKE_ERROR_PARSER_ID});
Comment 5 Jonah Graham CLA 2017-07-27 07:03:41 EDT
(Update summary)

Because the projects contain scanner discovery problems, the build is marked in error.

Permanent solutions to this could be:
1) Don't run scanner at all during headless build -- this only applies on newly imported projects as projects that exist already when headless build is started will already have the error markers
2) Exclude scanner problems (ones with marker types org.eclipse.cdt.managedbuilder.core.scanner.discovery.problem) from counting build as an error (this would probably be under a new command line argument, similar to -no-indexer which itself should probably be default)
Comment 6 Eclipse Genie CLA 2017-07-27 08:07:42 EDT
New Gerrit change created: https://git.eclipse.org/r/102077
Comment 7 Jonah Graham CLA 2017-07-27 08:11:26 EDT
(In reply to Eclipse Genie from comment #6)
> New Gerrit change created: https://git.eclipse.org/r/102077

With this change, you can add the following command line argument:

  -marker-type cdt

to only have C/C++ Problems cause build to fail. Additionally, you can add 

  -printErrorMarkers

to display all error markers that caused build to fail. If you were to run the original example in Comment 0 with -printErrorMarkers you would get output like:

    Headless build encountered errors
    Marker [on: /cmdline, id: 360, type: org.eclipse.cdt.managedbuilder.core.scanner.discovery.problem, attributes: [location: Project Properties, C++ Preprocessor Include.../Providers, [CDT GCC Built-in Compiler Settings] options, message: Program "xtool3/g++" not found in PATH, provider: org.eclipse.cdt.managedbuilder.core.GCCBuiltinSpecsDetector, severity: 2], created: 27/07/17 13:01]
Comment 9 Jonah Graham CLA 2017-07-27 08:50:32 EDT
Hi Fred, Can you test out the nightly CDT with this fix to see if it resolves your issues (without needing my previously provided workarounds)?

http://download.eclipse.org/tools/cdt/builds/master/nightly - the build should be ready in a few hours

---

Info added to N&N https://wiki.eclipse.org/CDT/User/NewIn94#Build
Comment 10 Eclipse Genie CLA 2017-07-27 08:53:41 EDT
New Gerrit change created: https://git.eclipse.org/r/102083
Comment 11 Jonah Graham CLA 2017-07-27 08:54:44 EDT
(In reply to Eclipse Genie from comment #10)
> New Gerrit change created: https://git.eclipse.org/r/102083

When writing N&N I realized that command line styles were inconsistent. Changed -marker-type to -markerType