On Thursday, 03/20/2003 at 08:10 CST, "McKown, John" <[EMAIL PROTECTED]> wrote: > The problem with using "make" is that I must know *in advance* which > programs I want to compile and then code a make file for that set of > programs. What I want to do is more like: > > Edit program1 > Submit program1 to compile > Edit program2 > Submit program2 to compile > ... How ever many times > > Each compile is independent of the others and I don't want to "preplan" and > build a make file to compile the set of programs since I don't often know > the members of the set in advance. I do see where a make file would be used > as I would use a "compile proc" in MVS. I.e. to compile a C program, I must > do steps 1 through 5. I could then create a generalized make file where I > pass in the name of the program to compile along with any parameters. > > I may just be trying to force an MVS concept where it doesn't really belong.
"The Linux Way" is to use make. Only the most trivial of programs doesn't need a make file. I think make really shines when it comes to management of dependencies, such as changed header files, something a simple batch compile can't accomplish. Find another windmill. :-) But putting philosophy aside, putting the task into the background, whether it is gcc or make, is how it's done. If your turnaround time gets too long, or your friends complain, stop doing it. ;-) If that's not good enough, then give the Linux server more resources. Or, you may be able to use gcc's cross-platform compiler support. Compile zLinux applications on your workstation, and use NFS, et. al., to store the objects up on zLinux. Alan Altmark Sr. Software Engineer IBM z/VM Development
