Mail Archives: djgpp/2000/05/02/20:18:49
Eli Zaretskii <eliz AT is DOT elta DOT co DOT il> wrote:
<Snipped>
>First, the original poster clearly used DOS, not Windows (he said the
>configure script was called `configur').
Yes, I noticed that, but is was not as clear to me as it was to you
that it was plain DOS as opposed to a DOS box. He did say he used
pkunzip, but not which version.
OTOH, if he used the DJGPP tar and got 'configur', you are probably
right that he is in plain DOS. Mea culpa.
>And second, the -!. option has no effect whatsoever on an LFN
>platform. The code which renames file names is disabled under LFN, so
>you always get the original names from the archive, whether or not you
>use the -!. option.
I did not know that. Probably another case of my failure to RTFM.
>> What unix file names would pose a problem in an LFN environment?
>
>I was talking about DOS, not Windows.
Understood.
>> >I have yet to see a package that really requires LFN to be built. A
>> >few simple (and fairly standard) tweaks of the configuration scripts,
>> >that's all that's needed to overcome the file-name problems.
>>
>> True, as far as GNU-released scripts and applications are concerned.
>> I have seen non-GNU-produced application-specific packages that use
>> GNU-like facilities but do not make any portability changes in the
>> *application* scripts and code. This frequently then requires a
>> non-LFN porter of such an application to have to really dig into the
>> application code to find all of the nonportable code and change it.
>
>That's true, but it does not necessarily have anything to do with LFN.
>File names that are invalid on DOS are usually not the most important
>issue when non-portable code is considered, and once spotted, these
>problems are easy to fix.
Only if you are already familiar with shell script reading and
debugging (assuming the invalid names are created in the scripts, of
course). Not an easy thing for a naive user.
>> Note, I do *not* say that such packages can *not* be made LFN-clean.
>> I simply point out that for application packages it is often more work
>> than someone who is only interested in the application itself is
>> willing or knowledgable enough to perform.
>
>Granted, a port is not a trivial job. What I was pointing out is that
>the LFN-related issues are minor compared to the rest of the porting.
Well, maybe, but IMHO only in the case of one already familiar with
the tools.
Granted that discussions like the ones over on gnu-utils-bug are
deeper and more far-ranging than just LFN issues, but LFN issues can
be a great mystery to those not already familiar with them.
Which the OP plainly was not.
>Also note that I was talking about _building_ a package, not _using_
>it. The LFN-related issues in the application code (as opposed to
>such problems in configuration and build scripts) will not be apparent
>until you run the program.
Agreed, unless there are also application-specific building scripts in
addition to the standard ones. But as you say, these are _build_
issues, not _use_ issues.
----------------------------------------------------
Peter J. Farley III (pjfarley AT nospam DOT dorsai DOT org OR
pjfarley AT nospam DOT banet DOT net)
- Raw text -