Mail Archives: djgpp-workers/2001/04/27/03:30:49
> Date: Thu, 26 Apr 2001 22:16:31 +0100
> From: Richard Dawe <rich AT phekda DOT freeserve DOT co DOT uk>
>
> > - Files whose names where UPCASED, such as TODO, NEWS, README,
> > etc. should be stored upcased in the zip, for the sake of users
> > who set FNCASE=y and want to see the file names as they would on
> > Unix. (If you have difficulty to make this happen, I can
> > suggest how to do that.)
>
> OK, I'll fix that for the release. Please suggest how I would do this. I
> do not know off the top of my head, but I could probably work it out.
There are two ways:
- set FNCASE=y before zip'ping the package.
- edit the *.mft files so that they have the right letter-case, then
invoke zip with the manifest file as a response file, like this:
zip -9 fil40b.zip @manifest/fil40b.mft
> > - The problem with "ginstall -s" being unable to work with
> > PMODE/DJ-stubbed executables sounds disturbing. Does ginstall
> > work with CWSDSTUB? What about programs compressed with UPX?
> > If these don't work either, I think we need to fix `strip' to be
> > able to work with such programs.
>
> I don't know - I'll look into that.
If the only problem is with `strip', then Mark probably should take a
look at this. The case of UPX is not very important (since
compressing strips the program anyway), but CWSDSTUB and PMODE/DJ
should IMHO be supported.
In any case, "install -s" should not fail if `strip' didn't work,
perhaps just print a warning message.
> > - The messages printed by chown and chgrp are different from those
> > printed by v3.16: the previous port pretended that the
> > owner/group _did_ change, while this port's message says the
> > owner/group were retained, but cites the new owner/group. This
> > is misleading, IMHO. What is the reason for this change?
>
> Actually, I made them behave like this, after we discussed some things in
> a thread entitled "Porting Fileutils 4.0: chgrp, chown, df", starting on
> 2000-01-10. chown() always succeeds. Before carrying out the modification
> operation, chgrp sets $GROUP to the desired group; afterwards it sets it
> back. In other words, the user is considered to own everything and belongs
> to every group.
>
> The message is confusing. chown() and chgrp() both contain a function
> called describe_change(). I could patch that to display the actual user
> and group name, rather than the requested user and group.
The trick to set GROUP etc. was meant to avoid patching chgrp's and
chown's code where they set the owner and the group. I do think it is
better to say the ownership was changed, not that it was retained.
Perhaps removing GROUP from the environment right after the call to
chgrp library function will do that?
> > - There are no Makefile's and no config.h, which requires
> > everybody to run the configure script, and have the associated
> > tools installed. Is there any reason why the source
> > distribution couldn't come already configured, so that users
> > could simply say "make"?
>
> There were many LFN problems with Fileutils 4.0. Some filenames required
> massaging to fit into 8+3. Some files had multiple extensions, which
> required modifications to automake, autoconf files, some scripts.
While porting other packages which had those problems, I used a
file-name-change feature of DJTAR: include a file with name mappings
in the distribution and tell users in djgpp/README how to invoke DJTAR
to rename files on the fly (DJGPP source distributions were packaged
with all the renaming already done). Edits of the configure script were done
by config.bat, before it runs "sh ./configure". Those edits also
added some stuff to the configure script to change the file names
mentioned in Makefile.in's when they are edited into Makefile's.
Autoconf and Automake files were left untouched, because people who
modify them should indeed have the ported Autoconf and Automake
installed.
Take a look at the ported Textutils and GDB, to see two examples of
this approach. I believe Mark did something similar in Binutils.
> It was easier to reproducibly configure and build with LFN
> and SFN starting with a minimal set of changes, when I was testing.
That might be the best approach for you, but end users have different
priorities ;-)
> I can go for the "kitchen sink" approach where the tools aren't needed
> ("everything" patch applied). I have scripts set up to generate diffs, so
> that wouldn't be much work.
If you can send me whatever I need to generate modified files that are
supposed to be suitable for building on DOS and Windows, I will test
the build procedure.
> It seems I've taken the wrong approach by depending on autoconf and
> automake. I'll fix that for the next release.
Thanks.
In the meantime, I did some minimal testing to `df' on plain DOS,
including with SUBST and JOIN. I also built GDB after installing the
binaries, and tried `cp' with numeric backups on plain DOS.
Everything works correctly. Good work!
- Raw text -