From: Bela T. <bel...@ks...> - 2004-03-01 16:38:54
|
Hi About two weeks ago someone (I think Erik) has suggested to move any vendor specific header files to separate subdirectories. I think it is a good idea. I would propose the folowing directory structure: include -> this directory contain only header files files specific to the C-language (common to all ports) include/mcs51 -> vendor-independent header files for the mcs51 port, e.g., 8051.h, 8052.h, ser.h, ser_ir.h, serial.h, mcs51reg.h Vendor-specific directories include/mcs51/analogdevices include/mcs51/atmel include/mcs51/cygnal include/mcs51/dallas include/mcs51/infineon include/mcs51/philips include/mcs51/etc... include/avr include/ds400 include/gbz80 include/hc08 include/pic14 include/pic16 include/tininative include/xa51 include/z80 All existing source code of the should be changed like this: #include <string.h> #include <stdlib.h> #include <stdarg.h> #include <ctype.h> #include <mcs51/atmel/at89x051.h> #include <mcs51/ser_ir.h> main(void) { .... .... } Regards: Bela |
From: Erik P. <epe...@iv...> - 2004-03-01 16:46:38
|
On Mon, 1 Mar 2004, Bela Torok wrote: > About two weeks ago someone (I think Erik) has suggested to move any vendor > specific header files to separate subdirectories. > I think it is a good idea. Actually, it was Frieder. > I would propose the folowing directory structure: > > include -> this directory contain only header files files specific to the > C-language (common to all ports) > > include/mcs51 -> vendor-independent header files for the mcs51 port, e.g., > 8051.h, 8052.h, ser.h, ser_ir.h, serial.h, mcs51reg.h > > Vendor-specific directories > include/mcs51/analogdevices > include/mcs51/atmel > include/mcs51/cygnal > include/mcs51/dallas > include/mcs51/infineon > include/mcs51/philips > include/mcs51/etc... > > include/avr > include/ds400 > include/gbz80 > include/hc08 > include/pic14 > include/pic16 > include/tininative > include/xa51 > include/z80 > > All existing source code of the should be changed like this: > > #include <string.h> > #include <stdlib.h> > #include <stdarg.h> > #include <ctype.h> > > #include <mcs51/atmel/at89x051.h> > #include <mcs51/ser_ir.h> > > main(void) > { > .... > .... > } I think this is a good organization, but it will be difficult to change the cvs directories. Perhaps we could leave the existing files where they are in cvs, but handle them as a special case in the make install so that they install to the correct places? Erik |
From: Maarten B. <sou...@ds...> - 2004-03-02 12:42:22
|
Hi, I'm just a user (and recently supplier of some header files) but can you please explain why it is a good idea to move the header files? Are there really that many that all overview is lost? It seems to me this only brings a lot of unnecessary work and risk in the form of broken code. And "If it ain't broke..." Greets, Maarten Brock > > About two weeks ago someone (I think Erik) has suggested to move any > > vendor specific header files to separate subdirectories. I think it > > is a good idea. > > > > All existing source code of the should be changed like this: > > > > #include <string.h> > > #include <mcs51/atmel/at89x051.h> > > #include <mcs51/ser_ir.h> > > I think this is a good organization, but it will be difficult to > change the cvs directories. Perhaps we could leave the existing files > where they are in cvs, but handle them as a special case in the make > install so that they install to the correct places? > > Erik |
From: Erik P. <epe...@iv...> - 2004-03-02 17:58:03
|
On Tue, 2 Mar 2004, Maarten Brock wrote: > I'm just a user (and recently supplier of some header files) but can you > please explain why it is a good idea to move the header files? Are > there really that many that all overview is lost? It seems to me this only > brings a lot of unnecessary work and risk in the form of broken code. > And "If it ain't broke..." We could retain backwards compatibility for the existing files. For example, a new ser_ir.h could be: #include <mcs51/ser_ir.h> #warning ser_ir.h is deprecated, use mcs51/ser_ir.h instead Erik |
From: Bodo W. <bod...@we...> - 2004-03-02 20:32:18
|
> We could retain backwards compatibility for the existing files. For > example, a new ser_ir.h could be: > > #include <mcs51/ser_ir.h> > #warning ser_ir.h is deprecated, use mcs51/ser_ir.h instead This sounds to me as the best solution :-) No problems with CVS, as old files don't need to be moved/deleted. And it's a chance to tidy up the "real" header files. Bodo |
From: Bernhard H. <bh...@mg...> - 2004-03-03 11:07:01
|
> We could retain backwards compatibility for the existing files. For > example, a new ser_ir.h could be: > > #include <mcs51/ser_ir.h> > #warning ser_ir.h is deprecated, use mcs51/ser_ir.h instead What about adding another include path depending on the port? We have at the moment: -Isdcc/bin/../share/sdcc/include -I/usr/local/share/sdcc/include We could add: -Isdcc/bin/../share/sdcc/include/%port% -I/usr/local/share/sdcc/include/%por t% It's just an idea, Bernhard |
From: Vangelis R. <vr...@ot...> - 2004-03-04 10:07:10
|
----- Original Message ----- From: "Bernhard Held" <bh...@mg...> To: <sdc...@li...> Sent: Wednesday, March 03, 2004 12:53 Subject: Re: [sdcc-devel] New include file directory structure > What about adding another include path depending on the port? > > We have at the moment: > -Isdcc/bin/../share/sdcc/include -I/usr/local/share/sdcc/include > > We could add: > -Isdcc/bin/../share/sdcc/include/%port% -I/usr/local/share/sdcc/include/%p or > t% This is what the pic16 port does but modifies the search paths natively from the port _finaliseOptions. See src/pic16/main.c for an example. Vangelis |