Developing Redlog in the new tree and compiling quite frequently, I am observing two problems:
1. The make process takes too long.
2. All error messages when compiling go into some log file but not to the screen.
There is a 3rd problem not related to the new tree:
3. The syntax-checking of the reduce compilers is not really good. In particular, certain mismatches of numbers of arguments in procedures calls are not detected.
A partial solution to (3), which I have been using for a long time already, is using the cross referencer and automatically processing its output before compilation.
I now have got something that solves the problems (1-3) for me but it is not really nice yet:
I currently have got a "make.red" overloading some procedures in "remake.red" (e.g. for using package.map rather than 'folder) and a "make.sh" (bad name, I have learned meanwhile).
The entire solution currently relies on having both "make.sh" and "make.red" located in trunk/packages, and on trunk/packages being the current directory.
I could check this into svn at least temporarily for being used by other developers and as a basis for discussion.
This "make.sh" calls awk for filtering and formatting the output of Reduce calls. The awk programs are currently located as strings in "make.sh", which is not a good solution for maintenance and further development.
I think perl would be one feasible and much cleaner solution, and I could do that.
BUT: Since yesterday evening I am wondering whether GNU make is flexible enough
* to have targets like "redlog", which is not a file in CSL (in PSL I at least have redlog.b).
* to make the out-of-date decision not on the basis of filedates but using a call of Reduce, which then does olderfaslp().
From a user's point of view, I think, it would be just great to have a "Makefile" in trunk/packages such that one can say "make groebner".
This would use a "compiler call" like "rd", which is another piece of software doing thorough syntax checking (I will go into the cref code for this at some point) and compiling a package or a single file (decision automatically by testing for "create!-package", and maybe some option to force one or the other).