Carl Bartels wrote:

> type thing, only make it intelligent enough to search through all the
> .jar's,
> tar's, tgz's, tar.gz's, tar.bz2's, .zip's and God knows what else people

AFAIK future zlibs will understand .bz2.

IIRC the tar interface (which I don't know) would just have
to call "gzopen" instead of "open", the [de]compression would
then happen transparently. I have no idea whether zlib provides
all the other stream-related functions that the tar interface
needs.

I'd say that .jar and .zip are not necessary - just tell the users
with nonstandard machines how to get and install tar and gzip.
Non-programmers on PCs might be happier with winzip, which can
only extract tar, but not create it - but this is not a problem
for them.

Besides, pkzip is only shareware, not completely free, which might
cause legal problems in strange circumstances.
I'm not aware about the legal status of .jar.

I'd keep the #include statements as they are, and have them
search unpacked files first, then look into archives (this way
users can unpack single files, modify them and have them used
automatically).
Another possibility would be a syntax like
#include "[includes]/metals.inc"

where [includes] means to look for a file includes.tar
or includes.tar.gz and find /metals.inc inside of that.
(I intentionally wrote [includes], not [includes.tar]
in order to have this resolved automatically).

To save space, I add an answer to some more postings of
this thread here as well:

> 1)  Documentation:  If all the includes come as one big tar (or
> whatever) file, then people won't be able to peruse them the way they
> can now so a whole new pile of documentation will have to made available
> stating what's in each include file.

Since everybody is supposed to have tar and gzip installed on
his machine, he can unpack the individual files. This also solves
the second topic (Home-brews).

Definition conflicts are a problem already now - somebody
recently reported funny effects when including both golds.inc
and metals.inc (which define slightly different things with the
same name).

CPU time needed for decompression is IMHO not a problem:
People with slow machines can decompress them manually
and use a big includes.tar instead of a small includes.tar.gz.
I'd leave the decision to the user.

Ralf

Post a reply to this message