Future Proof File Designs/Methods

[Chris Sharman]

>In spite of your concern about the complexity, I firmly believe that any
>system should have a "compile everything" job stream. Probably 2 jobs, one
>for Qdesign and another for Qtp and Quiz. This may actually be the single
>most important "future-proofing" tool!

Hear, hear. (our environment VMS).
We impose a few naming conventions:
interdependent sources have the same name: eg fred.qzs, fred.qts, and where
necessary a build-fred.com script to build it.
The generated compiled files must be called after the source: eg fred*.q%c
LIB-*.* are included modules.
Errors aren't allowed.
Most warnings aren't allowed (we'd like to insist on clean compiles, but PH
warnings are sometimes unavoidable, and range in impact from ignoreable to
fatal).
We build everything out of CMS, and report all failed builds, all missing
compiled files, all extra compiled files (that weren't live before).
Every time we do it there are some problems to sort (we have problems with
permanent subfile dependencies too - ban them!!), but we just feed them back to
the author to fix before redoing the exercise.

To be honest, I don't think I could contemplate an upgrade without such a tool:
I'd have to write it first.

Chris
______________________________________________________________________
Chris Sharman			Chris.Sharman@CCAgroup.co.uk
CCA Stationery Ltd, Eastway, Fulwood, Preston, Lancashire, PR2 9WS.
= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
Subscribe: "subscribe powerh-l" in message body to majordomo@lists.swau.edu
Unsubscribe: "unsubscribe powerh-l" in message to majordomo@lists.swau.edu
powerh-l@lists.swau.edu is gatewayed one-way to bit.listserv.powerh-l
This list is closed, thus to post to the list, you must be a subscriber.