The target_USES property declares what kinds of rules and external libraries target needs. This includes at least the rules to compile source code language files, but also special libraries that the target needs to link against. Typically something is available as a makefile use if it defines rules to process files, or if it modifies compiler or linker behaviour, or if the way in which the feature will be included differs from one target architecture or site to another. For example, X11-related libraries are made available as a use because the preprocessor and linker options required for it vary greatly from one system to another.
A particularly improtant point to note is that all rules to compile source code languages are implemented as uses. You must also mention for every target all the uses it will need. If you add a source file to the SRC property but forget to add the use to pull in the rules to compile that file, make will complain that it does not know how to compile that source file. This will happen even if some other target in the same makefile has already mentioned the use--every target in the makefile really is treated completely independently.
The order in which the uses are mentioned is not usually important. Various programming language implementation impose restrictions on the linker choices. For example, on many systems programs containing C++ code must be linked with the C++ compiler, not with the system's standard linker or, say, the C compiler. Similar for C, while many FORTRAN programs can be linked with almost anything. The release tools solve this internally by assigning priority values to linker choices and choosing the highest priority linker for a target. Therefore, it does not make any difference what order you define the uses--the release tools will make its selection based on the priorities. Having said that, other uses do not define compilation rules but simply provide header files and libraries. In those cases the order may be significant, although usually it should not be.
Another complication to the ordering issues is added by the fact that the order in which you mention uses in your makefile is not necessarily the order in which the release tools will consider them. This happens because uses are considered together with linksets (explained in the next section), and linksets are sorted by their dependency orders. The sorting attempts to be as stable as possible so that if there is no reason to rearrange depedencies, it doesn't. Sometimes the order may change, though. For example, if you mention a makefile use X in your makefile and some package you are depending on also brings it in via a pseudo-use, the preprocessor options for X will probably end up moved on the command line. On the other hand, X options are defined as system preprocessor options so that they come after the preprocessor options from package use relationships, meaning that they might not move after all.
At any rate, all the uses you can mention in the makefile you can also mention in the PACKAGE file, including the ones that define compilation rules. Where a makefile use defines linksets, you can only get access to them from the PACKAGE file--from makefile you always get the default linkset. This is further explained in the next section.
Finally, your project may have added uses other than those described in the reference pages following Appendix F, ``Details on Makefile Uses''. The mechanism implementing the uses is completely extensible, and in fact if you find yourself repeating the same target-specific rules from one makefile to another you might want to consider making it a proper use. You can use the existing implementations as examples.