- From: <Irene.Vatton@inrialpes.fr>
- Date: Wed, 26 Jan 2000 11:47:29 +0100
- To: bglbv@my-deja.com
- cc: www-amaya-dev@w3.org
In-reply-to: Your message of Tue, 25 Jan 2000 21:46:29 -0500."
<20000126003955.1770.qmail@my-deja.com>
> (Please don't take that Subject: for a reference to Swift.)
>
> I suggest that the Amaya maintainers remove the automatically-generated
> *_f.h header files from the CVS repository (with "cvs remove", i.e.
> moving them to the Attic). The reason is that these can and *should* be
> regenerated with cextract whenever changes are made. "make proto" takes
> care of this. Having them in the repository both bloats the distribution
> and increases the risk of mismatches developing between the headers and
> the actual functions they describe.
We cannot do that as long as we cannot generate these files on the Windows
platforms.
> (Among other things, this would expose the fact that dialogue/browser.c
> still includes environ_f.h, which is no longer being updated from any
> environ.c since that file no longer exists. It should be including
> fileaccess_f.h instead.)
Neither dialogue/browser.c nor another .c file include environ_f.h, but that
file still existed on the CVS base. I guess you have to start a "make depend"
to update your dependencies. I updated the file bowser.c and removed
environ_f.h.
> I would also suggest that every .c file include its associated _f.h file.
> That way the compiler gets a chance to check the prototypes for consistency.
> The same holds for the header files that define the public API, of course.
I agree.
> Speaking of which, shouldn't some of TtaReadByte and friends be promoted
> to the public API, since they are being used in various places outside
> thotlib? (amaya/transparse.c, batch/app.c, batch/grammar.c, etc.)
>
Yes of course.
Irene.
Received on Wednesday, 26 January 2000 05:48:01 UTC