This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: [rfa/binutils] distclean .cvsignore?
- From: Andrew Cagney <cagney at gnu dot org>
- To: Ian Lance Taylor <ian at wasabisystems dot com>
- Cc: binutils at sources dot redhat dot com
- Date: Sat, 28 Feb 2004 13:43:24 -0500
- Subject: Re: [rfa/binutils] distclean .cvsignore?
- References: <4040D628.50205@gnu.org> <m34qtbqdlm.fsf@gossamer.airs.com>
Andrew Cagney <cagney@gnu.org> writes:
This patch modifies bfd/ and opcodes/ so that the .cvsignore files are
removed when doing a distclean. The name is not dos friendly so
shouldn't be included in GDB's distro.
My understanding of the distclean Makefile target is that it should
return the directory to the state of a distribution.
I don't think it is a good idea for distclean to remove files which
are actually in the CVS repository. That is not its job.
A distribution is different to CVS. A distribution ends up with files
not in CVS (yacc output, texinfo, ...).
I agree that .cvsignore files aren't needed in a release, though I'll
note that we're not hearing any complaints about them. To remove
them, we should either remove them from the CVS repository, or we
should arrange for the process which builds a release to remove those
files from the release. I don't think distclean is the right
approach.
That's because this is the first GDB release since they were added (good
thing GDB's release process checks for this :-).
If distclean isn't the right approach, what is? Perhaphs the top-level
release scripts can learn to ignore these?
There are a lot of other DOS file naming issues in the binutils. We
stopped worrying about it a while ago, and nobody has complained. The
daily snapshot cron job still runs doschk, and I include the output
below.
Ah, you just don't see the complaints, they get handled before they
become an issue (perhaphs I should moan and complain more so people
notice? :-).
Also, remember, its GDB and not BINUTILS that is being built 8.3 :-/
For reference:
http://sources.redhat.com/gdb/current/onlinedocs/gdbint_13.html#SEC125
13.4.9 File Names
Any file used when building the core of GDB must be in lower case. Any file used when building the core of GDB must be 8.3 unique. These requirements apply to both source and generated files.
Pragmatics: The core of GDB must be buildable on many platforms including DJGPP and MacOS/HFS. Every time an unfriendly file is introduced to the build process both `Makefile.in' and `configure.in' need to be modified accordingly. Compare the convoluted conversion process needed to transform `COPYING' into `copying.c' with the conversion needed to transform `version.in' into `version.c'.
Any file non 8.3 compliant file (that is not used when building the core of GDB) must be added to `gdb/config/djgpp/fnchange.lst'.
Pragmatics: This is clearly a compromise.
When GDB has a local version of a system header file (ex `string.h') the file name based on the POSIX header prefixed with `gdb_' (`gdb_string.h'). These headers should be relatively independent: they should use only macros defined by `configure', the compiler, or the host; they should include only system headers; they should refer only to system types. They may be shared between multiple programs, e.g. GDB and GDBSERVER.
For other files `-' is used as the separator.
enjoy,
Andrew