For my project, I call cmake for a third party library that I include statically from a custom make task (using automake), which results in the parser changing directory to the third party library; however it does not change back to the previous directory. 

Basic issue is that the parser uses the last 'Entering Directory' line to set paths, ignoring any 'Leaving Directory' lines.

I was able to get around the issue by building the third party library as a separate step, then checking for its existence and not re-building if it is present so when the main build happens then the directory is not changed.

When running the gcc tool using an out of source build, I received several errors (java.nio.file.NoSuchFileException) with incorrect paths listed.

 -- 

I found that the parser should be using the GNU Make lines that begin with `make[] Entering directory` to resolve paths (JENKINS-54035). 

 -- 

It looks like the responsibility for this is currently in src/main/java/edu/hm/hafner/analysis/LookaheadParser.java.

 -- 

I did test the regex ".make(?:
[
d+])?: " + ENTERING_DIRECTORY + " [`'](?<dir>.)['`]" and it worked for my output.

 -- 

I don't use Java very often and I don't have time at work to confirm this, however I believe the issue may be with the extractAndStoreDirectory function. The IssueBuilder parameter is marked as final, and a quick search suggests that when the build.SetDirectory call is made the final specification makes the change local to the function and thus does not carry forward to the Gcc4CompilerParser.java createIssue function.