previous up next print clean
Next: RELATED TOPICS Up: Claerbout and Karrenbach: Cake Previous: OTHER DIRECTORIES


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. We 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 suggest breaking 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 reusable, 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, coagulating nifty rules into include files makes those nifty rules available everywhere. Another reason to break a long rule into parts is if some of the parts are time consuming and we plan frequent restarts from an intermediate place.

Editing the cakefile is changing the rules. What are the rules when the rules are changing? This is especially confusing for 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 we 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. We learned this when we tried working with file names like It is particularly confusing if two rules can make the same target. Which should be used? We 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 we had trouble when we 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%.

previous up next print clean
Next: RELATED TOPICS Up: Claerbout and Karrenbach: Cake Previous: OTHER DIRECTORIES
Stanford Exploration Project