On 23 Sep 2002 at 14:29, Fringe Ryder wrote: > I am an experienced Windows user AND developer, and have even written > programs for Linux (and OS/2, CP/M, C64, etc.) And yet I spent probably > five hours trying to get an MSW dev environment that would allow me to > build Plucker... or any part there-of... and failed. I've got CygWin up, > gcc up, Palm's dev kit, got the emulator running, but I'm still completely > unable to run a make.
Sorry to hear you got caught part way. Perhaps you could document your success and pitfalls up to the sticking point, so others could look at that document and perhaps see the solution. There were some threads in the maillist on cygwin a few weeks back. I set the cygwin up and can compile things like the plucker-viewer OK, but my that was some years back that it was configured now, so I'm afraid not of much use to describe a setup nowadays (that was an old cygwin-b20). > Anyhow, so I poked around further inside. Correct me if I'm wrong but > there's actually very little C++ in the Plucker project... Some different tools have come about to solve different types of tasks over the years. They all have to be Free; beyond that its 'best tool for the job'. > The Palm viewers are C, and the Exploder/UnPlucker are C, and that's > pretty much it. The Palm viewer probably has to be C so that it can run fast on a weak processor. The explode lib is portable C so it can also be used in an embedded envronment. Mike has built a the start of a portable C viewer that can be separate from resources also. > The Parser is mostly Python, perhaps with some Perl mixed in. The Python parser only needs Python AFIK (one of the Python gurus please correct me if I am wrong). Python is part of most POSIX installs, and is now shipped in the new OSX (seems a bit buggy in first release though). MSW usually doesn't have it, so the relevant parts of the library are put in the installer. Python and perl are good choices for parsers, since they are excel at string manipulation and internet access. The python parser can also transmogrify into a Java parser, through Jython. An amazing feat. A C++ parser (with some parts windows only at that time) was made awhile back based on the python parser. It was quite an extensive work. I believe it was Bill Nalen that did the C++ parser, info in is in mail archives. > The Conduit is Pascal?!? The Conduit.exe has always seemed to work out well. The code organization was kept the same in the Desktop's palm_installer class that does the similar management. The Conduit.exe will continue to be a part of the MSW install since it still allows part of a 100% GUI-less interface to plucker, and also for those who have scripts that depend on it. > Plucker Desktop is C++, but isn't a formal part of Plucker. I started to > try to convert it to VC++, and quickly ran into a few barriers such as it > requiring wxWindows. Even after installing and compiling wxWindows, there > are a lot of compile errors... maybe later. It does need a GUI toolkit for widgets, that was pretty much unavoidable. wxWindows was taken since it is cross-platfom, makes fast performing executables, has a licence compatible with Plucker, and makes apps that fit in nicely to a user's desktop environment, and gives good support for the Free compilers. Plus XML resources whip the llama's ass. ;-) Hopefully (knock wood) ;-) there shouldn't too much in the way of conversion. A makefile would need to be written though, based on the existing ones for GCC, Cygwin, and Borland Free C++ compiler. > So it looks like potential new team members who work on the dominant > Windows tools are pretty effectively frozen out of helping on the team > until they've decided which element (and resulting language) and done a > fair amount of effort to set-up their system for it. Linux users are > bang-in, but ex-Linux-users who don't live/breathe/die cygwin/gcc are cast out. This issue comes up every once in a while (though usually seems phrased in a "Why doesn't Plucker switch to the Metrowerks Codewarrior for the viewer?") The focus isn't so much to support the dominant tools, they have to be Free tools foremost, or else they aren't worth the effort put into making the software that could be lost if Metrowerks closes shop. Plus basing development on non- Free tools would freeze out any developers that didn't have the cash to get the tools just to do a bit of hacking/fixing: I know I would've been locked out of doing anything on the viewer if I had to cough up a few hundred just to get it to compile. But things went okay, and things built eventually, and I was able to help out the project in a few areas that I was able. Plucker is a big project, additional sets of hands are certainly needed and welcomed. Best wishes, Robert .---~~~~~~---. ________________________________________ / \ / \ MedicalMnemonics.com | __ | .-------+` `+-------. A free non-profit online searchable | | () | | database of medical mnemonics to help `-------+.__.+-------' remember the important details. (| O O |) ^\ /^ http://www.medicalmnemonics.com \ \ / / [EMAIL PROTECTED] \ ~~~~ / ________________________________________ `-_ _-' ~~~~~~ _______________________________________________ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
