Mail Archives: djgpp/1997/09/11/21:34:19
Eli Zaretskii <eliz AT is DOT elta DOT co DOT il> wrote:
<Snipped>
>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
<g>. 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)
- Raw text -