Re: [sdcc-devel] Proposal for 2.3

[Michael H. <mic...@ju...>]

On Mon, 3 Sep 2001 pa...@pj... wrote:

> >build at the end of next weekend.  Objections?  Big bugs that we should
> >fix first?
>
> I hit a bug today, which makes my mp3 player project crash in some
> very mysterious ways.  Reverting to a SDCC from a few weeks ago, the
> problem disappears.  I don't know what's going on yet, but I will
> dig deeper in the next couple days.  It could be something stupid
> in my code that didn't matter before.  I don't like posting bug
> reports without a good test case, but since you asked....

Any luck?

> Also, I'd like to ask about rearranging the library directory a
> bit.  I've been tempted to do this, but being new to SDCC it
> seems better to ask before making such a change.  Today we have:
>
> share/sdcc/lib/<port>
>
> except in the case of mcs51, where it's either "small" or "large".
> I'd like to change it to:
>
> share/sdcc/lib/<port>/<options>
>
> The "options" part would be a string returned from a function
> in each port that looks at what options are in use (or if that
> function pointer is NULL then no extra subdir is used).  For
> mcs51, this function would return "small" or "large" in the
> normal cases, and things like "large-xstack" or "small-reentr"
> if those options are in use.  In the long term, this ought to
> allow all ports to add special features without the situation
> where the user gets incompatible library code linked into their
> application without any errors (of course, they shoulda RTFM :)
>
> These extra libraries would only be built if configure is passed
> something like --enable-device-options.  And the finishing touch
> would be some verbose message in the linker when it can't find
> a library, and maybe even a special error message when putchar()
> is the undefined symbol!

Sounds OK, but but after applying Hope's razor[1] I'd rather do this for
2.4.

So, is it worth doing the release?  The bugs currently in the tracker are
minor, but we do have Paul's possible bug hanging out.

-- Michael

[1] "If it's not a bug fix then it can wait for the next release"