PHILOSOPHY AND PITFALLS

Two philosophical approaches to programming are ``procedural'' and ``rule based''. Fortran and shell language are examples of procedural languages and cake and make are rule-based languages. Many of the rules in a cakefile each invoke a small shell-like program. Some rules might contain a long string of shell-like commands with many intermediate results. It is a question of philosophy if you want to break up such a long string into separate rules. I generally prefer one long rule which is like a shell. The long string of commands is easier to understand and debug than a bunch of small rules. However, many circumstances will cause me to break up a long rule into parts. The best reason to break a long rule into separate short ones is if some of the short ones are reuseable, either in this directory, or in all directories. We never like to see repeated code in any language because it makes maintenance susceptible to inconsistency. Further, it is the isolation of nifty rules that enables us, after improving them, to immediately bring the improvements into effect everywhere. Another reason to break a long rule into parts is if some of the parts are time consuming and we intend frequent restarts from an intermediate place.

What are the rules when the rules are changing? When we start coding in make or cake we are writing rules that will evolve with time. (It is like when the tax law changes.) This issue is particularly confusing to people switching from make to cake. (make requires you to keep all the intermediate files, so to force a rebuild you just remove any file that is defective because of the changing rules). Suppose you just used the editor to change sign1=0 to sign1=1 in the rule below.

FIGDIR/spectrum.v : DATA
        <DATA Ft3D sign1=1 | Graph > junk.H out=FIGDIR/spectrum.v

If you type cake figures the figure may not build because no files have changed their dates. Technically, you should have put sign1 in a parameter file and then the date of the parameter file would have changed when you changed the value. Often you can use the system program touch to change the date of the data or the program, but that is a poor idea if these are system wide objects that don't belong to you. In this case (which I have chosen to be particularly pesky) you could type cake spectrum.burn, or you could temporarily change your rule to

FIGDIR/spectrum.v : DATA cakefile
        <DATA Ft3D sign1=1 | Graph > junk.H out=FIGDIR/spectrum.v

because the date of the cakefile itself did change when you changed the value of sign1. Later you must remember to remove this figure dependence on the cakefile, or this figure will rebuild every time you change anything in the cakefile.

Finally there are some hazards to coding in the cake language. We might think that rules with no dependencies would never need to run, but the inventor of cake decided (probably by experience) that such rules should always run.

Most hazards arise because there can be many rules and they can interact in unexpected ways. Sometimes cake will attempt to use a rule recursively and will run for a half minute and then give up. I learned this when I tried working with file names like NAME.save.v. It is particularly confusing if two rules can make the same target. Which should be used? I think cake should tell you that two rules can make the same target and you should get rid of one of them. Instead it seems that we cannot tell which will be used, or maybe it tries to use both. This hazard is especially likely with the wildcard %. Recently I had trouble when I had two similar rules, one for building plot files and one for merging them. These rules were

        skmod%.v : mod%.v dat%.v
                vp_SideBySideAniso   mod%.v  dat%.v  > skmod%.v

        %.A %.V %.v : %.H
                <%.H Byte > %.A
                <%.A Ta2vplot title=% labelsz=12 > %.V out=%.v

Notice that the second rule creates the same target as the first if ``%'' takes the value skmod%. I'm not sure exactly what caused the trouble but I solved it when I changed one line to read

        %.A %.V %.v : %.H  if cando %.H