This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Implement a cache in which module could store derived dependencies. I am filing a feature request in core/compiler since this is the most relevant component, but the feature should most likely be imlemented by a separate module. Here are high-level requirement: 1. Dependency Cache will be a storage for derived dependencies. It will provide an API for defining, removing and querying dependencies. The cache will provide API to store dependencies between files. Modules will be able to extend this API to define more fine-grained dependencies. 2. The contents of Dependency Cache will be persisted in the IDE (in userdir or in project), without possibility to share this cache between users (no VCS support). 3. Individual modules will be responsible for analyzing sources and identifying dependencies. The modules will then store dependencies in the cache. 4. There will be no implicit connection between dependency cache and Compilers API, modules will have to retrieve information from the cache and use it to define compilation steps via Compilers API.
work on design specification started
first draft of API design is available at: http://core.netbeans.org/proposals/dependencies/index.html
Removed from 3.4 plan. There was only one external dependency on this requirement from gordonp@netbeans.org, Gordon agreed that he does not need this features in 3.4.
Created attachment 6067 [details] Dependency cache - prototype module
Moving to projects module. Chris will design this in accordance with the project's dependency system. Assigning Priority 3, it is a should-have feature for milestone 3.
We will not be able to complete this feature in PROJECTS_MILESTONE_3. The implementation team decided to remove it from the milestone (it's a P3).
These issues are planned as Sun's "must have" contribution to NetBeans 4.0 and are considered to be "high level" issues. That is why changing the type to FEATURE and priority to P1.
Yardo, this issue is NOT planned as a must-have feature for 4.0. It was originally requested by users Gordon and Michael and it was planned for M3. But after we integrated javamake in 3.4 and after Chris has designed the new projects build API this feature was downgraded to P3. Chris asked all the parties if we can remove it from the list of planned features and nobody objected. So I am setting the Priority of this issue back to P3 and the Target Milestone to TDB and I will remove it from our plan.xml. If anybody disagrees, speak up and we can discuss this.
There have been several proposals for general dependency managers (http://core.netbeans.org/proposals/dependencies/index.html and http://projects.netbeans.org/ps/Dependencies.html). I am interested in obtaining specific information about this feature from interested users and to determine if the proposed usages (require a general model and should be implemented by MDR). Specifically, I am interested in answers to the following questions: 1. How and where this feature be used (specific use cases)? What is the expected number of dependencies to be stored? 2. Is the general dependency feature a limited implementation of a language specific meta-model? Are/will/should the derived dependencies be expressed in a language model anyway (MDR will handle queries)? 3. Will some specific requirements be satisfied by the build dependency proposal http://projects.netbeans.org/proposals/buildusedependencies/BuildUseProposal.html ? 4. How is this type of dependency currently implemented in NB 3.4 or FFJ 4.0? Will this feature be used if implemented?
Here's the use-case for cpp. (1) It will be used to store dependencies on headerfiles by source files. Anytime a line of the form #include "X.h" appears in Y.c, we have a dependency from Y to X. Whenever X.h changes, Y.c has to be recompiled. The number of dependencies to be stored is typically 20 per file (I derived this by counting the number of #include lines in a C library directory and dividing by the number of source files; typically we can ignore dependencies on system headerfiles (/usr/include) so the number is slightly smaller. But for a real project this means the number of dependencies can run in the thousands. 2. I'm not sure about the meta model question, but at least in the near term we won't have a meta model for C++, C, or Fortran. 3. I don't think so - unless we pre-create some targets like "build all source files when any header file changes", but that probably won't work anything but small projects (if changing one headerfile causes massive unnecessary recompilation (compiling C++ can be slow because of templates and native code generation & optimization) people will stop using it.) I'm going to study the doc in more detail to see if I missed something. 4. FFJ currently doesn't do C++ projects builds; it relies on the user's makefiles, where dependencies are computed either by explicitly being listed, or some filter rule, or using Sun's KEEP_STATE feature where dependencies are recorded in a side-door file.
There are several possible solutions to this problem: 1. A module will use MDR to define a model describing dependency information. The MDR provides facilities to define arbitrarily complex models and provides optimized persistence facilities. More difficult for module writers, but provides more flexibility 2. Provide a simple settings persistence model which provides a setting to store dependent objects. The query interface would return a FileSet which provides the set of objects which needs to be recompiled. In the example where Y.c has an include X.h statement. The dependency list stored with X.h would include Y.c. If X.h changed the result of the query would be X.h and Y.c. This approach is simply; however it does not allow arbitrary extension and may not be scalable.
This issue started almost year ago and was discussed several times. The original target was NB 3.4 and attached prototyp of the solution was created based on the discussions and requirements at that time. I think requirements and proposals mentioned here are valid, but there is still a lot of things unclear. What to do with this issue? Should we resurrect discussions? I'm changing target milestone to FUTURE, because I do not believe we will be able to solve it for NB 4.0.
As described in http://www.netbeans.org/servlets/ReadMsg?msgId=619519&listName=nbdiscuss the current work on projects prototype has been stopped.
--> VERIFIED