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: Thu, 11 Sep 1997 23:44:39 GMT Organization: None Lines: 103 Message-ID: <34187783.6773474@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: >Other packages have such files. In fact, every package that supports >internationalization (aka i18n) has such a file in the `po' directory. Well, if that's the case, then (following your suggestion below) it should be reported to the package maintainer as a bug. Alternatively, if autoconf supports it, macros can and should be written by the package-builder to automatically replace such names with 8.3-friendly substitutes for those environments that require it. >> OTOH, there *are* a lot of names in the package that are not unique in >> the first eight characters. DJ dealt with these very constructively >> by shortening common prefixes like "stamp-" to "s-" or "st-", "tmp-" >> to "t-", etc. That can be done on an automated basis, if needed, as >> part of a non-LFN implementation. > >IMHO, this should be reported to the package maintainer as a bug that >needs to be corrected. There should be no problems in changing these >names to be unique in the first 8 characters. Agreed. Or better yet, automated with macros for configurations (like non-LFN DOS) that need it. >> Not a disadvantage at all, if you think about it. Anyone who is brave >> (or foolhardy) enough to attempt a rebuild from source can, I believe, >> be expected to have the entire environment available. Rebuilding from >> source is not trivial under any circumstances, so I do not believe it >> is too much to ask that the required toolset be expected to be >> available for source rebuilds. > >With all due respect, I disagree. The more auxiliary tools you require, >the more risk that something will go wrong with them. People might have >old ports, non-DJGPP ports, or incompatible programs with the same names. >Or they might set up the tools incorrectly. It is a nightmare to solve >problems due to such snafus when an angry user tells you (from the other >side of the globe) that your package won't build on their system. Which can be neatly solved by putting checks into the configuration scripts that verify versions (e.g., by using "--version" switches). Or tests that make sure the available tools support the functions needed. (See the perl configure script for examples of this.) Then the configuration just can't be rebuilt without the minimum versions and/or capabilities of the needed tools. Look, I'll agree that a lot can go wrong with tools, even GNU's tools . However, with the exception of a new piece of hardware/software that has no gcc implementation yet, there really is not (IMHO) any good reason not to expect an appropriate set of tools to be available. For example, how many users are *just* looking for a new implementation of gawk, with *no* other GNU tools available, *and* are on a machine with no gcc support? (OK, OK, maybe not such a good example -- I was such a person myself, once upon a time.) All GNU configure scripts *assume* a port of /bin/sh is available. Otherwise there is no shell with which to run configure. I agree this is a chicken-and-egg situation WRT bash, since you need a /bin/sh to configure bash itself. But once stable, ported gcc and bash and tools *are* available, why not make source-builder's and new porting jobs and new-version jobs easier instead of harder? I believe that the purpose of porting is to achieve the best possible emulation of the desired environment. That means getting all the tools needed to make up the environment, and that is not, IMHO, unreasonable. Tough to support, yes. I can't disagree with you there. >Look how religiously do GNU people stick to tools that are available on >all platforms. Using your argument, they would require people to install >GNU tools before building other packages. And using my argument above, perhaps they should. Or at least to insist on a minimum set of functionality from native versions of tools. >In my view, using Bash and the rest of the utilities in DJGPP ports is >nothing but a strategic retreat. It is justified (IMHO) only because the >alternatives are much worse. Those who, like me, ported packages without >Bash, know how much energy is required just to generate the Makefiles from >Makefile.in, even for simple packages. That energy is wasted, because the >*real* porting is in making the code work on DOS. No, here I have to repectfully disagree with you. That is not energy wasted, since the porter learns an *awful* lot about how GNU wants to configure things in the process. Packaging is an art, too, and some of the most sophisticated programming and design go into a really good packaging scheme. It is just as much of a challenge to create an *installable* package, and more of a challenge to create a *re-buildable* package, as it is to make a *working* package. These are complementary excercises, not mutually exclusive ones, and the challege of each is on the same level. Ask any commercial software development team whether they want the challenge faced by the packaging team. And check out the quality of the people it takes to build a really "simple" installation process (simple to the end-user, that is). "User-friendly installation" is a very high goal to set oneself. "User-friendly re-building" is even higher. High goals need appropriate tools to aid in the process, or they are not (necessarily) even acheivable. ---------------------------------------------------- Peter J. Farley III (pjfarley AT dorsai DOT org)