[ale] compiled system calls versus shell scripts

[Joe Knapka]

Geoffrey <esoteric at 3times25.net> writes:

> Bjorn Dittmer-Roche wrote:
> > On Thu, 23 Oct 2003, Geoffrey wrote:
> 
> >>For example, you know networking needs to be up before Samba is started.
> >>  But, startup of samba and nfs could be parallel processes.
> > Make is a little smarter than that. EG. if you have a copplex web of
> > dependencies, rather than just a few things that can happen in parallel,
> > make might do better.
> 
> How so?  You still have to create the make file with the specified
> dependencies.  How does that differ from building a script with the
> dependency checking built in as well?  What is that make will do
> differently?

For one thing, it provides a (relatively) standard and well-known way
to express dependendency relationships. If you use make rules
appropriately, your startup script could be simply a collection of
lines like:

system : proc1 proc2 proc3 proc4 proc5 proc6 proc7

proc1 : proc2 proc3

proc2 : proc5

proc3 : proc5 proc7

proc6 :

You could trivially add and remove dependencies as you tuned your
startup procedure. Of course, you could write your own scripts to make
it similarly trivial, and maybe that would be more fun :-)

The downside is that (a) making it as neat as I've described probably
would require nontrivial make-rule voodoo, and (b) the targets have to
be files, which means that each of the "procN" names would need to
actually be the name of a file created when the associated part of the
startup script was run. Making that all work could get hairy (it
might, for example, involve wrapping many simple actions in scripts
that do the actions and then touch files on disk).

Another possibility might be to use Ant, if you're comfy with the
whole Java+XML deal. I haven't used Ant much, but my impression is
that it's generally a better tool for doing this sort of thing than
make.

Cheers,

-- Joe