[pilot-db-list] development environment (was: Hebrew support)

[Yedidyah Bar-D. <di...@ta...>]

On Mon, Apr 26, 2004 at 01:50:38PM -0600, Nathan Kurz wrote:
> On Mon, Apr 26, 2004 at 09:57:21PM +0300, Yedidyah Bar-David wrote:
> > OK, I will make it a separate message for each issue.
> > I also subscribed to the list. Still, there are a few things I won't
> > repeat in each message: I use Debian sid, with the following versions:
> > prc-tools 2.2.90.cvs20030306-4 (has gcc 2.95.3, gdb 5.3)
> > pose 3.5-6 (the first version working for me - for a few months I
> > was pretty sure I'll have to use the simulator on Windows, which isn't
> > as simple for me) with the ROM of a Palm m130 (PalmOS 4.1)
> > palmos sdk 5r3
> 
> I'm having luck with Pose 3.5-2 with Slackware 9 and Linux 2.2.24.  I

Yes, but Slackware's "-2" isn't Debian's. It probably took debian more
versions to get something working.

> recall problems with some versions regarding XWindows color depths
> (24bpp did not work?), but otherwise have not have problems with Pose.

I only work with 16bpp, as it's a quite old card and 24bpp is less
convinient. Thanks for telling me, though, so I won't try :-)

> As I mentioned earlier, you will need the MSectGDB patches if you want
> GDB to work more than minimally.  Note also that you need all the
> pieces of those patches installed, not just the gdb replacement.

OK.

> 
> I've found that the Palm Simulators _almost_ work under Wine, and
> perhaps someone with greater knowledge could actually make them work.
> I have had success running GDB on Linux ethernet connected to
> Simulators running on Windows.  If you do this, note that you will
> need gdbpanel installed for  GDB to work with a Simulator.

I currently won't try this, as Windows is much less convinient for me.
If/When you make it work with wine, I might try this.

> 
> > I tried and worked with pilot-db 1.1.0, 1.2.0 alpha 5 (the compiled
> > prc from sf.net), and the CVS version of today. Earlier versions needed
> > minor tweaks to compile against sdk-5r3, the CVS compiled cleanly.
> 
> Since getting involved in this project a couple months ago, I've spent
> most of my time trying to get the CVS version working again.  I've
> recently come to the conclusion that the CVS code is more trouble than
> it is worth, represents an experimental branch from the release
> version sometime prior to 1.1.0, and that the 1.1.0 should replace the
> CVS version as the current head.
> 
> What this means is that you should concentrate your efforts on the
> 1.1.0 release code, and ignore the CVS and alpha series.  I'll try to
> make the appropriate changes to the CVS repository later this week.
> 

I will try and see if there is anything that works for me better with
the CVS version. If not, Fine. Otherwise I'll try to back-port to 1.1.0.

> > I used the following to compile:
> > ./configure --enable-standard --enable-debug --enable-sony=no --enable-handera=no --enable-fiveways=no --enable-make_plugins
> > without '--enable-sony=no --enable-handera=no --enable-fiveways=no', I
> > had some compilation problems, I guess because you need a different sdk
> > for this, didn't check.
> 
> Yes, external SDK's are required for these.  Worse, these SDK's aren't
> all easily available, and need to be extensively massaged if they are
> to work with GCC (prc-tools).  While you can build successfully
> without them, in the CVS version I found bugs in the non-enabled code
> path.  Contact me if you'd like help getting these SDK's.

No, unless you think I should also use them with 1.1.0.
-- 
Didi