Community
Participate
Working Groups
Build Identifier: M20100909-0800 Stack overflow due to infinite recursion when setting artifact name to anything with ${PWD} variable. Steps to reproduce: 1.Create Hello World project 2.Open Project > Properties > C/C++ Build > Settings 3.Select "Build Artifact" tab and at "Artifact Name" field type ${PWD}/MyApp or simply ${PWD}. 4.Press OK, observe the "Internal Error - java.lang.StackOverflowError" window pops up. The reason why this variable (and ${CWD}) is handled differently than others lies in MBSEnvironamentVariableSupplier.getConfigurationVariable(String name, IConfiguration configuration) that has a special case for it: if("CWD".equals(name) || "PWD".equals(name)). This IF statement causes the infinite recursion to start. It calls to ManagedBuildManager.getBuildLocation(), which in turn calls to GnuMakefileGenerator.initialize(), which tries again to resolve all macros/variables and it becomes a loop. Reproducible: Always
The rather simple Builder.getDefaultBuildPath() seems like an overkill. Specifically, it fully initializes the makefile generator (which causes the recursion) although the caller doesn't need the generator except for the path. There is no existing API method to replace initialization. So the API either needs be extended or the recursion stopped inside IManagedBuilderMakefileGenerator2.initialize(). But that means that custom generators will still fall into the same trap. This way or another, custom generators will require a change. Any opinions?
Both ManagedBuildManager.getBuildLocation() and Builder.getBuildPath() are called very frequently and fully initialize the makefile generator. This is a bad idea and leads to recursion. There should be a utility method for this purpose. The IManagedBuilderMakefileGenerator2 API should be extended with a new method that receives configuration and returns the build working directory. E.g. IPath getBuildWorkingDirForConfiguration(IConfiguration cfg). This resolves the recursion and improves performance.
Created attachment 185496 [details] Patch with the above suggestion
