Re: argp: Correct documentation
You can do advocacy of GNU and the GNU system in many places. But lists of platforms in *technical documentation* are not the proper place to do so. That is incorrect, it is an excellent place to do so. Our guidelines also do not differentiate between technical documentation, and other places. > We avoid > mentioning them out of principle, since we do not want to promote > them. Are you saying that it *promotes* HP-UX, to state that HP-UX 11 lacks a certain variable? Mentioning irrelevant, or obsolete platforms, does proomote them. Please refer to the GNU Coding Standards, and GNU Maintainer guide. I think it is best that this is brought up with RMS directly, since that you're being antagonistic as per usual.
Re: argp: Correct documentation
The gnulib documentation calls the GNU based systems for "glibc platform"; I suggested that this was changed but only got unfriendly pushback from Bruno. The gnulib manual uses the phrase to detonate a list of operating systems, for example Portability problems fixed by Gnulib: @itemize @item This variable is missing on all non-glibc platforms: macOS 11.1, FreeBSD 13.0, NetBSD 9.0, OpenBSD 6.7, Minix 3.1.8, AIX 5.1, HP-UX 11, IRIX 6.5, Solaris 11.4, Cygwin 2.9, mingw, MSVC 14, Android 9.0. @end itemize Portability problems not fixed by Gnulib: @itemize @end itemize The suggestion was to use "GNU systems" or similar wording. Alfred M. Szmidt wrote: > >Alfred M. Szmidt wrote: >> Does a system become a `glibc platform' if one uses gnulib? > >No, it doesn't, because > - the term 'platform' or 'system' denotes the basic OS + base libraries, > - Gnulib does not emcompass glibc. > > Ok, so you agree that there is no such thing as a "glibc platform", > seeing that glibc is not "basic OS + base libraries". So it makes > sense to not use that term. It's pointless to do hairsplitting like this. We use the term "platform" extensively in the Gnulib documentation for 15 years: https://www.gnu.org/software/gnulib/manual/html_node/Target-Platforms.html and no one has ever asked for a definition, nor reported that this documentation was ambiguous. >> I could not find this decision in those two references, both are pages >> from Debian, and nothing from RMS on the topic. > >You can trust my memory on this statement, even though I can't find >the precise mail where RMS announced this decision. It was probably >in 2001. > > It has little to do with trust, if there is such an "announcment" it > would be useful to put it up on gnu.org. There is at least this FAQ on gnu.org: https://www.gnu.org/non-gnu/glibc-bsd/ > What matters is the GNU project, and what we say. You can do advocacy of GNU and the GNU system in many places. But lists of platforms in *technical documentation* are not the proper place to do so. > The text over all is messy on other points as well: > >Portability problems fixed by Gnulib: >@itemize > +@item > +This variable is missing on all non-glibc platforms: > +macOS 11.1, FreeBSD 13.0, NetBSD 9.0, OpenBSD 6.7, Minix 3.1.8, AIX 5.1, HP-UX 11, IRIX 6.5, Solaris 11.4, Cygwin 2.9, mingw, MSVC 14, Android 9.0. > > ... > > Does this mean that FreeBSD 12 supports it? What amount Minix 2? These questions are irrelevant. Any Gnulib user will want portability to FreeBSD versions ⥠X, where X depends. Therefore, if they want portability to FreeBSD 12, they will also want portability to FreeBSD 13. If a feature is not available on FreeBSD 13, it therefore does not matter whether it is present on FreeBSD 12, 11, 6.4, or 1.0. > Are > these "all" the platforms, seeing that it is an exhaustive list in > detail. See https://www.gnu.org/software/gnulib/manual/html_node/Target-Platforms.html > We avoid > mentioning them out of principle, since we do not want to promote > them. Are you saying that it *promotes* HP-UX, to state that HP-UX 11 lacks a certain variable? > Why isn't freedos listed? See https://www.gnu.org/software/gnulib/manual/html_node/Target-Platforms.html > Is this list manually updated each, > and every time those companies or projects make a release? That seems > like useless churn. Please leave it up to me, to decide on what tasks/patches I spend or waste my time. I don't comment publicly on the cost/benefit ratio of your tasks/ patches either. Bruno
Re: argp: Correct documentation
Alfred M. Szmidt wrote: > Does a system become a `glibc platform' if one uses gnulib? No, it doesn't, because - the term 'platform' or 'system' denotes the basic OS + base libraries, - Gnulib does not emcompass glibc. Ok, so you agree that there is no such thing as a "glibc platform", seeing that glibc is not "basic OS + base libraries". So it makes sense to not use that term. I suspect that you find it clear since you came up with it, to others it is not as clear. > I could not find this decision in those two references, both are pages > from Debian, and nothing from RMS on the topic. You can trust my memory on this statement, even though I can't find the precise mail where RMS announced this decision. It was probably in 2001. It has little to do with trust, if there is such an "announcment" it would be useful to put it up on gnu.org. I do not recall any such thing from RMS having been announced around that time, or at all. > - Is Alpine Linux a GNU system? (It uses musl libc instead of glibc.) [4] > > No, Alpine is not based on the GNU system ... > > - Is Windows with WSL and a GNU distro a GNU system? [5][6] > > Windows is the operating system here, that is what your computer is > running. Just becaues you run another operating system inside an > existing one, doesn't mean that one becomes the other. While you can answer these questions (and I agree with the answers), the mere fact that these questions appear on reddit shows that the term "GNU system" is not as unambiguous as one might wish. What reddit, or some other nasty fourm shows does not make something ambiguous. What matters is the GNU project, and what we say. Seeing that you yourself could answer these two questions, we can agree that there is little ambigiousity in what constitutes the GNU system. Overall, the GNU system is not "based on the 'glibc platfrom'", and lets avoid using that term. We have far clearer ones, like the 'GNU system' to use that has wide acceptance in the GNU project, but also outside. The text over all is messy on other points as well: Portability problems fixed by Gnulib: @itemize +@item +This variable is missing on all non-glibc platforms: +macOS 11.1, FreeBSD 13.0, NetBSD 9.0, OpenBSD 6.7, Minix 3.1.8, AIX 5.1, HP-UX 11, IRIX 6.5, Solaris 11.4, Cygwin 2.9, mingw, MSVC 14, Android 9.0. ... Does this mean that FreeBSD 12 supports it? What amount Minix 2? Are these "all" the platforms, seeing that it is an exhaustive list in detail. Will one list other obscure non-free platforms? We avoid mentioning them out of principle, since we do not want to promote them. Why isn't freedos listed? Is this list manually updated each, and every time those companies or projects make a release? That seems like useless churn. Etc
Re: argp: Correct documentation
>+This variable is missing on all non-glibc platforms: > > How about we just say "non-GNU systems" -- the majority of operating > systems in the world are 'non-glibc platforms', and there is no > platform that is called 'glibc'. Our system is called GNU after > all... First, "glibc platforms" and "GNU systems" are not the same thing. True, since there is nothing like a "glibc platform", it is a bad term that has no good meaning. The text reads strangley anyway, if you use gnulib (or via some other means, in the case of argp there used to be a libargp that was portable across many systems) on a operating system that does not use the GNU C Library, then .. it does exist. But the text claims that it does not. Does a system become a `glibc platform' if one uses gnulib? Seeing that all or most of the things glibc provides, so does gnulib. * RMS decided that the NetBSD kernel, plus the NetBSD libc, plus GNU userland is a GNU system and to be called "GNU/NetBSD". [1] Whereas the NetBSD kernel, plus glibc, plus GNU userland is to be called "GNU/kNetBSD". [2] I could not find this decision in those two references, both are pages from Debian, and nothing from RMS on the topic. * According to the definition of GNU system [3], it looks like a distro based on Linux, glibc, and lots of proprietary software would not be a GNU system. Second, in technical documentation, I prefer to have unambiguous terms, and there is ambiguity in the term "GNU system": We have plenty of texts that clear up any ambiguity, where as there is nothing on 'glibc platform'. There is little ambiguity about what it means, and even if it did the little extra is worth to mention our own operating system in a list of other operating systems. - Is Alpine Linux a GNU system? (It uses musl libc instead of glibc.) [4] No, Alpine is not based on the GNU system, much like Android. See https://www.gnu.org/philosophy/android-and-users-freedom.en.html - Is Windows with WSL and a GNU distro a GNU system? [5][6] Windows is the operating system here, that is what your computer is running. Just becaues you run another operating system inside an existing one, doesn't mean that one becomes the other.
Re: argp: Correct documentation
Portability problems fixed by Gnulib: @itemize +@item +This variable is missing on all non-glibc platforms: How about we just say "non-GNU systems" -- the majority of operating systems in the world are 'non-glibc platforms', and there is no platform that is called 'glibc'. Our system is called GNU after all...
Re: license: comma or semicolon?
The historical reason for this is that GNU GPL version 2 used a semi-colon, while GNU GPL version 3 changed it to a comma. When the license notices got updated, the normal way of doing so was to replace 2 with 3, and not much more in source files or running M-x copyright-update or something (I forgot the name, or even if it existed) in Emacs.
Re: egrep, fgrep, and install-info
2) For 'install-info', what would be the replacement? Even though Automake knows how to handle its absence [1], it would be good to know. On systems where install-info is lacking, we simply don't install a node entry in the dir file and continue with the post-install. This is a slightly different behaviour than what we have for other programs which we generally consider a hard error. E.g., if you don't have grep -E, and no egrep or some other such ... you're shit outta luck.
Re: cmp/diff
On 12/26/20 4:07 PM, Alfred M. Szmidt wrote: > install-info does not have an replacement, like say egrep/fgrep -- > this is how we install a dir entry for a info manual. Removing > install-info would be a regression. In practice, GNU installation procedures use install-info in the way that's described in the proposed patch: they test whether install-info is available, and if so they use it. The make-stds.texi file already recomments this practice in its "Standard Targets" section. The proposed patch is doing merely making make-stds coherent; it's not advocating any change to existing best practice for install-info. The example entry in '(standards) Standard Targets' is I think orthogonal, it is for the benefit of the user where installing the node entry is not considered an error but only a "warning" (and then some extra checks because we want to treat real errors as such). Which is quite different from the behaviour we have for other programs -- if you are missing md5sum (or even fgrep) you'd get a hard error. So I really don't see how it makes it coherent, having install-info as a "safe" requirement makes logical sense since our prefered documentation format is info (the original rationale for removing install-info was "its GNU specific"), and why we do some extra sanity checks is to be nice to the user. The change also removes install-info the only rule where it makes sense to use install-info -- post-installation.
Re: cmp/diff
>> Looking at that list now, the only obvious tool to remove is egrep, >> since 'grep -E' subsumes it nowadays. > Yes, I think that should be dropped. Maybe from usage in scripts or Makefile, but from a users point these do not replace "grep -E" or "grep -F" which are far more annoying to type than egrep or fgrep.
Re: cmp/diff
> What about 'install-info'? It is quite GNU-specific. Nothing in > gnulib appears to refer to it (except for the make-stds manual..). install-info is specific to GNU yes, the GNU standards are for the GNU system and GNU project after all. install-info does not have an replacement, like say egrep/fgrep -- this is how we install a dir entry for a info manual. Removing install-info would be a regression.
git-version-gen minor fix
Seeing that --prefix and --fallback have a mandatory argument, it should be mentioned in --help. The following patch does that. diff --git a/build-aux/git-version-gen b/build-aux/git-version-gen index 0278a9c..47d6576 100755 --- a/build-aux/git-version-gen +++ b/build-aux/git-version-gen @@ -1,6 +1,6 @@ #!/bin/sh # Print a version string. -scriptversion=2012-12-31.23; # UTC +scriptversion=2014-06-19.19; # UTC # Copyright (C) 2007-2014 Free Software Foundation, Inc. # @@ -85,8 +85,9 @@ Print a version string. Options: - --prefix prefix of git tags (default 'v') - --fallback fallback version to use if \git --version\ fails + --prefix PREFIXprefix of git tags (default 'v') + --fallback VERSION + fallback version to use if \git --version\ fails --help display this help and exit --version output version information and exit
Re: git-merge-changelog
The only special program in gnulib is git-merge-changelog; though now that I think about it, it makes more sense to split out git-merge-changelog into a seperate project. Yes, you're entirely right. The project has been created already: http://savannah.gnu.org/projects/vc-changelog/ It is empty, is the idea to only have git-merge-changelog there? I haven't moved it yet, due to lack of time / more urgent priorities. Would you like to help moving it? Wouldn't it be better to put it in vc-dwim?
git-merge-changelog in bin_PROGRAMS
It seems that git-merge-changelog is added to bin_PROGRAMS in the generated lib/Makefile.am, which causes it to get installed in exec_prefix/bin (at least in inetutils). Not sure why though; I couldn't find anything that struck me in the ChangeLog. Anyone know?
Re: git-merge-changelog in bin_PROGRAMS
It seems that git-merge-changelog is added to bin_PROGRAMS in the
generated lib/Makefile.am, which causes it to get installed in
exec_prefix/bin (at least in inetutils). Not sure why though
It's necessary so that the installation instructions at the top of
this file work. make install should install the program in
${bindir}.
`make install' must _not_ install git-merge-changelog, this is a
internal file to gnulib, and using gnulib in a package must not cause
installation of extra files from gnulib. The crux is that gnulib
seems to have changed this, somewhere to install git-merge-changelog
in bindir. This is a serious regression; I'll roll a new inetutils
release for now, but we need to fix this in some sensible manner.
The question is: why does inetutils contain this program? Simon
wrote in [1]:
! I haven't seen any other project include git-merge-changelog,
! which makes some sense as it seems to be more of a developer tool
! not strictly related to building the project itself.
Moreover only the committers need the tools. People who use the
anonymous git checkout and don't contribute don't need it.
So that one can merge changelog entries without having to install it,
since git is a DVCS, anyone can commit and pull which causes marge
conflicts for ChangeLog entries at times. There are multiple modules
that are only useful to maintainers, gnu-web-doc-update, gnupload, and
those should not get installed either in bindir simply because one
includes the module either.
Cheers!
Re: git-merge-changelog in bin_PROGRAMS
What about this? I haven't tried it, but I think it should work. The only special program in gnulib is git-merge-changelog; though now that I think about it, it makes more sense to split out git-merge-changelog into a seperate project. 2012-01-03 Alfred M. Szmidt a...@gnu.org * modules/git-merge-changelog (bin_PROGRAMS): Variable renamed to ... (bin_nodist_PROGRAMS): ... this. diff --git a/modules/git-merge-changelog b/modules/git-merge-changelog index 857a8bc..aa05103 100644 --- a/modules/git-merge-changelog +++ b/modules/git-merge-changelog @@ -28,7 +28,7 @@ memcmp configure.ac: Makefile.am: -bin_PROGRAMS = git-merge-changelog +bin_nodist_PROGRAMS = git-merge-changelog git_merge_changelog_LDADD = libgnu.a @LIBINTL@ $(LIBTHREAD) Include:
Re: [bug-inetutils] bootstrap is broken
As usual, since I've changed things, I'll wait for review/ACK from you, Alfred, before pushing. Thanks Jim! Works for me, please push.
Re: [bug-inetutils] bootstrap is broken
Mats reported the following problem when bootstraping inetutils with the latest gnulib/ (2011-12-17): configure.ac:152: error: possibly undefined macro: gl_FUNC_READLINE configure.ac:176: error: possibly undefined macro: AC_DEFINE This is due that we set ACLOCAL_FLAGS in bootstrap.conf, the change that introduced this is: * build-aux/bootstrap (AUTOPOINT, AUTORECONF): Factor out definitions. Run autopoint and libtoolize *before* gnulib-tool. After it, run an abbreviated autoreconf, rather than a loop around all tools. (slirp, bt_mark_as_generated): Remove functions. Since ACLOCAL_FLAGS isn't passed to autoreconf, I suggest the following fix. 2011-12-21 Alfred M. Szmidt a...@gnu.org * build-aux/bootstrap (AUTOPOINT): Pass ACLOCAL_FLAGS when invoking autoreconf. --- build-aux/bootstrap~ +++ build-aux/bootstrap @@ -1,6 +1,6 @@ #! /bin/sh # Print a version string. -scriptversion=2011-12-17.15; # UTC +scriptversion=2011-12-20.23; # UTC # Bootstrap this package from checked-out sources. @@ -821,9 +821,9 @@ find $m4_base $source_base \ # Tell autoreconf not to invoke autopoint or libtoolize; they were run above. echo running: AUTOPOINT=true LIBTOOLIZE=true \ -$AUTORECONF --verbose --install --no-recursive -I $m4_base +$AUTORECONF --verbose --install --no-recursive -I $m4_base $ACLOCAL_FLAGS AUTOPOINT=true LIBTOOLIZE=true \ -$AUTORECONF --verbose --install --no-recursive -I $m4_base \ +$AUTORECONF --verbose --install --no-recursive -I $m4_base $ACLOCAL_FLAGS\ || exit 1 # Get some extra files from gnulib, overriding existing files.
sc_prohibit_stddef_without_use works incorrectly
The following syntax-check is broken,
_stddef_syms_re = NULL|offsetof|ptrdiff_t|size_t|wchar_t
# Prohibit the inclusion of stddef.h without an actual use.
sc_prohibit_stddef_without_use:
h='stddef.h'\
re='\($(_stddef_syms_re)) *\(' \
$(_sc_header_without_use)
This tries to match NULL (, NULL can exist in other situations:
gettimeofday (tv, NULL);
which will not be matched by the above, the same goes for ptrdiff_t,
size_t and wchar_t (as variable type specifiers).
Re: sc_prohibit_stddef_without_use works incorrectly
Thanks Jim!
Re: config.h double inclusion
I think that autoconf should have the guard for double inclusion. Autoconf does not need to provide a double-inclusion guard for config.h, because those packages that need it can get it through use of AH_TOP and AH_BOTTOM. That is not a reason to not include such a guard.
config.h double inclusion
Hey, in inetutils we have a problem of where sometimes config.h is included twice, but gnulib redefines a macro that was already specified in config.h, for example gnulib:lib/argp.h: #include config.h -- #define HAVE_DECL_PROGRAM_INVOCATION_NAME 0 #define GNULIB_PROGRAM_INVOCATION_NAME 1 ... #include argp.h -- #ifdef GNULIB_PROGRAM_INVOCATION_NAME extern char *program_invocation_name; # undef HAVE_DECL_PROGRAM_INVOCATION_NAME # define HAVE_DECL_PROGRAM_INVOCATION_NAME 1 #endif Which ends up redefining HAVE_DECL_PROGRAM_INVOCATION_NAME to 1; all good so far since program_invocation_name is provided by gnulib. A bit later, we do: #include libinetutils.h which will cause warnings like: ../config.h:561:1: warning HAVE_DECL_PROGRAM_INVOCATION_NAME redefined In file included from syslogd.c:100: ../lib/argp.h:431:1: warning: this is the location of the previous definition I'm thinking that maybe config.h should be generated with a double inclusion guard (#ifndef CONFIG_H, #define CONFIG_H, ..., #endif)? It is easy enough to do it on a per project basis, but I see now reason why this isn't the default. Thoughts? Cheers, Alfred.
Re: bug#8881: config.h double inclusion
I'm thinking that maybe config.h should be generated with a double inclusion guard But the general rule is that config.h must always be included first, no? So there shouldn't ever be a possibility of including it twice. It might be better to have config.h do something like this: #ifdef CONFIG_H # error config.h included twice #endif #define CONFIG_H Warning: Quite a few misbehaving packages actually install their config.h. One should send bug reports for those cases, since it is just broken.
Re: config.h double inclusion
I'm thinking that maybe config.h should be generated with a double inclusion guard But the general rule is that config.h must always be included first, no? So there shouldn't ever be a possibility of including it twice. Right, which is the case in inetutils in all places where we use config.h. The problem pops up when you have another header file that includes config.h (as the first thing) to use macros from it (for libinetutils.h it is PACKAGE_BUGREPORT and HAVE_FORK or something). It might be better to have config.h do something like this: #ifdef CONFIG_H # error config.h included twice #endif #define CONFIG_H Not against it, but I think that: #include config.h #include argp.h /* or some other gnulib header... */ #include config.h /* via some internal #include; where it is the first line */ should be valid to do. A bit later, we do: #include libinetutils.h which will cause warnings like: ../config.h:561:1: warning HAVE_DECL_PROGRAM_INVOCATION_NAME redefined Sp libinetutils.h includes config.h? Then that is a problem. One possible fix is to arrange for libinetutils.h to be built from libinetutils.in.h, the same way that (for example) stdint.h is built from stdint.in.h in gnulib. Right, sorry if I wasn't clear. I would prefer not to, the fix that I might go for if we can't fix this in autoconf would be: to simply do: #ifndef HAVE_CONFIG_H #error config.h hasn't been included; please include it #endif But I think that autoconf should have the guard for double inclusion.
Re: [bug-inetutils] inetutils-1.8: ftp build error
I am forwarding an error reported on the inetutils mailing list. The problem is that readline 6.x exports `xmalloc' and `xrealloc', and it causes a linker error when used together with gnulib. Probably readline shouldn't export these symbols, but I think it should be possible somehow to workaround this problem in gnulib as well. What do you think? This is a known bug, the reason if I recall is that readline exports xmalloc and xrealloc is to allow programs to hook their own version into readline. So the readline maintainer has declined any fixes for this.
Re: [bug-inetutils] inetutils-1.8: ftp build error
This is a known bug, the reason if I recall is that readline exports xmalloc and xrealloc is to allow programs to hook their own version into readline. So the readline maintainer has declined any fixes for this. This is a severe bug. It makes readline useless for any project that uses gnulib. I should note that this was from my recollection, but I agree, it is painful. Here is what Chet had to say on the topic: Re: [Bug-readline] [PATCH] hide symbols for helper xmalloc/xrealloc/xfree functions | libreadline is exporting symbols for its internal helper | xmalloc/xrealloc/xfree functions. These function names are | quite common, but might not behave exactly the same way as | readline expects. | | I want applications to have the option to override these functions if | they so choose.
Re: setproctitle()
Can you simply declare the copyright to be LGPLv2+? Many modules are already LGPLv2+ (see modules/*). I could if I were just releasing the code myself, but if the FSF needs a copyright assignment, does that not imply that I no longer get to choose the copyright? As original author, you get to choose the license that will be used within gnulib. I see nothing wrong with you declaring that the setproctitle module is LGPLv2+. If the FSF is the copyright holder, then there is no (legal) need to ask the original author about permission to relicense the work. It might be a nice thing to do, but if the original author says no for some reason, the FSF can still relicense the work; they are the copyright holders.
Re: announce-gen -- not flexible enough
Ping? From 00c33e8b07ae06d2c09394c3cf2892063f0c2fc6 Mon Sep 17 00:00:00 2001 From: Alfred M. Szmidt a...@gnu.org Date: Sat, 5 Dec 2009 20:44:20 +0100 Subject: [PATCH] Allow for per-project post-release administrative tasks. --- ChangeLog|8 top/maint.mk | 10 +- 2 files changed, 17 insertions(+), 1 deletions(-) diff --git a/ChangeLog b/ChangeLog index 3c01809..900736b 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,11 @@ +2009-12-05 Alfred M. Szmidt a...@gnu.org + + * top/maint.mk (alpha, beta, stable): Split out project specific + rules into `default-post-release-administrivia'. + (post-release-hook): New variable. + (post-release-administrivia, default-post-release-administrivia): + New targets. + 2009-12-05 Bruno Haible br...@clisp.org * lib/progname.h (set_program_name): Clarify specification. diff --git a/top/maint.mk b/top/maint.mk index 1ed1541..262a69f 100644 --- a/top/maint.mk +++ b/top/maint.mk @@ -82,6 +82,9 @@ endif today = $(shell date +%Y-%m-%d) news-check-regexp ?= '^\*.* $(VERSION_REGEXP) \($(today)\)' +# Override this in cfg.mk if you have different post-release procedures. +post-release-hook ?= default-post-release-administrivia + # Prevent programs like 'sort' from considering distinct strings to be equal. # Doing it here saves us from having to set LC_ALL elsewhere in this file. export LC_ALL = C @@ -761,12 +764,17 @@ alpha beta stable: $(local-check) writable-files no-submodule-changes $(MAKE) news-check $(MAKE) distcheck $(MAKE) dist XZ_OPT=-9ev + $(MAKE) post-release-administrivia + $(MAKE) -s emit_upload_commands RELEASE_TYPE=$@ + +post-release-administrivia: $(post-release-hook) + +default-post-release-administrivia: $(MAKE) -s announcement RELEASE_TYPE=$@ /tmp/announce-$(my_distdir) if test -d $(release_archive_dir); then \ ln $(rel-files) $(release_archive_dir); \ chmod a-w $(rel-files); \ fi - $(MAKE) -s emit_upload_commands RELEASE_TYPE=$@ echo $(VERSION) $(prev_version_file) $(MAKE) update-NEWS-hash perl -pi -e '$$. == 3 and print $(noteworthy)\n\n\n' NEWS -- 1.6.5.2
Re: announce-gen -- not flexible enough
- avoid breaking the announcement-generating code: Once you move the $(MAKE) -s announcement release_typ...@... command into another rule, $@ is no longer valid. Instead, rely on RELEASE_TYPE being set in the environment. Ah, yeah, I had fixed that in a different commit that I forgot about, thanks!
Re: update copyrights?
You mean, changing
Copyright (C) 1999, 2000, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009
Free Software Foundation, Inc.
to
Copyright (C) 1999-2009 Free Software Foundation, Inc.
?
It's allowed by current FSF rules, but the fact that the FSF did
not want it for 15 years does not give me a comfortable
feeling. Rather, I fear that, with a small percentage probability,
the rule may change again, in the opposite direction. So I would
prefer to wait for 1 or 2 more years before doing that.
Since when is this allowed? The GNU maintainer guide say explicitly
that it isn't:
| Do not abbreviate the year list using a range; for instance, do not
| write @samp{1996--1998}; instead, write @samp{1996, 1997, 1998}.
Re: news-date-check tweaking..
If you don't mind, sending git format-patch output (i.e with a log entry) and removing the space-before-TAB ^^ would be nice. Will try to do so in the future.
announce-gen -- not flexible enough
announce-gen is lovley, but it is very inflexible if you use a different format for NEWS. In inetutils, we use something like: | December 27, 2008 | Version 1.6: | | * Fixed FOO in BAR. | | * Added BAZ. | | October 21, 2006 | Version 1.5: | | ... I am not sure what a way one should fix announce-gen to be more flexible, maybe just being able to specify a `start' regexp, and a `end' regexp would be enough. So in the above example, we could use something like: --start-regexp=^Version --end-regexp=^ $ Or maybe just a switch to skip looking at NEWS, and add a `FIXME: Add noteworthy changes here' where the news entries go. Alas, I don't know enough perl to hack announce-gen.
Re: announce-gen -- not flexible enough
Alfred M. Szmidt wrote: announce-gen is lovley, but it is very inflexible if you use a different format for NEWS. In inetutils, we use something like: | December 27, 2008 | Version 1.6: | | * Fixed FOO in BAR. | | * Added BAZ. | | October 21, 2006 | Version 1.5: | | ... I am not sure what a way one should fix announce-gen to be more flexible, maybe just being able to specify a `start' regexp, and a `end' regexp would be enough. So in the above example, we could use something like: --start-regexp=^Version --end-regexp=^ $ Or maybe just a switch to skip looking at NEWS, and add a `FIXME: Add noteworthy changes here' where the news entries go. Alas, I don't know enough perl to hack announce-gen. Yes, it is rigid. announce-gen started as a way to help automate some repetitive tasks. Now, you see there is some benefit to conforming. In a few projects (gzip, diff, grep), I've simply begun using the format required by the tools that operate on NEWS. Note that there is at least one other tool that knows the form of NEWS entries: build-aux/do-release-commit-and-tag Your options: - use the suggested format for new NEWS entries - insert that part of NEWS manually into your announcement email - change both announce-gen and do-release-commit-and-tag Changing the format is just cumbersome and not really worthwhile; asking each and every project to follow this strict format is unrealistic as well. Inserting things manually is impossible, since `make alpha/stable' will fail hard since there is no way to ignore those checks. For the later, you must change announce-gen/do-release-commit-and-tag anyway. I do not see what exactly you are suggesting that I didn't already suggest, I was looking for input on the `right way' of doing things.
Re: announce-gen -- not flexible enough
You said you would not be changing announce-gen, so isn't it moot?
I said that I did not have enough knowledge to hack announce-gen since
it is written in perl; I cannot do something when I don't know how to
do it.
I pointed out that yet another script parses (and rewrites) NEWS
and would need similar changes.
Right, so something similar needs to be added there. I can do it for
do-release-commit-and-tag, since that is in shell script. Attached is
a quick hack, that I didn't bother testing.
Is there is someone who can add a --skip-news option to announce-gen,
(and a way of specifying that you don't want NEWS to be inserted in
cfg.mk; though I can do that)? If not, the best solution is to remove
announce-gen from gnulib, since it is not flexible enough for other
projets to use; asking everyone to use the same format for a file that
has been free-hand for 20+ years is not going to work.
diff --git a/build-aux/do-release-commit-and-tag
b/build-aux/do-release-commit-and-tag
index ba0c1b2..abe463d 100755
--- a/build-aux/do-release-commit-and-tag
+++ b/build-aux/do-release-commit-and-tag
@@ -3,7 +3,7 @@
# controlled .prev-version file, automate the procedure by which we record
# the date, release-type and version string in the NEWS file. That commit
# will serve to identify the release, so apply a signed tag to it as well.
-VERSION=2009-11-06.10 # UTC
+VERSION=2009-12-05.17 # UTC
# Note: this is a bash script (could be zsh or dash)
@@ -28,6 +28,8 @@ ME=`basename $0`
warn() { printf '%s: %s\n' $ME $* 2; }
die() { warn $*; exit 1; }
+opt_skip_news=false
+
help_version()
{
case $1 in
@@ -41,7 +43,7 @@ a signed tag. Run it from your project's the top-level
directory.
Requirements:
- you use git for version-control
-- a NEWS file, with line 3 identical to this:
+- optionally a NEWS file, with line 3 identical to this:
* Noteworthy changes in release ?.? (-??-??) [?]
- a version-controlled .prev-version file
@@ -69,6 +71,10 @@ There is NO WARRANTY, to the extent permitted by law.
EOF
exit ;;
+ --skip-news)
+ opt_skip_news=true
+ break ;;
+
*) die unrecognized option: $1;;
esac
}
@@ -103,10 +109,12 @@ esac
pkg=$(sed -n 's/^PACKAGE = \(.*\)/\1/p' Makefile) \
|| die 'failed to determine package name from Makefile'
-# simple check: no question marks on line 3 of NEWS
-noteworthy='* Noteworthy changes in release'
-test $(sed -n 3p NEWS) = $noteworthy ?.? (-??-??) [?] \
- || die 'line 3 of NEWS looks fishy!'
+if [ $opt_skip_news == false ]; then
+# simple check: no question marks on line 3 of NEWS
+noteworthy='* Noteworthy changes in release'
+test $(sed -n 3p NEWS) = $noteworthy ?.? (-??-??) [?] \
+|| die 'line 3 of NEWS looks fishy!'
+if
# No dirt allowed.
case $(git diff-index --name-only HEAD) in
@@ -114,19 +122,22 @@ case $(git diff-index --name-only HEAD) in
*) die 'this tree is dirty; commit your changes first';;
esac
-# update NEWS to have today's date, plus desired version number and $type
-perl -MPOSIX -ni -e 'my $today = strftime %F, localtime time;' \
- -e 'my ($type, $ver) = qw('$type $ver');' \
- -e 'my $pfx = '$noteworthy';' \
- -e 'print $.==3 ? $pfx $ver ($today) [$type]\n : $_' \
- NEWS || die 'failed to update NEWS'
+if [ $opt_skip_news == false ]; then
+# update NEWS to have today's date, plus desired version number and $type
+perl -MPOSIX -ni -e 'my $today = strftime %F, localtime time;' \
+-e 'my ($type, $ver) = qw('$type $ver');' \
+-e 'my $pfx = '$noteworthy';' \
+-e 'print $.==3 ? $pfx $ver ($today) [$type]\n : $_' \
+NEWS || die 'failed to update NEWS'
+fi
# Ensure the current branch name is master:
curr_br=$(git rev-parse --symbolic-full-name HEAD)
test $curr_br = refs/heads/master || die not on master
-
-printf version $ver\n\n* NEWS: Record release date.\n \
-| git commit -F - -a || die 'git commit failed'
+if [ $opt_skip_news == false ]; then
+printf version $ver\n\n* NEWS: Record release date.\n \
+| git commit -F - -a || die 'git commit failed'
+fi
git tag -s -m $pkg $ver v$ver HEAD || die 'git tag failed'
# Local variables:
underscore vs. hyphen
What should be used in variable names for maint.mk, a hyphen, or underscore? Some variables use underscore, and some use hyphens... Which is very confusing.
news-date-check tweaking..
In inetutils we use something like `Version 1.6 (2008-12-27):' in
NEWS, but news-date-check hardcodes it, and expects something else, `*
FOO 1.6 (2008-12-27)', would this be acceptable for overriding the
format?
diff --git a/top/maint.mk b/top/maint.mk
index c3fab9a..18f63af 100644
--- a/top/maint.mk
+++ b/top/maint.mk
@@ -71,6 +71,10 @@ gnu_ftp_host-beta = alpha.gnu.org
gnu_ftp_host-stable = ftp.gnu.org
gnu_rel_host ?= $(gnu_ftp_host-$(RELEASE_TYPE))
+# Override this in cfg.mk if you are using a different format in your
+# NEWS file.
+news-date-regexp ?= '^\*.* $(VERSION_REGEXP) ('$$today')'
+
ifeq ($(gnu_rel_host),ftp.gnu.org)
url_dir_list ?= http://ftpmirror.gnu.org/$(PACKAGE)
else
@@ -570,7 +574,7 @@ sc_makefile_check:
news-date-check: NEWS
today=`date +%Y-%m-%d`; \
- if head $(srcdir)/NEWS | grep '^\*.* $(VERSION_REGEXP) ('$$today')' \
+ if head $(srcdir)/NEWS | grep $(news-date-regexp) \
/dev/null; then\
:;\
else\
Re: [PATCH] Add missing dependency to gnulib
Giuseppe drank one beer that he couldn't handle. something against this trivial patch? If those dependencies are needed, go ahead. If not, I see no reason to add them. It fixes make check. Giuseppe From 48baa84f12699ff6b3ee50e2b2211cce503f08ca Mon Sep 17 00:00:00 2001 From: Giuseppe Scrivano gscriv...@gnu.org Date: Thu, 3 Dec 2009 19:27:30 +0100 Subject: [PATCH] Add missing dependency to gnulib --- ChangeLog |4 tests/Makefile.am |2 +- 2 files changed, 5 insertions(+), 1 deletions(-) diff --git a/ChangeLog b/ChangeLog index 8051682..3816557 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,5 +1,9 @@ 2009-12-03 Giuseppe Scrivano gscriv...@gnu.org +* tests/Makefile.am (LDADD): Add missing dependency to gnulib. + +2009-12-03 Giuseppe Scrivano gscriv...@gnu.org + * ftp/cmds.c (domap): Add braces around the else branch. (strup): Remove function. * ftp/ftp.c (hookup): Change `len' type to size_t. diff --git a/tests/Makefile.am b/tests/Makefile.am index 1813a98..6b02c85 100644 --- a/tests/Makefile.am +++ b/tests/Makefile.am @@ -18,7 +18,7 @@ AM_CPPFLAGS = -I$(top_srcdir)/libinetutils -I$(top_srcdir)/lib -LDADD = -L../libinetutils -linetutils +LDADD = -L../libinetutils -linetutils -L../lib -lgnu check_PROGRAMS = localhost TESTS = $(check_PROGRAMS) ping-localhost.sh traceroute-localhost.sh -- 1.6.5
Re: Error message doesn't say, error
Without some clear marker, it is more than a little hard to find. This is line 414 of 619 lines of typescript text: configure.ac:9: version `sharutils_version' doesn't follow Gnits standards That is how error messages in GNU look like, and have looked like for the past 20 years. You can grep for `configure.ac:[0-9]*:` to find all error messages or use compilation-mode in emacs or some similar editor. See `(standards) Errors' for further variants of error messages. Where do you get this error from? I cannot find it in gnulib, sharutils or autoconf. I suspect that the check is actually wrong, and not your version number even though one tends to use a three group for alpha/beta releases, and two groups for real releases. Any help at all would be appreciated. The sharutils build has been broken for a couple of years now. Thanks! By the way, the `latest' version (i.e. old :-) is avaiable at
Re: Error message doesn't say, error
By the way, the `latest' version (i.e. old :-) is avaiable at ... http://gnu.org/software/womb/gnits/
Re: Error message doesn't say, error
configure.ac:9: version `sharutils_version' doesn't follow Gnits standards Where do you get this error from? automake. See info Automake Gnits. I must be missing something utterly obvious, but I cannot find it at all: ~/s $ /bin/grep -ir follow Gnits autoconf automake gnulib sharutils ~/s $ I suspect that the check is actually wrong, I'd need to see the configure.ac in order to confirm. configure.ac: | m4_include([version.m4]) | AC_INIT([GNU sharutils],[sharutils_version],[sharutils_eaddr]) version.m4: | m4_define([sharutils_version], [4.7.1]) | m4_define([sharutils_eaddr], [bug-gnu-ut...@gnu.org])
Re: Error message doesn't say, error
* Alfred M. Szmidt wrote on Sun, Nov 15, 2009 at 06:08:58PM CET: configure.ac:9: version `sharutils_version' doesn't follow Gnits standards Where do you get this error from? automake. See info Automake Gnits. I must be missing something utterly obvious, Line wrapping. :-) D'oh, why didn't I think of that! Thanks. configure.ac: | m4_include([version.m4]) | AC_INIT([GNU sharutils],[sharutils_version],[sharutils_eaddr]) version.m4: | m4_define([sharutils_version], [4.7.1]) | m4_define([sharutils_eaddr], [bug-gnu-ut...@gnu.org]) Oh, that works if you allow m4 traces to see the macro expanded: AC_INIT([GNU sharutils],sharutils_version,[sharutils_eaddr]) although this is probably safer instead: AC_INIT([GNU sharutils],m4_defn([sharutils_version]),[sharutils_eaddr]) Ah, that makes sense. Super thanks Ralf! Bruce, how about this? I'd actually rather see the whole version.m4 mess be removed, but this is a decent fix for now. 2009-11-15 Alfred M. Szmidt a...@gnu.org * configure.ac (AC_INIT): Wrap sharutils_version and sharutils_eaddr around m4_defn. (AM_INIT_AUTOMAKE): Added `gnits'. *** configure.ac.~1.42.~2009-11-14 21:11:07.0 +0100 --- configure.ac2009-11-15 18:35:29.480981168 +0100 *** *** 6,16 dnl FIXME: AC_CHECK_FUNCS([gethostname getwd]) dnl m4_include([version.m4]) ! AC_INIT([GNU sharutils],[sharutils_version],[sharutils_eaddr]) AC_CONFIG_SRCDIR([src/shar.c]) AC_CONFIG_HEADERS([config.h]) ! AM_INIT_AUTOMAKE([1.11 dist-bzip2]) AC_USE_SYSTEM_EXTENSIONS AC_SUBST(DIST_ALPHA) --- 6,16 dnl FIXME: AC_CHECK_FUNCS([gethostname getwd]) dnl m4_include([version.m4]) ! AC_INIT([GNU sharutils],m4_defn([sharutils_version]),m4_defn([sharutils_eaddr])) AC_CONFIG_SRCDIR([src/shar.c]) AC_CONFIG_HEADERS([config.h]) ! AM_INIT_AUTOMAKE([1.11 dist-bzip2 gnits]) AC_USE_SYSTEM_EXTENSIONS AC_SUBST(DIST_ALPHA)
syntax-check: copyright-check
copyright-check doesn't handle multi-line copyright years for texinfo,
the following causes an error that the year list is outdated:
Copyright @copyright{} 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007,
2008, 2009 Free Software Foundation, Inc.
output from syntax-check
it would be nice if the output from syntax-check was compatible with compilation mode so that one can use it to jump to each line easily.
Re: output from syntax-check
Unfortunately, doing that is often at odds with the goals of keeping the test code simple and efficient. If you find small and clean changes that improve matters without inducing inordinate inefficiency even in projects with thousands of source files, please send a patch. Proposed sed extension to help this: http://lists.gnu.org/archive/html/bug-gnu-utils/2009-11/msg00030.html This is a good aproach, but for compilation-mode to work you need the line number as well. Would it be acceptable for syntax-check to use this option if it is included in GNU sed? It wouldn't be compatible with POSIX sed, but one could do a check for the option and only use it if one is using GNU sed.
Re: version-etc tweak
For what it's worth, argp uses `Report bugs to bug-inetut...@gnu.org.', i.e. no package name.
Re: gnu-web-doc-update: new script
Thanks Jim, you just made my day.
Re: inetutils ChangeLog doc/Makefile.am doc/inetuti...
After the patch I installed to inetutils [1], I think actually the only problem is that the gnulib 'fdl' module is a moving target. That doesn't really work, as Karl explained, since the main manual needs to be updated manually whenever there is a FDL version update in gnulib. Right. So in gnulib, I propose we deprecated 'fdl' and ask maintainers to depend directly on 'fdl-1.3' or whatever version they need. Thoughts? I agree.
Re: inetutils ChangeLog doc/Makefile.am doc/inetuti...
The situation with GPL and LGPL is different: A change in the license of the code is a very careful decision. Whereas the FDL license version does not matter for many developers. This explains the difference in module structure. Is this true? The GFDL certainly caught a lot of attention when it came out. Also, if the or any later version clause isn't given, it seems there could be a problem blindly upgrading. At a quick glance, the situation doesn't look that different. I agree, it is a license change, blindly upgradeing the license is always wrong, it doesn't matter if `many developers' do not care. It is partially our job to see that they do care.
Re: Installing gnulib from git
On Wednesday 01 of April 2009 21:32:36 Reuben Thomas wrote: On Wed, 1 Apr 2009, Mike Frysinger wrote: the `git clone` is the install. just execute the gnulib-tool script from there. Right. So I just add the directory to my PATH? Or symlink gnulib-tool into a directory on my PATH? AFAIK it is not useful to install gnulib to your system. Well, Debian packages snapshots of it. It's useful, because gnulib-tool is on PATH. That's all I want really, I want gnulib-tool to be on my PATH and I was asking what I have to do to make that work. Any problem with adding gnulib to your path?
Re: Installing gnulib from git
Well, Debian packages snapshots of it. It's useful, No, it is insanely wrong, defeating the purpose of gnulib and causing impossible-to-track bugs due to out-of-sync sources. But let's not go into that again, you can find the discussions in the archives if you care. :) Well, I asked about it just recently, and the maintainer's main reason is that it's not acceptable to have a package that requires an internet connection to be useful. I agree that it's not a good way to use gnulib, which is why I'm switching to using it from git. You do not need a internet connection to compile a project that uses gnulib, the project will include whatever parts of gnulib it uses.
Re: Installing gnulib from git
Any problem with adding gnulib to your path? I prefer to add executable-only directories. That makes little sense, if you wish to be able to access a directory, then it must be executable.
Re: Installing gnulib from git
What is it that made you expect to see installation instructions? Most GNU packages have an INSTALL file. That's where I look first for installation instructions. gnulib is not something you install. Ever.
Re: fdl-1.3
A symlink?! This can only cause problems: - When 'git' is run on a Windows system (not Cygwin), AFAIK there are no symlinks. In which case, git treats the file as a single line text, whose contents would correspond to the symlink, but the contents of the git tree make it obvious (via the different object mode) that it is a link. - When 'git' is run on Linux on a vfat file system, there are - no symlinks. Ditto. git can already work around such deficient file systems when it comes to versioning the file, and hopefully no one is crazy enough to actually try developing git on such a file system. But makeinfo, copy and others do not work around such deficient file systems, and one cannot expect every tool to do so. - When you use 'tar' with option 'h' to copy the directory, the copy will be different from the original: it will have the symlink replaced by its target's contents. Which is perfectly fine - the copy in gnulib is for reference, and whether it is a symlink or a copy shouldn't matter. It just made my life as autoconf maintainer easier to be able to add a line to cfg.mk that does 'cp gnulib/doc/fdl.texi autoconf/doc/', http://git.savannah.gnu.org/gitweb/?p=autoconf.git;a=commitdiff;h=5bf2204#patch2 That will not work if you do it on a vfat filesystem, all you will get is a single line text file; which will produce the wrong info manual. It will also not help if you wish to use fdl.texi directly on a vfat file system. The problem is not git handling things like this, but other programs. Please, can't you make fdl.texi a regular file? Either with contents @include fdl-1.3.texi or as a copy of fdl-1.3.texi? This is a nice and simple solution.
Re: Project management and code quality tools
The copyright notice said the FSF, I assumed you have papers on file. But it would be good to confirm this. I don't think you can transfer code from one project to another like that. So you you have to contact rms I think. Yeah, it is painful... sighs * Stylesheets: should it be inlined into the generated HTML instead? That is often easier. Is the output also generating flat text? That would rock...
Re: Project management and code quality tools
* Stylesheets: should it be inlined into the generated HTML instead? That is often easier. Is the output also generating flat text? That would rock... The original pmccabe tool outputs flat text, and this pmccabe2html takes it and generates HTML (or some Wiki-markup). Although pmccabe2html could be enhanced to support flat text output as well. Nice, I like that.
Re: [PATCH] remove duplicate #include directives
+2008-08-31 Jim Meyering [EMAIL PROTECTED] + +remove duplicate #include directives I think someone forgot their capitals, and periods... :-) +* lib/chdir-long.c [TEST_CHDIR]: Remove duplicate #include stdio.h. +* lib/putenv.c: Remove duplicate #include stdlib.h. +
Re: GNUmakefile and 'make install'
Thank you. I think everyone will be happy with that change now; does anyone have any objections to the new behaviour?
Re: GNUmakefile and 'make install'
Why can not just a simple _warning_ message be displayed at the end of the run instead? That does not punish anyone, and users are informed that they installed something that has stale cruft in it, and they can easilly do `make uninstall', `make all' or whatever to fix it; or simply ignore it. The old behaviour of `make install' _is_ correct, erroring out because some file is stale is utterly wrong, and you must be able to edit the source tree without having to rerun `make all', `autoreconf', etc and have `make install' work. It does not matter if it is extracted from a tarball, or from a VCS. That the maintainer then is to lazy (as the example you gave of m4 using a version of autoconf that was not in autoconf's vcs) to bother updating his version data is not a reason to punish everyone else for something that is correct behaviour from `make install'.
Re: GNUmakefile and 'make install'
Sorry if I'm asking questions you've already answered before, but I'd rather have make install be read-only in the working directory. That's a longstanding tradition I'm loath to overturn. For whats it worth, I concur.
Re: GNU-style ChangeLog merge driver for Git
Ben Pfaff wrote: The web interface is searchable. Type your search string into the box labeled search: and hit Enter. Click on the question mark for a description of the kinds of searches that are available. Indeed! Thanks for pointing this out. This weakens my previous arguments. No, it doesn't. You cannot do many things in a web browser, for example, you cannot use M-x occur to see how often something was changed, or just to group changes related to a single file. I do not know of a web browser that allows regexp in the search field, which is immensly useful. Then there is narrowing and widening, etc etc. Then there is the question of having to be hooked up to a network if you wish to access this information using a very poor interface.
Re: GNU-style ChangeLog merge driver for Git
The web interface for the history is also usable without prerequisite knowledge; but it is not searchable. It is also not accessible to people without access to the big bad internet; or funky GUI tools. maintaining ChangeLogs is redundant work, when you're already entering the very same information into the versipon control system. Please place yourself at the position of the user who builds and runs a program, not the developer. If all packages have different ways of configuring the package, of showing version history, of listing the dependencies, etc. building packages for one's own use is too much of a frustrating experience. This is why a unified 'configure' invocation scheme was needed; this is also why a unified view of the version history is needed. Indeed!
[BUG] Check for AC_CONFIG_AUX_DIR is incorrect
Hey, The check for AC_CONFIG_AUX_DIR is incorrect, since autoconf (really, m4) allows one to quote arguments. So if ones configure.ac contains the following valid code: AC_CONFIG_AUX_DIR([build-aux]) the check will fail. Not entierly sure how to handle it since m4 allows one to set the quote character. Any ideas? Cheers.
[PATCH] Specifying the name of the gnulib library.
Hi, this allows a user to specify the name of the gnulib library (currently libPACKAGE) to something that they might prefer through bootstrap.conf by setting the variable gnulib_name. In inetutils we use libgnu for gnulib, and libinetutils.a for our own functions. 2007-03-16 Alfred M. Szmidt [EMAIL PROTECTED] * build-aux/bootstrap (gnulib_name): New variable. (gnulib_tool_options): Use it. --- bootstrap 15 Mar 2007 23:58:36 +0100 1.1 +++ bootstrap 16 Mar 2007 19:54:12 +0100 @@ -89,6 +89,7 @@ extract_package_name=' } ' package=`sed -n $extract_package_name configure.ac` || exit +gnulib_name=lib$package build_aux=build-aux # Extra files from gnulib, which override files from other sources. @@ -450,7 +451,7 @@ gnulib_tool_options=\ --no-changelog\ --aux-dir $bt/$build_aux\ --doc-base $bt/doc\ - --lib lib$package\ + --lib $gnulib_name\ --m4-base $bt/m4/\ --source-base $bt/lib/\ --tests-base $bt/tests\
[PATCH] autopoint always run even though it might not be used
Hey,
right now bootstrap will always run autpoint, even if one might not be
using it. Since autopoint requires that AM_GNU_GETTEXT_VERSION, we
can easily check if we are using autopoint/gettext.
2007-03-16 Alfred M. Szmidt [EMAIL PROTECTED]
* build-aux/bootstrap (with_gettext): New variable. Only run
autopoint and copy gettext configuration files if WITH_GETTEXT is
t.
--- bootstrap 15 Mar 2007 23:58:36 +0100 1.1
+++ bootstrap 16 Mar 2007 19:54:12 +0100
@@ -466,13 +467,18 @@ done
# Import from gettext.
-
-echo $0: (cd $bt2; autopoint) ...
-cp configure.ac $bt2
-(cd $bt2 autopoint rm configure.ac)
-slurp $bt2 $bt || exit
-
-rm -fr $bt $bt2 || exit
+with_gettext=t
+grep '^[]*AM_GNU_GETTEXT_VERSION\' configure.ac /dev/null || \
+with_gettext=nil
+
+if test $with_gettext = t; then
+ echo $0: (cd $bt2; autopoint) ...
+ cp configure.ac $bt2
+ (cd $bt2 autopoint rm configure.ac)
+ slurp $bt2 $bt || exit
+
+ rm -fr $bt $bt2 || exit
+fi
# Reconfigure, getting other files.
@@ -504,11 +510,11 @@ for file in $gnulib_extra_files; do
symlink_to_gnulib $file $dst || exit
done
-
-# Create gettext configuration.
-echo $0: Creating po/Makevars from po/Makevars.template ...
-rm -f po/Makevars
-sed '
+if test $with_gettext = t; then
+ # Create gettext configuration.
+ echo $0: Creating po/Makevars from po/Makevars.template ...
+ rm -f po/Makevars
+ sed '
/^EXTRA_LOCALE_CATEGORIES *=/s/=.*/= '$EXTRA_LOCALE_CATEGORIES'/
/^MSGID_BUGS_ADDRESS *=/s/=.*/= bug-'$package'@gnu.org/
/^XGETTEXT_OPTIONS *=/{
@@ -517,11 +523,11 @@ sed '
'$XGETTEXT_OPTIONS' $${end_of_xgettext_options+}
}
' po/Makevars.template po/Makevars
-
-if test -d runtime-po; then
- # Similarly for runtime-po/Makevars, but not quite the same.
- rm -f runtime-po/Makevars
- sed '
+
+ if test -d runtime-po; then
+# Similarly for runtime-po/Makevars, but not quite the same.
+rm -f runtime-po/Makevars
+sed '
/^DOMAIN *=.*/s/=.*/= '$package'-runtime/
/^subdir *=.*/s/=.*/= runtime-po/
/^MSGID_BUGS_ADDRESS *=/s/=.*/= bug-'$package'@gnu.org/
@@ -531,9 +537,10 @@ if test -d runtime-po; then
'$XGETTEXT_OPTIONS_RUNTIME' $${end_of_xgettext_options+}
}
' po/Makevars.template runtime-po/Makevars
-
- # Copy identical files from po to runtime-po.
- (cd po cp -p Makefile.in.in *-quot *.header *.sed *.sin ../runtime-po)
+
+# Copy identical files from po to runtime-po.
+(cd po cp -p Makefile.in.in *-quot *.header *.sed *.sin ../runtime-po)
+ fi
fi
echo $0: done. Now you can run './configure'.
Re: [PATCH] autopoint always run even though it might not be used
+with_gettext=t
+grep '^[ ]*AM_GNU_GETTEXT_VERSION\' configure.ac /dev/null || \
+with_gettext=nil
Please use yes and no for such values, or :/true and false
if you intend to use them as commands (as in `if $with_gettext'). t
is impossible to understand for those that don't speak the language this
idiom originated in.
Sorry, been coding Lisp latley. Here is a updated (though untested
version) of the patch.
2007-03-16 Alfred M. Szmidt [EMAIL PROTECTED]
* build-aux/bootstrap (with_gettext): New variable. Only run
autopoint and copy gettext configuration files if WITH_GETTEXT is
`true'.
--- bootstrap 15 Mar 2007 23:58:36 +0100 1.1
+++ bootstrap 16 Mar 2007 19:54:12 +0100
@@ -466,13 +467,18 @@ done
# Import from gettext.
-
-echo $0: (cd $bt2; autopoint) ...
-cp configure.ac $bt2
-(cd $bt2 autopoint rm configure.ac)
-slurp $bt2 $bt || exit
-
-rm -fr $bt $bt2 || exit
+with_gettext=true
+grep '^[]*AM_GNU_GETTEXT_VERSION\' configure.ac /dev/null || \
+with_gettext=false
+
+if test $with_gettext = true; then
+ echo $0: (cd $bt2; autopoint) ...
+ cp configure.ac $bt2
+ (cd $bt2 autopoint rm configure.ac)
+ slurp $bt2 $bt || exit
+
+ rm -fr $bt $bt2 || exit
+fi
# Reconfigure, getting other files.
@@ -504,11 +510,11 @@ for file in $gnulib_extra_files; do
symlink_to_gnulib $file $dst || exit
done
-
-# Create gettext configuration.
-echo $0: Creating po/Makevars from po/Makevars.template ...
-rm -f po/Makevars
-sed '
+if test $with_gettext = true; then
+ # Create gettext configuration.
+ echo $0: Creating po/Makevars from po/Makevars.template ...
+ rm -f po/Makevars
+ sed '
/^EXTRA_LOCALE_CATEGORIES *=/s/=.*/= '$EXTRA_LOCALE_CATEGORIES'/
/^MSGID_BUGS_ADDRESS *=/s/=.*/= bug-'$package'@gnu.org/
/^XGETTEXT_OPTIONS *=/{
@@ -517,11 +523,11 @@ sed '
'$XGETTEXT_OPTIONS' $${end_of_xgettext_options+}
}
' po/Makevars.template po/Makevars
-
-if test -d runtime-po; then
- # Similarly for runtime-po/Makevars, but not quite the same.
- rm -f runtime-po/Makevars
- sed '
+
+ if test -d runtime-po; then
+# Similarly for runtime-po/Makevars, but not quite the same.
+rm -f runtime-po/Makevars
+sed '
/^DOMAIN *=.*/s/=.*/= '$package'-runtime/
/^subdir *=.*/s/=.*/= runtime-po/
/^MSGID_BUGS_ADDRESS *=/s/=.*/= bug-'$package'@gnu.org/
@@ -531,9 +537,10 @@ if test -d runtime-po; then
'$XGETTEXT_OPTIONS_RUNTIME' $${end_of_xgettext_options+}
}
' po/Makevars.template runtime-po/Makevars
-
- # Copy identical files from po to runtime-po.
- (cd po cp -p Makefile.in.in *-quot *.header *.sed *.sin ../runtime-po)
+
+# Copy identical files from po to runtime-po.
+(cd po cp -p Makefile.in.in *-quot *.header *.sed *.sin ../runtime-po)
+ fi
fi
echo $0: done. Now you can run './configure'.
Re: coreutils-6.0 on BeOS (9)
Btw, the #ifdef __GLIBC__ in m4/fsusage.m4 looks wrong also for the Hurd, because glibc/sysdeps/mach/hurd/statfs64.c does not appear to access /proc. /proc doesn't exist on GNU, never did. Cheers.
