From:	pjfarley AT banet DOT net (Peter J. Farley III)
Newsgroups:	comp.os.msdos.djgpp
Subject:	Re: Question about running configure script
Date:	Mon, 01 May 2000 22:35:54 GMT
Message-ID:	<390e0378.27082543@news3.banet.net>
References:	<Pine DOT SUN DOT 3 DOT 91 DOT 1000501115937 DOT 9191J-100000 AT is>
X-Newsreader:	Forte Free Agent 1.21/32.243
NNTP-Posting-Host:	32.100.165.5
X-Trace:	1 May 2000 22:34:53 GMT, 32.100.165.5
Organization:	Global Network Services - Remote Access Mail & News Services
Lines:	63
X-Complaints-To:	abuse AT prserv DOT net
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp
Reply-To:	djgpp AT delorie DOT com

Eli Zaretskii <eliz AT is DOT elta DOT co DOT il> wrote:
>On Mon, 1 May 2000, Peter J. Farley III wrote:
>
>> C:\>djtar -x -v -!. co991215.tgz
>
>The -!. part is IMHO not a good idea.  It disables the automatic
>conversion of some invalid file names that are frequently met in
>tar.gz archives of the Unix origin.  djtar then prompts you for a
>valid name for each of these files, which can be quite a pest if the
>number of such files is large.
>
>Why did you suggest to use that option?

Since the package the original poster asked about was *not* a GNU
release, the types of invalid file names you refer to are (in my
experience -- YMMV) less likely to occur.  Using this option preserves
*all* periods in file names, all of which are perfectly legal under
Win9x DOS boxes -- which is where I strongly suggested the OP should
be operating.

What unix file names would pose a problem in an LFN environment?

>> Although, as Eli Zaretskii will probably tell you, *almost* any
>> GNU-style package *can* be built under DJGPP in plain DOS, there are
>> sometimes cases where Win9x LFN (long-file-name) support is truly
>> necessary.
>
>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.

Doing at least the initial port in an LFN environment is MUCH easier.

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.

>> One addition I would make to the things
>> that others have already said:  Before running the configure script,
>> run the DJGPP version of "autoconf" to modify most of the
>> "non-DJGPP-friendly" parts of configure.  To do this, change to the
>> directory where the configure script is stored, and just say:
>> 
>> C:>\place\where\configure\lives>bash autoconf
>
>This should not be necessary with the current version of ported Bash
>2.03.  It supports features that make this step redundant.

Hmm-m-m.  Looks like I need to do a little RTFM before I can reply
intelligently to that.  I'll make a further reply later, if it seems
needed.

----------------------------------------------------
Peter J. Farley III (pjfarley AT nospam DOT dorsai DOT org OR
                     pjfarley AT nospam DOT banet DOT net)

- Raw text -