[rfa/binutils] distclean .cvsignore?

Andrew Cagney cagney@gnu.org
Sat Feb 28 18:43:00 GMT 2004


> 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




More information about the Binutils mailing list