Now I have 2 skeptic/conservative opinions from sdcc developers and 2
optimistic replays from sdcc users.
I would like to have more opinions from sdcc users, so don't hesitate to
send a mail to sdcc-user or sdcc-devel mailing list.
In my previous post I asked sdcc users to help us (sdcc developers) in
some tasks, mainly in:
* change sdcc libraries license to GPL+LE:
collect the info and make a list of sdcc library files for which
the license can be changed, based on the agreement from authors
(see
http://sdcc.sourceforge.net/wiki/index.php?page=Library+License+Selection)
* documentation upgrade / review / reorganization
* ...
Anybody willing to take the challenge?
Borut
Sébastien Lorquet wrote:
> Agree too, for the same reasons :)
> Sebastien
>
> On Thu, Jan 14, 2010 at 11:12 PM, steven.borley
> <[email protected] <mailto:[email protected]>> wrote:
>
> Borut,
>
> As a SDCC user I'd have no problem with the changes you propose.
>
> As for the deprecation of the keywords I long ago switch to using
> only the version that begin with the double underscore.
>
> One consequence of this would perhaps be to make porting code
> easier. Form experience I often find 'data' is used as a variable
> name, which currently causes some very odd error messages to an
> unsuspecting user.
>
> Steven
>
>
> On 14 Jan 2010, at 06:54, Borut Razem wrote:
>
> > Hello Jesus,
> >
> > here is the complete list of deprecated keywords:
> >
> > non-compliant | compliant
> > keywords | keywords
> > ===============+=============
> > at | __at
> > bit | __bit
> > code | __code
> > critical | __critical
> > data | __data
> > far | __far
> > eeprom | __eeprom
> > fixed16x16 | __fixed16x16
> > flash | __flash
> > idata | __idata
> > interrupt | __interrupt
> > nonbanked | __nonbanked
> > banked | __banked
> > near | __near
> > pdata | __pdata
> > reentrant | __reentrant
> > shadowregs | __shadowregs
> > sfr | __sfr
> > sfr16 | __sfr16
> > sfr32 | __sfr32
> > sbit | __sbit
> > sram | __sram
> > using | __using
> > _naked | __naked
> > xdata | __xdata
> > _overlay | __overlay
> >
> >> I believe this will create a whole bunch of compatibility issues.
> >
> > It will produce a bunch of warnings if the code use
> non-compliant keywords.
> > The code will still compile correctly. And if somebody really
> don't want
> > to see the wraninings, he can use "#pragma disable_warning 197"
> in the
> > source file or "--disable-warning 197" command line option.
> >
> > I actually already implemented this functionality and it was
> trivial:
> > just introduce the error message in SDCCerr.[ch] and change the
> > TKEYWORDSDCC macro in SDCC.lex, so it can be easily reverted if
> there
> > are too many complains from sdcc users.
> >
> > The harder work was correcting the regression tests, which used
> > non-compliant keywords a lot.
> >
> > Best regards,
> > Borut
> >
> >
> >
> > Jesus Calvino-Fraga wrote:
> >> Hi Borut,
> >>
> >> Can you explain why sdcc specific keywords need to be
> deprecated? I
> >> believe this will create a whole bunch of compatibility issues.
> >>
> >> Jesus
> >>
> >> At 11:31 AM 13/01/2010, you wrote:
> >>
> >>> Hello sdcc users and developers,
> >>>
> >>> here is a list of tasks which by my opinion are candidates for
> the sdcc
> >>> 3.0 release:
> >>>
> >>> * sdas merge with asxxxx 5.0
> >>> * change sdcc libraries license to GPL+LE
> >>> * review and merge "SDCC inline support and fixes"
> enhancements by
> >>> Pavel Pisa
> >>> see
> >>>
> >>>
>
> http://sourceforge.net/tracker/?func=detail&atid=100599&aid=1767885&group_id=599
>
> <http://sourceforge.net/tracker/?func=detail&atid=100599&aid=1767885&group_id=599>
> >>> * review and merge support for cs08 target by Gary Osborn
> >>> * deprecate warnings for sdcc specific keywords, not
> preceded with
> >>> two underlines (data, code, idata, xdata, ...) and
> announce in the
> >>> documentation that they will be removed in the future
> >>> * remove unsupported and broken targets xa51, avr
> >>> * review & merge patches in the bug tracker
> >>> * bug fixing
> >>> * ...
> >>>
> >>> The list is quite long and you probably have additional
> candidates.
> >>>
> >>> I propose to make a list of candidates on sdcc wiki,
> prioritize them and
> >>> find the persons which will work on them. There are many tasks
> that can
> >>> be done by non "core" sdcc developers: change sdcc libraries
> license,
> >>> changes, review and reorganization of the documentation, ...
> >>>
> >>> So if there is anybody willing to help us, let us know!
> >>>
> >>> Borut
> >>>
>
------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
_______________________________________________
Sdcc-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sdcc-user
