| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
| |
Github wants the file to be called README.md, but the GNU coding
standards say that the file must be called README. Duh. So we compromise
by keeping the file README.md in the Git repository for Github, but
during the build process we make a suffix-less copy that is the one
we'll also distribute in the release archives.
|
| | |
|
| |
|
|
|
|
| |
This relocation has the advantage that makeinfo needs no more magic -I
flags to find the generated macro texi files from the top-level; now
those files reside all within on directory.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Peter Johansson pointed out that relying on Automake to install that
file into the source tree (and thus into the distributed tarball) is
dangerous, because different versions of Automake will install different
versions of the license. See this posting for further details:
http://lists.nongnu.org/archive/html/autoconf-archive-maintainers/2009-09/msg00009.html
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The announce-gen script needs access to the gnulib repository in order
to determine the library's version string. The default location, where
gnulib is expected to be, is $srcdir/gnulib. Quoting from maint.mk:
gnulib_dir ?= $(srcdir)/gnulib
gnulib-version = $$(cd $(gnulib_dir) && git describe)
At first, it looked like adding gnulib as a submodule to that location
would be a good idea (especially, since it's needed to bootstrap, too).
After some thought, however, it feels like overkill. Submodules are
meant to track the state of the other repository in the current branch,
but we don't really need that information. We just need some moderately
recent version of gnulib-tool somewhere in $PATH; that's good enough.
|
| |
|
|
|
| |
Gnulib is now registered as a submodule. Please run "git submodule init"
to update your checked-out copy.
|
| | |
|
| | |
|
| |
|
|
| |
git-version-gen is happier this way.
|
| | |
|
| | |
|
| | |
|
| |
|
