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: 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 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)