From: pjfarley AT dorsai DOT org (Peter J. Farley III) Newsgroups: comp.os.msdos.djgpp Subject: Re: Suggestion for future DJGPP development -- depend on bash Date: Tue, 16 Sep 1997 03:36:46 GMT Organization: None Lines: 78 Message-ID: <341defd7.5403236@snews.zippo.com> References: NNTP-Posting-Host: news.newsdawg.com To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Precedence: bulk Eli Zaretskii wrote: >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)