This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [rfa/binutils] distclean .cvsignore?


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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]