Reflected those changes in unit design doc
This commit is contained in:
parent
ddafa0935a
commit
418e013dda
|
@ -29,6 +29,27 @@ there is an additional directory in the search path, such as
|
|||
`/usr/local/include/fspl`, then the unit will be searched for in each one (in
|
||||
order) until it is found.
|
||||
|
||||
There are standard paths that the compiler will search for units in. These are,
|
||||
in order of preference:
|
||||
- `$HOME/.local/include/fsplc`
|
||||
- `$HOME/.local/src/fsplc`
|
||||
- `/usr/local/include/fsplc`
|
||||
- `/usr/local/src/fsplc`
|
||||
- `/usr/include/fsplc`
|
||||
- `/usr/src/fsplc`
|
||||
|
||||
Files in `include` directories should *not* include program code, and should
|
||||
only define types and external functions and methods, similar to header files in
|
||||
C. They may have a corresponding shared object file that programs can
|
||||
dynamically link against.
|
||||
|
||||
Files in `src` directories *may* contain program code, and may be compiled into
|
||||
an object file if the user wishes to link them statically. Because of FSPL's
|
||||
ability to "skim" units (discussed later in this document), files in `src` may
|
||||
be used in the same way that files in `include` are. Thus, `src` files are
|
||||
effectively more "complete" versions of `include` files with extended
|
||||
capability, and that is why they are searched first.
|
||||
|
||||
## Uniqueness
|
||||
|
||||
Each unit is uniqued by a UUID. Most users will never directly use UUIDs, but
|
||||
|
|
Loading…
Reference in New Issue