Hello James,
Am 27.01.2023 um 17:28 schrieb James H. H. Lampert via MIDRANGE-L <midrange-l@xxxxxxxxxxxxxxxxxx>:
Out of morbid curiosity, what exactly *is* TMKMAKE?
It is a port of the UNIX "make" tool to the CL environment, taking OS/400 specific peculiarities into accounts which don't exist on plain Unix: Files with members, objects in a library sharing the same name (but being of distinct type), and source members not having a file name extension to designate their content (such as .c on UNIX indicating the file has C code inside).
Basically you write text describing an output object, and dependent input objects. Objects can be things in a library as well as members of files. Then you write he command(s) to generate the output object from the input object(s).
On UNIX, make implicitly expects a "Makefile" in the current directory. So, to recompile something on UNIX is accomplished by a single "make" on the command line. I changed tmkmake's command defaults to always expect a MBR(MAKEFILE) in the SRCFILE(*CURLIB/SOURCES).
Most simple example:
mylib/mypgm<pgm>: mylib/mypgm.sourcefile<file> mylib/mydspf<file>
crtbndrpg PGM(mylib/mypgm) srcfile(mylib/mypgm)
Note that member name and file name are exchanged. Note that I used mylib for clarity. If you change your current library (which is expected by my command defaults anyway), you don't need an explicit library. Unless you refer to objects in other libraries, that is.
Translated into English this means: If the pgm object mylib/mypgm (before the colon) does not exist or its timestamp is older than (any of the) the dependent file mbr object(s) (after the colon), run the associated command to recreate the former from the latter.
As dependents, you can list as many other objects as required. In the example above, I also referred to a file mydspf. So if this is newer then the pgm object but the source is not, the PGM is compiled again, anyway.
Make recursively checks each and every rule for dependencies. And that's the power of make, with carefully written Makefiles: Change one countless referenced field in a PF and just run make there, and everywhere else. Things will be automatically be rebuilt as needed.
You can write as many rules as desired. One rule may have several programs defined. I "abuse" this to have "timestamp members" in a separate SRC PF for PFs and LFs. The "changed" time stamp changes with every record added/changed/deleted, while I suspect (I didn't actually try) the LF's time stamps change with every record added or deleted, or when the actual key value field(s) change.
HTH.
Tmkmake has some flaws compared to the UNIX make I'm used to, as laid out in my message from last Monday, though. The biggest issue is that it checks timestamps only once at startup instead of after a rule has been executed. In the end, interdependencies force the same rule to be needlessly run more than once.
:wq! PoC
midrange.com
