- 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