Hello Raphael, On 11/11/2011 08:07 AM, Raphael Neider wrote: > 1. I can check in only the new files using the old naming scheme > (underscore) for consistency. > > 2. I can check in the new files using the old naming scheme plus > updated versions of existing header files that have seen changes in > the latest gputils' templates/sources. Some bit names and config flags > have been dropped or renamed, so even this update might break user > code. > > 3. I can check in the new files using the new naming scheme together > with updated versions of all other device headers to reflect the new > naming scheme (basically a complete rewrite) and the changes made to > gputils' templates/sources from which they are generated. Due to the > changed naming convention, this will most likely break a lot of code > out there (if there is a lot of code out there, that is), but will (a) > simplify further maintenance (no manual modifications on generated > files for now), and (b) bring our headers closer to what the HiTech > compiler is using (as pointed out by Gál). At least in the long run, I > think I want to get here. > ... and no, I do not really want to maintain XXX_bits next to XXXbits or use > #ifdef LEGACY_NAMING > #define _BITSUFFIX _bits > #else > #define _BITSUFFIX bits > #endif > /* ... */XXX ## _BITSUFFIX > throughout the library ;-) >
If we are going to replace XXX_bits with XXXbits in the future, I would vote for XXX_bits next to XXXbits (without LEGACY_NAMING) for old files and only XXXbits for new files and mention somewhere in the documentation that XXX_bits is deprecated and will be obsoleted (removed) in the near future. So we retain the backward compatibility and have clear path for new development / devices. But you already mentioned that you don't like this approach... >> I also fixed a nasty bug which made the gputils >> 0.14.0 unusable :-(. > How so? At least all the sdcc/pic14 and pic16 device libraries > compiled, assembled and linked without complaints (not sure about > their actual content, though)? The .cinit section is not generated for lkr files were DATABANKS heave SHADOW option. 12f1822_g.lkr is (only) such a case in gputils 0.14.0. There are also problems when the hex file is directly generated by assembler (non relocatable code), but this is not used by sdcc. Borut ------------------------------------------------------------------------------ RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 _______________________________________________ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
