Comments on your comments ...

You should try to read the Doc++ lex grammer ... its a full state machine in itself. It does not always ignore white space. It counts qoutes, "{", "(", switches state as it steps into and out of structs, classes, functions, etc.

Sorry ... A Rule a b c : d e f : g h i ;

Has 3 parameters ... any parameter can have any number of elements.

Do you have rules like

rule X { local i ;

for i in ( 1 2 3 4 5 6 7 8 9 ) { if $($(i)) { } } }

Sun's make did two things I really like.

1) they are "integrated" with the compilers using an normally undocument (or it use to be undocument) command line arguement.

Each time a file was compiled, a file .make.dependencies, I believe, is updated by the compiler (or make looking at special compiler output). The file lists for each target (.o file) which files were read during the compilations.

2) make had a file called .make.state (I believe) which was also maintained.

Each time a target was built, the make state would be updated. The next you called make, make compared the exact commands lines for the previous run, and if they differ, would assume the target needs to be rebuilt.

For example, make a.o might call the C++ compiler and the command lines would be stored in the make state.

a.o: CPP -o a.o a.cpp

Now you want to turn debugging on. export CXXFLAGS=-g; make a.o

Make says "last time I did "CPP -o a.o a.cpp", but this time the macro expands to "CPP -g -o a.o a.cpp", thats different, therefore, a.o needs to be rebuilt.

Notice, the user does not need to touch or remove anything to get this to happen.

This is also not an issue for us. By you must admit that something like

Main A : a.cpp c.cpp ; Main B : b.cpp c.cpp ;

would be nice if c.cpp was compiled to c.o only once. The above style is more deductive than forcing the user to build a library simply to avoid a second compile. In this case, .o files would work just as well.

If fact, there are cases when you need to force an object file to be linked into an application. Now I have to do things like ..

Main A : a.cpp ; Object c.cpp ;

ExtraObjects A : c.o ;

but with grsiting, its a bit more tricky.

Your correct, a rule could be writen to grist stuff that not already gristed. But usage of the $(X:G=g) notation is so nice and easy, that you often don't build a temporary variable to get gristing sorted out.

A form like $(X:X=g) (where :G adds grist only if no grist is present) would be convent.

I'm not sure if everything should be/needs to be gristed. But gristing should be consistent.

For example, in the rules distributed with Jam, the C++ rule does not grist its inputs. The Object rules does not grist its inputs, the Objects rule does.

So, mixing C++ rules and Objects rules in the same Jamfile is risky.

C++ a.o : a.cpp ;

MainFromObjects a : a.o ;

(very possibility) refer to differ a.o files