Community
Participate
Working Groups
As far as I understand, the .cproject file has taken over the position of .cdtbuild. However, ManagedBuildManager.SETTINGS_FILE_NAME is still pointing to .cdtbuild. This is causing a number of NPEs. For example, ManagedBuildManager.canLoadBuildInfo throws a null pointer exception, because "file.getLocation()" is null in the following: private static boolean canLoadBuildInfo(final IProject project) { IFile file = project.getFile(SETTINGS_FILE_NAME); if (file == null) return false; File cdtbuild = file.getLocation().toFile(); if (cdtbuild == null) return false; return cdtbuild.exists(); } Either the ManagedBuildManager.SETTINGS_FILE_NAME constant has to be changed or all the code that references this constant should be updated.
The constant is used by the project conversion mechanism to update build settings from old projects, so we can't remove it. The method you mention does need to change though.
Er, I meant change, not remove.
Ok I'm confused... From what I can tell, canLoadBuildInfo() is only called in one place, by ManagedBuildManager.canFindBuildInfo(), and even then if it's an older project that has been converted. So as far as I know, this is doing what it's supposed to. Were you using an old project at the time? If so, did the .cdtbuild file get deleted? Or is this a new project created with CDT 6.0?
Does this mean public APIs that make a reference to this constant are deprecated? (Example: ManagedBuildManager.canGetBuildInfo(IResource)). 'canGetBuildInfo' doesn't seem to be deprecated in its javadoc. We make references to these APIs in our code and when I upgraded my CDT plug-ins, I started getting NPEs. Is there another method that should be used in place of this method? Thanks!
(In reply to comment #4) > Does this mean public APIs that make a reference to this constant are > deprecated? (Example: ManagedBuildManager.canGetBuildInfo(IResource)). > 'canGetBuildInfo' doesn't seem to be deprecated in its javadoc. > We make references to these APIs in our code and when I upgraded my CDT > plug-ins, I started getting NPEs. > Is there another method that should be used in place of this method? > Thanks! "Deprecated" is not quite the right word. They are there for backwards compatibility. So they're not deprecated in the sense of "don't reference them at all", but they don't reflect current functionality. Unfortunately I don't see a way to get at this from public API, but ICProjectDescriptionStorageType.STORAGE_FILE_NAME is what you want I think.
James (and others), do you think it's valid to want a public way to get at ICProjectDescriptionStorageType.STORAGE_FILE_NAME? Or should we continue to intentionally hide this as internal? I would think in general that it ought to be hidden, as reads and writes to the storage should happen via API calls. However, maybe for project conversion we might need to check if the file exists? Even then I would think we should be doing all that in the internals.
Created attachment 138053 [details] Simple patch (In reply to comment #4) > Does this mean public APIs that make a reference to this constant are > deprecated? (Example: ManagedBuildManager.canGetBuildInfo(IResource)). > 'canGetBuildInfo' doesn't seem to be deprecated in its javadoc. canGetBuildInfo resorts to this only if the build information isn't loaded, and you're right, it's the wrong thing to do. > We make references to these APIs in our code and when I upgraded my CDT > plug-ins, I started getting NPEs. Which other APIs? That seems to be the only method (having had a quick look at the call-hierarchy for SETTINGS_FILE_NAME). I guess there are a couple of issues. AFAICS the API doesn't contain a way to get at this information. The project description is loaded and the build system is called back to load it's data. The build system's data is opaque to the project description. There's no way for cdt.core / the build-system to know if there's data to load without actually trying to load it. See #getBuildInfo(IProject): This (effectively) does: getLoadedBuildInfo() == null ? getProjectDescription(...) return getLoadedBuildInfo() So by my reckoning you can replace canGetBuildInfo(IProject) with getBuildInfo(IProject, true) != null (In reply to comment #6) > James (and others), do you think it's valid to want a public way to get at > ICProjectDescriptionStorageType.STORAGE_FILE_NAME? Or should we continue to > intentionally hide this as internal? I would think in general that it ought to > be hidden, as reads and writes to the storage should happen via API calls. > However, maybe for project conversion we might need to check if the file > exists? Even then I would think we should be doing all that in the internals. I agree. I think the storage should be considered and these variables should be internal / deprecated / marked don't use... The project's storage should be considered opaque as it might live anywhere. That said there may be a need to discover if a project has managed build enabled on it. Note that testing for the existence of a file isn't sufficient to prove this... Perhaps this flag could be cached in the IResource metadata. However given that we load and hang onto build configuration as soon as the project is loaded, the whole area of loading / storing seems to be in need of a revamp :)
