Bus width reduction is easy to avoid, I was just using it as an example, when blocks have many, many parameters, all adding/removing logic and changing port lists, it can be quite complicated. Again, it should be better. As for identifying "user generated" warnings, that's the problem, in that there is no way to tell what is user generated.
For "the brick", the library term is a little misleading. In Quartus II, User Libraries is nothing more than a search path. So if an entity instantiates something called "ingress" for example, then Quartus II will first search all files manually added to see if they have a module/entity. Then it searches the project directory and all search path directories to see if they have a source file with that name, such as ingress.v, ingress.vhd, ingress.bdf, etc. (Note that if the file name doesn't match, such as a file called ingress_revB.v, it won't be looked at).
VHDL has a whole different set of libraries with a different meaning.
A .qip is just a Tcl-like file that is generally used to add files, but since they're in a file, they're held together, i.e. all the files are either added or not. The other benefit of a .qip is that it can reference where it's at, and add the files relative to it. That allows the user to move the .qip and the source files around, and as long as they keep their relative locations, it works.
My feeling is to go to Project -> Add Files and just start adding files you know you use. If you spend 15 minutes, I imagine you'll get a significant chunk. Then start looking at the warnings, and add what keeps coming up over time. They'll all be in the .qsf, and if you want, you can cut and paste them into a .qip, and do a search and replace to make them relative paths. Unless you have thousands of files in different hierarchies(which is possible), it's usually not too much trouble.
Honored Contributor
