Generate js-config.h
Enable memory/mozalloc
Export DictionaryHelpers.h
Install prcpucfg.h.

For some reason this goes in both dist/include and dist/include/nspr. The make build uses a symlink in dist/include/nspr, but makes a copy in dist/include. We just use a symlink for both. This is based on the value of the MDCPUCFG_H variable, which comes from the nspr autoconf.mk file.
Switch from 'python -B' to the $(PYTHON) variable.
tup-config-generator.py - also include js' config.status
Put generated headers in <installed-headers>, even if they are not in dist/include yet.

Some compilation commands pull headers from the source tree, rather than dist/include. These need to be put in the group so commands are ordered properly.
Start ipdl conversion.

In the make build, a single python process is executed to read all of the .ipdl files and create the entire ipc/ipdl/_ipdlheaders/ directory structure all at once. With tup, the model is going to be to read a single .ipdl file at a time and write out the contents just for that file. This way a change to a single .ipdl file only rebuilds the pieces necessary, rather than all generated files for every .ipdl file.
Generate ipdl_lex/yacc.py only once, and re-use them.
More ipdl conversions.
Generate most of the rest of .ipdl srcs.
Generate files from *.ipdlh

These are slightly different from *.ipdl, since we don't get the Child and Parent files.
ipdl.mk files: Use += instead of = when setting IPDLSRCS.

This will let the Tupfile that generates IPCMessageStart.h include all of the ipdl.mk files directly, since it just needs the source filenames.
Generate IPCMessageStart.h based on ipdl.mk files.
Generate all .ipdl files in a single command.

It turns out that all .ipdl files depend on all the others, so compiling them separately doesn't help. Changing any single .ipdl file afterward results in all of them getting recompiled anyway, so there is actually a net loss trying to do them separately as the files are parsed multiple times.
Use all configure-generated files for now.

No need to try to replace autoconf as well. We can re-use the obj-dir generated by configure, and use another obj-dir as a variant tree for tup if the user wants an out-of-source build. We just need to define which obj-dir to use in tup.config.
No need to generate files created by configure.

If tup.config were the primary driver of configuration, rules like these could be used to generate those files. However, it is easier to keep autoconf for now, so we can just re-use those files.
js/xpconnect/src: Use configuration variables from autoconf.mk
xpcom-config.h needs to be in <installed-headers>

Some compilation commands include this file in the xpcom/ directory, rather than in dist/include/
Symlink prcpucfg.h using autoconf configuration, not tup configuration.