Although GT.M is very flexible when it comes to configuration - it is all managed with environment variables - configuring directories one way vs. another can make it easier or harder to manage configurations. Two points worth noting are:
- The GT.M compiler produces .o object code modules from .m source code modules. Each object code module is specific to a GT.M version (or release - we use the terms interchangeably). So, the same source code modules can produce different object modules. Furthermore, GT.M produces different object modules for use in M mode (each character is one byte) and UTF-8 mode (each character is one or more bytes encoded in UTF-8). Also, while database files can have formats that are compatible across GT.M versions, a database file is can be open only by processes of one GT.M version at one time.
- Users expect to have multiple GT.M versions installed and in use on a computer. For example, one use case is rolling upgrades of GT.M releases.
While GT.M's environment variables accommodate just about any directory structure, for sanity, I recommend a GT.M working directory for each application environment. Within that working directory is a subdirectory for routines (independent of GT.M release), and a subdirectory for each GT.M release to be used. For example (the gtm script that comes with GT.M creates this structure by default):
$ tree -dL 1 myApp/
myApp/
├── r
├── V5.4-002B_x86_64
├── V5.5-000_x86
└── V5.5-000_x86_64
4 directories
$
As my laptop is 64-bits, I have separate subdirectories for 32- and 64-bit flavors of the same GT.M release, V5.5-000, so that I can run one or the other. Routines source modules go in the r subdirectory.
The structure of each release specific directory is:
$ tree -d myApp/V5.5-000_x86
myApp/V5.5-000_x86
├── g
├── o
│ └── utf8
└── r
4 directories
$
The g subdirectory is where database related files go ("g" is "globals" in M parlance). Object modules compiled in M mode go in the o subdirectory, and object modules compiled in UTF8 mode go in the o/utf8 subdirectory. There is also an r subdirectory in the release specific subdirectory for routines that depend on a GT.M version. (Since we try very hard to avoid regressions, the use case is where a routine is enhanced to take advantage of new functionality in a release.
In 32- and 64-bit releases of GT.M, object modules can be simple .o files in the o and o/utf8 subdirectories. As 64-bit releases of GT.M support placing object modules in shared libraries created with ld (makes memory usage more efficient when there are thousands of processes executing the same routine), you can also create .so files and place them within the o and o/utf8 subdirectories on 64-bit platforms.
Sometimes, when packaging VistA, I have also used p subdirectories to parallel r subdirectories, at the myApp level as well as at the release specific level. The idea is that routines generated when patching would go in the p subdirectories.
Regards
-- Bhaskar
--