Community
Participate
Working Groups
Created attachment 167750 [details] Zip containing autotools project: hello and simple Makefile project: makefile An Autotools project which is a form of a Makefile project has a build definition which specifies false for supportsManagedBuild. The CommonBuilder is used to perform the make portion of the build. When the project is initially created, a source file will have unknown header files shown in the C/C++ editor. This is expected. After building, the header files will be resolved and can be opened via the Outline View. There are two problems. 1. If the workspace is closed and reopened, the header file resolution is lost and the file in the editor will show the header files are unknown until the next build. 2. There appears to be no indexing performed automatically. Manually forcing a rebuild of the index does work. Again, this information is lost across a workspace close/reopen. The behaviour above does not occur for a ManagedBuild project. Creating a vanilla Makefile C project and adding a simple Makefile plus source (i.e. non-autotools) results in no header file resolution, even after building is successful. I do not know if the current Makefile project is the old format or uses the CommonBuilder and is closer to an Autotools project definition. If not, then a separate bug should be opened. I will attach the Autotools core plugin.xml for the relevant build definition. I will also attach a zip file containing the Autotools and simple Makefile projects used for testing.
Created attachment 167751 [details] plugin.xml file for Autotools core which contains Autotools project build definition Added plugin.xml for autotools core plugin.
(In reply to comment #1) > Created an attachment (id=167751) [details] > plugin.xml file for Autotools core which contains Autotools project build > definition > > Added plugin.xml for autotools core plugin. Update. Indexer seems to be working today for some reason. I can F3 on a C library function and it finds it in the glibc header file correctly. Interestingly enough, it still can't find the header files after close/restart of the workspace but finding the function definition does work (i.e F3 works for puts - a function in stdio.h, but it claims not to know about stdio.h in the outline view).
Update for RC2 using the Helios RC2 Package from: http://www.eclipse.org/downloads/download.php?file=/technology/epp/downloads/release/helios/RC2/eclipse-linuxtools-helios-RC2-incubation-linux-gtk.tar.gz If I create a C Project -> GNU Autotools Project -> ANSI Hello World the project will build and the headers are resolved. If one closes the project and reopens it, the headers are marked with warnings even though the indexer works fine on the various C functions used within. Building the project, cleaning the project again does not seem to remove the warnings from the header files. Where is the ScannerDiscovery info going and why isn't it being recalculated?
I may have a fix in the pipe. Try the lastest hudson build (>= 193) and see if it fixes your problem too.
Is this still an issue?
(In reply to comment #5) > Is this still an issue? Yes. Closing the project and reopening results in the headers being denoted as not found. The problem can be cleared by rebuilding. The ScannerDiscovery info does not appear to be saved across sessions.
(In reply to comment #6) > (In reply to comment #5) > > Is this still an issue? > > Yes. Closing the project and reopening results in the headers being denoted as > not found. The problem can be cleared by rebuilding. > > The ScannerDiscovery info does not appear to be saved across sessions. Yup, I've seen that too. But the scanner info is saved. It just doesn't get loaded by the project model properly. The odd thing is that my Android projects are getting loaded correctly. But when I create a C++ project with the same toolchain, it doesn't. The bizarreness continues. I'll take a look at this after my vacation and see if I can fix it for 7.0.1. For 8.0, I'd like to hook up the project model directly to the scanner discovery data which I do know is getting persisted properly.
(In reply to comment #6) > (In reply to comment #5) > > Is this still an issue? > > Yes. Closing the project and reopening results in the headers being denoted as > not found. The problem can be cleared by rebuilding. > > The ScannerDiscovery info does not appear to be saved across sessions. Thanks, reassigning to core.
*** Bug 327024 has been marked as a duplicate of this bug. ***
*** Bug 330564 has been marked as a duplicate of this bug. ***
I have made a fix to the Autotools Wizard to get around this issue. The Autotools build definition includes gcc and g++ compilers in the Autotools toolchain which superclass the gnu gcc compiler and gnu g++ compiler respectively. In project creation, the project description gets set and this eventually kicks off a check of the compiler optimization level of the gcc compiler tool. This option has a default value that changes based on the build type and this causes an option set to occur which triggers a notification which causes a call to getCLanguageDatas(). This in turn gets an instance of the gcc compiler input type with calculated id. Later in this cycle of setting the project description, a call to createMap() for the CfgScannerConfigInfoFactory2 class looks at each tool in the toolchain and creates a context only if the input type is not an extension (i.e. has an calculated id). The save() method of CfgScannerConfigInfoFactory2 is then called which checks the map to see if the scannerBuildInfo should be saved to the .cproject file. For ManagedBuild projects, this works because of the getCLanguageDatas() call such that by the time the call to save() in the CfgScannerConfigInfoFactory2 call occurs, there is an item in the map such that creation of a scannerBuildInfo entry occurs in the .cproject file. For Autotools, the set of the options does not occur and so we don't trigger the notification. This is due to the fact that the options holders do not equal the holders (tools) passed into the propertiesChanged() calls for the tools so the setOption does not occur. My guess is that has to do with the fact that the toolchain is inheriting these options by way of the superclassed gnu gcc tool. By the time the save logic gets invoked for Autotools, there is no context info created as the input type for the gcc compiler tool is still an extension and so no save occurs. After this, Autotools does end up getting the C Language datas, but it is too late because nothing calls the Scanner Config Info Factory to save it. The dirty flag may not even be set at this point. The fix is to override the createProject() method of the Wizard handler and add some logic following the super.createProject() which essentially resets the project description back again. By this time the input types are set and the Scanner Build info gets written to the .cproject file. This code is just emulating what occurs when the C/C++ Discovery Tab is opened and the OK button is pressed. Pressing the OK button is a workaround for older projects where this is occurring as this causes the Scanner build info to be written to the .cproject file and subsequent restarts of Eclipse work fine from then on.
You've made a workaround for Autotools but the issue is still there for Makefile projects as evidenced by duplicate bugs. Let me reopen the bug. Thanks for the detailed description.
