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.
Summary: | project creation sometimes misses include folders | ||
---|---|---|---|
Product: | cnd | Reporter: | tbrunhoff <tbrunhoff> |
Component: | Project Discovery | Assignee: | Alexander Simon <alexvsimon> |
Status: | RESOLVED INCOMPLETE | ||
Severity: | normal | ||
Priority: | P2 | ||
Version: | 8.2 | ||
Hardware: | PC | ||
OS: | Linux | ||
Issue Type: | DEFECT | Exception Reporter: |
Description
tbrunhoff
2016-03-17 17:56:05 UTC
As an aside, I've been successfully using this second method for several weeks and it avoids many, but not all, of the previously reported code model problems. The difference is that I have a single project for each executable, so when that project is the 'main project' there's no ambiguity. Previously, I used one project for each library, one one project for executable with the libraries marked as 'related'. And because I frequently work on multiple executables some of the libraries were only appropriate for some of the executables and/or they would be built with different compilers. To me it seemed that NB had a difficult time figuring out which source file was 'owned' by which project, and sometimes would mark them in the pull-down as not belonging to any project. So although many discrete projects is the model I would prefer, single monolithic projects seems to fit NB's model better. Hi Todd, Thank you for detailed problem description. I want to clarify some moments of the first described scenario. You did not mentioned if you allow building the project or not. IDE has absolutely different behavior depending on "build" step. If you forbid building and do not provide build log IDE creates a project with all source and header files. IDE does not have any information about include directories and user defined macros. Each include directive is resolved by file search in the root folder. Code model is inaccurate. If you allow building (or provide build log) and building is successful IDE creates a project only with sources that were included in the building. IDE knows all include directories and user defined macros. Code model is accurate. IDE has several machineries to configure project at creation time. 1. "Build Analyzer" is most reliable provider of "real compile lines". It is available on Linux and Solaris. The provider addes pre-load library that catches any system "exec" commands while building a project. IDE adds the file "nbproject/private/Default-exec.log" if log was produced. It is important that build procedure does not unset paths and pre-load libraries. 2. Configure by building log. It works if "build analyzer" is not available. You should make the best efforts to produce building log with real compile commands. Otherwise IDE cannot right configure a project. IDE adds the file "nbproject/private/Default-build.log" if log was produced. In both cases IDE relies on "full clean&build" (not incremental). If logs do not available or do not have valuable information, IDE uses 3. Configure by binary artifacts. It produces a low quality code model and depends on level of debug information. (Exception is studio compilers CC and cc that keep real compile line in binary file) According you description it seems you did not allow building a project. So could you clarify how did you create a project by first scenario? Did you allow building project? What artifacts are in a project "nbproject/private" folder? Alexander > You did not mentioned if you allow building the project or not. In every case, whenever I build a new project, I always do a full build so that the IDE gets a chance to see every file compiled the the compiler specified for the project. It is that process that tells it which files belong to the project, which in my case, turns out to be much better when the set of files is a subset of all the files in the build tree. So I think this means I use the Build Analyzer. > According you description it seems you did not allow building a project. First assume, as above, that I always use the Build Analyzer. Now then, view this bug report as how a project can be constructed. The first method works, but the source folders will be physical folders and cannot be removed and they will incorrectly contain all the files in the source folders whether or not they are part of the project. This is ok if the folder contains only files specific to that project. The second method also works, removing all source folders before clicking the "finish" button which starts the clean/build. But in this case it will discover all of the folders and files pertinent to the project and will put them in logical folders. This latter case is the focus of this bug. It works great! Except..... sometimes it does not discover the include folders. (In reply to tbrunhoff from comment #3) > This latter case is the focus of this bug. It works great! Except..... > sometimes it does not discover the include folders. Hi Todd, I do not know what to do with this bug. Probably it is a the same problem described in the bug #258214 (was fixed and included in the 8.1 patch 2). Could you try reproduce the issue? Please add trace flag: -J-Dcnd.discovery.trace.projectimport=true and attach message log if the bug is steel reproduced. Alexander |