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.
There are two primary ways to construct a new project with existing code: - The easiest is to specify the top of the tree in the first dialog. NB will then absorb all source files beneath that point and mark them in the project a physical folders. - Another way is to give it a folder without source, then give it a makefile that will do the 'make clean' and 'make', and the automatic configuration will discover all of the source files from the makefile output. The first method works well when the source tree contains only files relevant to the project. However, some trees contain files from multiple disjoint projects, such as a central repository for executables that all share different subsets of the files. In our case we have thousands of files in our source tree, where only a fraction of them are used for each executable. And in this case, the project will complain about unresolved includes and unresolved variables, precisely because it has included files that can't even be built by the intended project. One additional problem with the first method (and a large repository) is that folders that are unrelated cannot be removed from the project without actually deleting the source files and marking the subversion as deleted. That's because the folders are physical, not logical. The second method works well for just such a large repository, because the project discovery will find and add all of the source files to the project in 'logical' folders. This works quite well because it is a focused view on source files specific to that project. All this you probably know well. The only problem with the second method, is that is seems that include folders are not automatically added (as logical folders) to the project. I've tried creating small sample projects to illustrate, but the small projects seem to get properly populated. So this also means that I don't know how to repeat this other than in a large environment. The workaround is to go figure out which include folders were not included and add them with 'add items from folders'. Without doing so, code assistance will not be able to resolve types declared in the missing folders. Hope that's clear. Product Version: NetBeans IDE Dev (Build 201602080002) Updates: Updates available Java: 1.8.0_45; Java HotSpot(TM) 64-Bit Server VM 25.45-b02 Runtime: Java(TM) SE Runtime Environment 1.8.0_45-b14 System: Linux version 3.14.27-100.fc19.x86_64 running on amd64; UTF-8; en_US (nb) User directory: /home/toddb/.netbeans/dev Cache directory: /home/toddb/.cache/netbeans/dev
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