From: Bruno Haible <bruno@clisp.org>
To: bug-gnulib@gnu.org
Subject: maintainer-makefile: Determine gnulib's location on disk correctly
Date: Mon, 30 Jan 2023 03:04:41 +0100 [thread overview]
Message-ID: <30204496.beO8tFBq6J@nimes> (raw)
The sc_copyright_check syntax check is hitting me badly, due to an incorrect
determination of 'gnulib_dir' in maint.mk.
What I've done is:
- set GNULIB_SRCDIR to point to my current Gnulib checkout,
- checked out GNU grep from git,
- ran './bootstrap --gnulib-srcdir=$GNULIB_SRCDIR --no-git' so that it
actually uses this gnulib, instead of the gnulib subdirectory that
I used in some previous builds in 2017,
- run './configure && make dist'
It stops like this:
...
copyright_check
./gnulib/lib/version-etc.c
maint.mk: out of date copyright in ./gnulib/lib/version-etc.c; update it
make[4]: *** [maint.mk:1287: sc_copyright_check] Error 1
make[4]: Leaving directory '/media/develdata/devel/GREP/grep'
The copyright of ./gnulib/lib/version-etc.c is 2017. It's not up-to-date,
but it's not the gnulib checkout that I'm using. The one I'm using, I have
indicated through the GNULIB_SRCDIR environment variable.
This patch fixes it. The older commit, from Simon on 2021-01-26, said
"Mimic bootstrap's gnulib-srcdir guessing."
and `bootstrap --help` (of the older bootstrap version in GNU grep) says
" * If this package is in a git repository with a 'gnulib' submodule
configured, then that submodule is initialized and updated and sources
are fetched from there. If $GNULIB_SRCDIR is set (directly or via
--gnulib-srcdir) and is a git repository, then it is used as a reference."
but that is not what it actually does: In my case, the 'gnulib' submodule
existed and was configured *and* GNULIB_SRCDIR was set, and 'bootstrap'
did NOT update it. This wrong --help output is one of the things that I
fixed on 2022-07-24.
The new logic in maint.mk reflects the (corrected and now correctly
documented) logic in 'bootstrap'.
2023-01-29 Bruno Haible <bruno@clisp.org>
maintainer-makefile: Determine gnulib's location on disk correctly.
* top/maint.mk (gnulib_dir): Give priority to $(GNULIB_SRCDIR) over
$(srcdir)/gnulib.
diff --git a/top/maint.mk b/top/maint.mk
index 034e25be3d..44f3db9d9d 100644
--- a/top/maint.mk
+++ b/top/maint.mk
@@ -64,10 +64,10 @@ VC_LIST = $(srcdir)/$(_build-aux)/vc-list-files -C $(srcdir)
# You can override this variable in cfg.mk if your gnulib submodule lives
# in a different location.
-gnulib_dir ?= $(shell if test -f $(srcdir)/gnulib/gnulib-tool; then \
- echo $(srcdir)/gnulib; \
+gnulib_dir ?= $(shell if test -n "$(GNULIB_SRCDIR)" && test -f "$(GNULIB_SRCDIR)/gnulib-tool"; then \
+ echo "$(GNULIB_SRCDIR)"; \
else \
- echo ${GNULIB_SRCDIR}; \
+ echo $(srcdir)/gnulib; \
fi)
# You can override this variable in cfg.mk to set your own regexp
reply other threads:[~2023-01-30 2:04 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.gnu.org/mailman/listinfo/bug-gnulib
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=30204496.beO8tFBq6J@nimes \
--to=bruno@clisp.org \
--cc=bug-gnulib@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).