[EMAIL PROTECTED] (Ben Darnell) wrote:
> What is this "mission and purpose statement"? I can't find it in the
> prc-tools-0.5.0 source archive. Unless you can provide evidence to the
> contrary, it seems to me that the mission of prc-tools is and has always
> been to create a Free/Open Source toolset for creating PalmOS
^^^^^^^^^^^^^^^^
> applications, in which case both your and John Marshall's versions are
> equally "official" by this criteria.
No. Or, I should rather say, only partially. The original goal, mission, and
purpose of prc-tools was to create a toolset that (1) Free/Open Source as you
say *AND* (2) runs under UNIX and follows the UNIX way of doing things. Part
(2) is just as important as part (1). I know that to you it isn't, but this is
immaterial: it was for the original developers and inventors of the name prc-
tools, and that's what matters. The key motivation for its development was that
people wanted to develop for their Pilots from UNIX and CW doesn't run under
UNIX.
> John Marshall's prc-tools-2.0 has one characteristic which, while
> not traditionally meaningful in the world of Free Software, is percieved
> as very important by many developers - His version is officially
> endorsed by Palm Computing.
Which is why I formally charge Palm, Inc. with infringing on the rights of the
community I represent and causing it severe harm by its misrepresentation of
the software that we have developed to fill our need as we see fit and that we
are still actively maintaining on our own. Palm's presentation of prc-tools on
the development tools pages for the target OS sends the misleading and false
message that our cause is dead (which it isn't), that we are no longer
maintaining our software, and that only Palm and Com. Marshall are (which is
not true). This message is causing severe harm to our community and our cause,
I maintain that Palm, Inc. has no ethical or legal right to send such a
misleading and harmful message, and I demand that Palm, Inc. stop sending this
message immediately, either by disavowing all connections with prc-tools
altogether or by clearly acknowledging the original cause of prc-tools,
identifying me and the IFCTF Embedded Systems Engineering group as the only one
currently fighting for this cause by actually writing and maintaining code and
thus automatically being its current official maintainer, and, if Palm, Inc.
desires to continue developing, maintaining, or promoting its own divergent
version of prc-tools that we don't agree with or welcome, clearly identifying
this version as divergent and not accepted or welcomed by the ones fighting for
the original cause of the original software. I will do whatever it takes to
make Palm, Inc. comply with our demands.
> I have believed since the beginning of this conflict that (at least) one
> of the two prc-tools packages should be renamed, but neither maintainer
> is willing to do this.
Actually, there are some steps in this direction. On the pilot-unix mailing
list Mark W. Eichin <[EMAIL PROTECTED]> wrote:
| I've always seen
| it as a bug that the palm-targetted toolchain is anything more than
| that, a target. [...]
to which I responded with an outline of my plans for future prc-tools
development:
: OK, I see a misunderstanding here. OF COURSE I agree with you that there
: should not be a special version of gcc for PalmOS or anything like that. In
: the GNU toolchain PalmOS should be targeted just like any other embedded
: system would be. And I'm working very hard right now as I write this to make
: this a reality: make the necessary enhancements to the mainstream GNU
: toolchain that are not specific to PalmOS per se but are needed for it (in
: particular, improving the relaxation mechanism in the m68k assembler and
: linker and teaching m68k gcc to generate position-independent code for
: embedded systems with independently floating ROM and RAM), and then make
: PalmOS use generic facilities (plus maybe a special PalmOS target just to
: enable the right set of options by default) instead of applying big non-
: portable and unmaintainable patches to the toolchain. This will be the #1
: step in PalmOS gcc development past version 0.6.0.
:
: This, however, only concerns the GNU toolchain. The complete solution (what I
: call the PalmOS gcc programming environment, or simply PalmOS gcc) also
: includes other components. FOR ANY TARGET IT SUPPORTS, the GNU toolchain does
: not try to take over the functions that are and should be provided by other
: components, such as the OS kernel, system header files, or system C library.
: And this is what the PalmOS gcc Support Environment (PGSE) does. After
: version 0.6.0 prc-tools will cease to exist as they do now. The patches to
: the GNU toolchain will disappear. You will use the stock GNU toolchain with
: PalmOS being a target just like any other. After you configure and build this
: toolchain, however, you will need to download and build PGSE. This directly
: corresponds to what you would do for any other target. If, for example, you
: wanted to use the GNU toolchain on your Linux box to cross-compile for VAX
: 4.3BSD, after configuring and building the toolchain for vax-dec-bsd you
: would need to get the 4.3BSD header files and libc sources and compile the
: latter. You would do exactly the same thing for PalmOS: configure and install
: the toolchain, then download and build the support environment. This support
: environment is different a little from what you would need for, say, 4.3BSD
: in that libc is not the main component and instead you have libcrt as the
: crucial library plus some host tools like obj-res, but then PalmOS isn't
: 4.3BSD UNIX, and things like this can vary greatly from one OS to another,
: which is why they are not part of the toolchain in the first place.
:
: (A note about prc-tools as they are now being deprecated. Nothing is being
: thrown out or dropped, I'm simply restructuring it. Instead of prc-tools as
: they are now, you will have two separate products: PalmOS gcc, which will be
: an abstract entity logically consisting of the stock GNU toolchain configured
: for the PalmOS target and the PGSE package, and a separate resource and PRC
: manipulator that is a stand-alone program that doesn't require the GNU or any
: other compiler toolchain at all.)
The last paragraph outlines my plan for the restructuring of prc-tools. In
order for the new arrangement to cover everything that the current prc-tools
cover, two packages would be necessary: PGSE, the PalmOS gcc Support
Environment supplementing the GNU toolchain for building code and data
resources for PalmOS program entities, and a separate resource and PRC
manipulation package. My primary interest is in the design and implementation
of PalmOS gcc, so I will not relinquish PGSE or the related support in the GNU
toolchain for it to anyone else. I do not, however, maintain most of the tools
that I want included in the resource and PRC manipulation package. Therefore, I
would be willing to let someone else maintain it, as long as they do an
acceptable job at it.
If Com. Marshall agreed to stop maintaining a project named prc-tools, either
by renaming his current project or by restructuring it similar to the way I'm
restructuring mine (or some other way that does away with prc-tools), I would
not use that name either, unless everyone agrees to use it for some appropriate
purpose, such as the resource and PRC manipulation package separate from PalmOS
gcc. If, however, Com. Marshall does not cooperate and continues his current
prc-tools project, I will have to maintain the resource and PRC manipulation
package myself and call it prc-tools, just to keep this name and avoid giving
it away to Com. Marshall, as such a giveaway would again send a message that
the original cause of prc-tools is dead, which it isn't.
There is also a third option. Both Palm and Com. Marshall have told me that
they want to see our efforts merged. I have consistently responded that I will
not accept a merge on Com. Marshall's terms. However, if he felt it was OK for
him to make such a unilateral merge proposal to me, I felt that it was the
right thing for me to do to make a similar counter-proposal to him, proposing a
merge on my terms. I have E-mailed it to him last night. With each side now
having made a unilateral merge proposal to the other, we can see whether there
is a middle ground or no common ground at all. However, I cannot wait
indefinitely for such negotiations and in the meantime watch the PalmOS gcc
community being severely hurt by Palm's current misrepresentations on the
development tools pages for the target OS. Therefore, I have set the end of
next weekend as the deadline for negotiations to start. If the negotiations
don't start by that deadline, I will assume that there is no common ground or
cooperation and will resume aggressively demanding that Palm, Inc. stops its
misrepresentation.
> I think that while the two packages are
> coexisting with the same name, most people will choose Marshall's
> version, partially because he works for Palm, and partially because he
> makes it relatively easy to install on Windows (which, like it or not,
> is the OS used by the majority of developers) (and even with this,
> people have problems with the installation - imagine if they tried to
> compile everything from source).
Making Palm stop its misrepresentation on the development tools pages for the
target OS is one of my efforts to change this.
> When you say "prc-tools-2.0 isn't the latest version; 0.6.0 is" [...]
I don't go by version numbers and "latest", I'm simply alerting the people to
the fact that I'm the official maintainer and all of my versions, however
numbered, are official, whereas Com. Marshall's version is a deviant side
branch regardless of how he calls it.
--
Michael Sokolov Harhan Engineering Laboratory
Public Service Agent International Free Computing Task Force
International Engineering and Science Task Force
615 N GOOD LATIMER EXPY STE #4
DALLAS TX 75204-5852 USA
Phone: +1-214-824-7693 (Harhan Eng Lab office)
E-mail: [EMAIL PROTECTED] (ARPA TCP/SMTP) (UUCP coming soon)
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palm.com/devzone/mailinglists.html
