No, it is the working directory for the builder for the given project item. Technically, this is not necessarily the directory from which the builder will actually invoke the compiler (the build system could do some lookup, change directories, and run the compiler from there; e.g. recursive make setups could do something like that in theory). To get a better directory, it may be possible to add another method to the IBuildSystemManager like parserDirectory(ProjectBaseItem*) to allow the build system manager to give even more accurate information (to distinguish between the directory the builder is invoked and the directory in which the parser / compiler is invoked).

That being said, the current cwd of the parser is the cwd of the kdevelop process (which is essentially random, so fixing this shouldn't break anything, unless someone is relying on the directory from which they launch kdevelop having an effect on how the parser resolves relative paths). Also, even the custommake plugin seems to try to make this sort of thing work as well as it can. However this does immediately fix an issue I am having, points out the need for this sort of information, and adds the framework for providing it.

That being said, maybe that means this should be called the parseDirectory instead of build(er)Directory.