On Wed, Mar 27, 2002 at 05:57:00PM +0000, Chris Ring wrote:
> So that brings up an interesting general topic, maybe I just don't
> understand how PRC-Tools install works. I'm new to Palm's development
> tools, so forgive me if I could have RTFM somewhere...
(You mean "Palm OS development tools", not "*Palm's* development tools",
which would be something different.)
IMHO this is off-topic here and I really don't have time to properly help
you understand all this, so here are some general thoughts only.
Red Hat's RPM, Debian's dpkg, Cygwin's setup.exe, and Windows'
"Install/Remove Programs" are all Package Management Systems,
implemented with various degrees of success.
Package management is a Good Thing.
A package manager helps you install, uninstall and upgrade things. It
tells you what versions you've got installed and maybe tells you when
there's a new one. It tells you what files belong to what package, and
vice versa. It helps you find the documentation. It both slices and
dices.
You really don't want to go back to the bad old days of "unpack .zip
file into temporary directory, read readme file which is sometimes
called readme.txt or sometimes readme.1st, copy parts here and parts
there, find little setup.bat script that sets up registry stuff, reread
readme to see how to use it, run setup.bat"... then months pass, you
want to uninstall it... "oh no I've lost the uninst.bat script from that
particular temporary directory, and I can't remember which DLLs in
C:\WINDOWS belong to this one". A package management system insulates
you from all those details.
> Do the tools depend on something in cygwin (like, I
> suppose, cygwin dll's) so I'd have to redistribute those dependant
> libraries as well? Do they depend on some registry settings that
> wouldn't get created if I just distributed a .zip file (I'd hope not)?
Yes and yes (with good reason -- if you want to complain about your
dashed hopes, feel free to do so on the Cygwin mailing list, whose
denizens will be happy to flame you for posting an annoying question
which comes up weekly :-)).
> What I really want, is a simple tools distribution that I can pass
> around to my development team; so we know we're all building product
> using the same bits.
A package management system makes it *easier* to verify what version
Antsy Joe has installed.
> Today, we all have to download cygwin on each
> PC, then install PRC-Tools using setup.exe's script, then pray
> setup.exe got it right,
If you believe that a prc-tools binary I built does anything useful (for
example, if you believe that it's not a Trojan horse) and you believe
that the Cygwin binaries somebody else built work, then you might as
well believe that setup.exe works too. (Much like, as an end user, you
more or less believe that InstallShield works.)
(Amusingly enough, for most of the last week setup.exe *has* been broken
and hasn't installed prc-tools on Windows correctly. But it was fixed
yesterday, within 24 hours of my reporting the problem. There was no
prayer involved: you could see the failure pretty easily.)
> I'd just feel better if I "knew" we all had
> the same thing. Building from a released .zip file would give me that
> peace of mind.
In your in-house developers situation, it's just possible that a .zip
file would give you that peace of mind. (But I believe the package
managed solution would too.) It'd be a crazy waste of time to try to
duplicate what setup.exe does this week with the registry, but it might
be worthwhile to have your own prc-tools "released .zip file". In fact,
if you decided to learn enough about this stuff to do this, you might
find out that the prc-tools Cygwin binary package *is* a released archive
file that mostly just needs to be unpacked in the right place. ;-)
But doing this would throw away some functionality that setup.exe gives
you.
More importantly from a corporate viewpoint: if setup.exe goes wrong,
you can get support from the Cygwin maintainers. If your local zipfile
thingie goes wrong, it's your problem.
But the public release situation is different.
> You're right, I do want a working installation... but I don't
> understand why a .zip file distribution wouldn't give me that.
^^
It's not just you. There's tens of thousands of you.
You might be able to control your in-house developers' installations and
force them to follow the instructions ("or else you're fired, buster!"),
but there's no way to compel the general public to follow instructions,
or even just to read them.
Mike Davis is demonstrating this very well at this very moment :-).
The .zip file distribution of the SDK is not giving him a working
installation. A package suitable for machine unpacking might constrain
his flexibility and choice a little, but it would instantly solve his
frustration. (And mine! :-))
It's not even his fault. This is not "sync the .prc to your device"
(and some people even have trouble with that!). These packages are
complex enough that if you wrote installation instructions formally
enough that they could not be misinterpreted and would apply to every
configuration, they would be written in such complex language that they
would not be comprehensible to some human readers, so they wouldn't be
followed. You can't win. Installation instructions are always
substandard: they're always going to be useless for someone. (This is
very depressing for people trying to write installation instructions.)
I get a certain amount of email from people whose installations are
failing. (Even if the problem is with an SDK or PalmDebugger, they
still email me, not PalmSource or another vendor :-(.) Even at this
level, it's impossible to help them individually and still get anything
else done, and this is galling because it really is upsetting not to be
able to help these poor lost souls.
The only viable answer is to automate it and write the instructions so
that they are read by the computer. That's why I distribute a package
in preference to a raw archive. If I only distributed a raw archive
with instructions, I would get orders of magnitude more email. And that
means it would simply not be a practical way to distribute the tools.
>> After jumping through all the cygwin setup.exe hoops to get the
>> latest prc-tools
It is agreed that there are currently a few too many hoops. New
functionality in setup.exe released in the last two weeks will allow the
number of hoops to decrease by two. I'm working on taking advantage of
that functionality in the prc-tools packaging.
Unfortunately time spent answering email and mailing list questions is
time taken away from improving the tools. In order to help the people
having installation problems, I have to ignore them -- but that's not
particularly easy.
(And this, Mike McCollister, is what I mean when I say that questions
about when upcoming releases will be available delay that release. Of
course, there is an extent to which my tongue is in my cheek when I say
that. :-))
So... I hope that's more than you ever wanted to know about PRC-Tools
distribution. It's as much a social question as a technical one.
John
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/support/forums/
