Mail Archives: djgpp/1997/09/16/04:00:29
Eli Zaretskii <eliz AT is DOT elta DOT co DOT il> wrote:
<Snipped>
>Emacs distribution just doesn't have files whose names clash in the
>8+3 namespace, or are illegal on DOS and not automatically converted
>by DJTAR. I kept reporting such cases as bugs until Richard Stallman
>corrected them. That's all there is to it.
Obviously, that is a good solution. Until then, however, I just
thought there ought to be a way (and no, I don't know what it is yet)
to automate such a process, maybe only for the package originator, so
that one-name-at-a-time work can be eliminated. I'm still thinking on
it, and I don't claim to have solved it yet.
>> Well, maybe it *will* anger a few users out there. But why do you say
>> "impractical"?
>
>Because people want packages to be built out of the box for them. And
>on Unix, they can expect that, since the standard tools there are
>generally powerful enough. If they don't get this, many of them won't
>use GNU tools.
I understand your point. I just think that the extra step we ask
DJGPP builders to take -- downloading and installing the tools before
building the first (hopefully of many) package(s) -- is not as great a
burden as you seem to believe. And does the ng want to have to
support people like those you describe? I'm all for making the
*binary* distributions as easy and tool-free to install as possible.
That allows as many people as possible to *use* the tools. But for
those who are re-building, it is my belief that it is not too much to
ask that they get the toolset needed to do the re-build operation.
Think about what you just said -- "... *standard tools there* ..."
(emphasis mine). Isn't the DJGPP/DOS/GNU goal to make these selfsame
tools available to everyone? So that they *can* be used? So why in
the world can't package originators and porters use them, too?
>> Look, there is a lot of knowledge needed to attempt a re-build.
>
>It doesn't have to be this way. In fact, on Unix, it isn't, you just
>run ./configure and say "make install". Most of the DJGPP ports
>usually would build with a single "make", perhaps with a configure
>step, provided you have the required tools; no extra knowledge is (or
>should be) required.
My statement about the knowledge needed to re-build is based on the
expectation that none of us is perfect, and that there will (or can)
be problems in a re-build package that *might* require more knowledge
of how the toolset works than is true for a binary package. This is
*also* true on unix systems -- the package *may* rebuild without
trouble, and should, in fact, do so if the packager has done their job
well. But packagers are human, too, and mistakes can be made. And
the knowledge I speak of is required (in the event of a problem)
whether you are on DJGPP/DOS or any flavor of unix.
Thus, my other statements about the only difference being the number
of initial tool downloads needed. If a package has been built well
and carefully, availability of all of the appropriate DJGPP/DOS tools
should be just as transparent to a DJGPP/DOS re-builder as it is to a
unix re-builder, *except* for the initial download and installation of
each tool not normally available on DOS systems.
---------New (but related) topic-------------
One small incompatibility between DJGPP and unix systems that could,
perhaps, be addressed in a future release is to use more unix-standard
directory structures (like /usr/bin, /usr/lib, /usr/include, etc.) for
a higher degree of compatibility with the assumptions made for the
unix environment. Just another suggestion. DJGPP currently allows,
but does not require it. Maybe that should be strengthened to at
least a *suggested* structure, with the option to do something
different still allowed, though discouraged.
This would allow tools used in re-building to continue to make the
same directory assumptions made for unix systems, making it more
likely that a re-build would proceed smoothly.
----------------------------------------------------
Peter J. Farley III (pjfarley AT dorsai DOT org)
- Raw text -