Alternatives to make

[Jerry Coffin]

[... minor change in header causing unnecessary re-compilation]

It takes a little more than one line. In fact, it takes some
collaboration from the compiler, and some shell behind it. But
it does work, and it works correctly (unlike most other tools
I've seen), because it depends on the compiler to find the
dependencies, rather than trying to reimplement the compiler's
logic internally.

The one time I ran into this being a problem, I didn't use the compiler
to find dependencies particularly. Rather, I saved a pre-processed
version of the header and made the other files depend on that. When the
header itself changed, I preprocessed it to an intermediate file, then
compared that to the existing preprocessed file. The preprocessed file
was replaced if and only if the content (ignoring #line directives) had
changed.

The only noticeable shortcoming was that error messages sometimes cited
the wrong lines in the header -- but those were usually incorrectly
instantiated templates, and the real error was in the instantiation, not
the template itself.

 

[Jerry Coffin]

[ ... ]

The Windows version should be added to that page in a day
or two. Please keep in mind that this is a first draft
and is kind of rough. For example, the reading of the
config file uses strtok and expects that the fields in
the file be in a specific order. G-d willing, we'll
be able to revisit some of that later. But for now
it seems more important to include compression and
encryption support first. I'm not very familiar with
either of those topics. From what I can tell from
looking at openssl.org, they first compress and then
encrypt. Is that the order that is generally followed?

Yes -- if you encrypt first, the result will no longer compress well at
all (at least if the encryption works at all well). Compression works
(primarily) by finding and removing patterns in the original input --
but encryption (if it's effective) covers up all such patterns, so
there's nothing left for the compression to work with. In fact, this is
one easy way of testing encryption algorithms -- if the result
compresses at all, the encryption is probably quite weak (though the
converse isn't necessarily true -- lack of compression doesn't
necessarily mean the encryption is strong).