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:
1. 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.
2. 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
--
GT.M - Rock solid. Lightning fast. Secure. No compromises.
_____________
The information contained in this message is proprietary and/or confidential.
If you are not the intended recipient, please: (i) delete the message and all
copies; (ii) do not disclose, distribute or use the message in any manner; and
(iii) notify the sender immediately. In addition, please be aware that any
message addressed to our domain is subject to archiving and review by persons
other than the intended recipient. Thank you.
