Compiling with the Debian gnulib snapshot of 20081001, I am delighted that I
no longer get warnings about #include_next. (Un?)fortunately, this enables
me more easily to spot "real" warnings:
gl_anylinked_list2.h: In function ‘gl_linked_node_value’:
gl_anylinked_list2.h:124: warning: unused par
On Thu, 16 Oct 2008, Jim Meyering wrote:
This one is perhaps a good reason to turn off or ignore that warning,
Thanks to Paul Eggert for finding an acceptable solution.
In general, I reiterate the principle I implied with my request that
#include_next warnings be suppressed some time ago: gn
I just noticed that in a project of mine that uses gnulib, configmake.h is
in the git repo. Since this contains details of how I've configured my
build, that doesn't seem right, but equally, configmake.h is not listed in
the auto-generated .gitignore, which is why I've added it to the repo.
Is
I've just noticed for the first time that these files (or at least
.gitignore, assuming that .cvsignore works the same way) have rather odd
contents.
There seem to be basically two classes of user when it comes to what is
ignored:
1. gnulib is considered as a build dependency, so no files pr
On Thu, 6 Nov 2008, Bruno Haible wrote:
Hi,
Reuben Thomas wrote:
There seem to be basically two classes of user when it comes to what is
ignored:
1. gnulib is considered as a build dependency, so no files provided or
generated by gnulib are put in CVS/git.
2. gnulib is not considered as a
"Gnulib provides a module @samp{canonicalize-lgpl}"
since there's a canonicalize and a canonicalize-lgpl module, shouldn't it
just say "a module @samp{canonicalize}", and users can make the usual guess
that there might be an LGPL version?
--
http://rrt.sc3d.org/ | romantic, n. one who puts i
On Fri, 20 Feb 2009, Bruno Haible wrote:
Reuben Thomas wrote:
"Gnulib provides a module @samp{canonicalize-lgpl}"
since there's a canonicalize and a canonicalize-lgpl module, shouldn't it
just say "a module @samp{canonicalize}", and users can make the usual gue
Since gnulib works on many systems, I imagine it's supposed to work with C89
compilers?
I'm working on a project which uses C89, so I just added the -std=c89 flag
to GCC when building it, to find potential problems. Unfortunately, some of
the gnulib code I'm using now doesn't work:
In file i
On Thu, 5 Mar 2009, Simon Josefsson wrote:
Did you run all the gnulib configure tests using the same compiler and
flags? You can't change compiler and flags after running configure.
I think this is my problem: I set CFLAGS after running gl_EARLY in
configure.ac. Putting the setting right aft
The documentation says:
--without-included-regex
don't compile regex; this is the default on 32-bit
systems with recent-enough versions of the GNU C
Library (use with caution on other systems). On
, let me know what needs fixing.
--
http://rrt.sc3d.org/ | egrep, n. a bird that debugs bisonFrom 1549e1416029797bff90d5ee494f90f95efdba08 Mon Sep 17 00:00:00 2001
From: Reuben Thomas
Date: Tue, 17 Mar 2009 23:49:33 +
Subject: [PATCH] Update and improve help for --without-included-
On Tue, 17 Mar 2009, Eric Blake wrote:
In the meantime, I did a search of the copyright assignments; I see that
you have assignment on file for coreutuils, but not gnulib. Since it is a
separate project, I'd recommend repeating the process to ensure your
future gnulib contributions are not a pr
string.h uses restrict, which doesn't work if the compiler is C89 (e.g. gcc
in -std=c89 mode).
regex.h has some code to detect this case and allow for it; should string.h
copy this code? Or should it be broken out into a module? (It would be
useful to gnulib users too.)
--
http://rrt.sc3d.or
On Wed, 18 Mar 2009, Eric Blake wrote:
Did you actually encounter a compilation failure where restrict was
improperly defined while using gnulib? If so, how do we reproduce it?
It was not on my system, but on a BSD box that Nelson Beebe was kindly
building GNU Zile on for me. A bit of the bu
On Wed, 18 Mar 2009, Eric Blake wrote:
Ahh. The bug is in zile, not gnulib.
Ah, thanks very much, and apologies for the noise.
--
http://rrt.sc3d.org/ | mediate, v.i. to butt in (Bierce)
On Thu, 19 Mar 2009, Jim Meyering wrote:
Reuben Thomas wrote:
On Wed, 18 Mar 2009, Eric Blake wrote:
Ahh. The bug is in zile, not gnulib.
Ah, thanks very much, and apologies for the noise.
Always including first is easy to forget.
You might want to use rules like these from gnulib&#
On Fri, 20 Mar 2009, Eric Blake wrote:
Jim meant coreutil's maint.mk. It is not synced with gnulib's maint.mk,
although several people have expressed interest in resyncing them.
Aha! This is surely the sort of rule that should be pushed into gnulib.
Thanks anyway.
This problem seems to occ
On Fri, 20 Mar 2009, Bruno Haible wrote:
Reuben Thomas wrote:
I suppose it's also a downside of gnulib's being a source library, though
the tools it offers have persuaded me, at least, to treat its files as "not
normally for editing", and hence like a binary library
On Fri, 20 Mar 2009, Simon Josefsson wrote:
Reuben Thomas writes:
On Fri, 20 Mar 2009, Eric Blake wrote:
Jim meant coreutil's maint.mk. It is not synced with gnulib's maint.mk,
although several people have expressed interest in resyncing them.
Aha! This is surely the sort of
On Wed, 1 Apr 2009, Simon Josefsson wrote:
Reuben Thomas writes:
Since coreutils' maint.mk seems to be shared with other projects
already, could it not simply be pushed into gnulib as it is? Could
those projects (currently, according to the comments, "coreutils,
idutils, CPPI,
I just decided to stop using Debian packages, which I have to download from
sid in order to keep up to date in any case, and just do the obvious thing
and get gnulib from git, which I can update whenever I like.
However, I can't see any installation instructions. Am I missing something?
--
htt
On Wed, 1 Apr 2009, Simon Josefsson wrote:
It will be easier to review if you post patches for gnulib's maint.mk
instead of the entire new file.
I'll do that.
You may have to patch coreutils maint.mk too, but that could go to
bug-coreut...@gnu.org.
I was hoping to end up with a single file
On Wed, 1 Apr 2009, Simon Josefsson wrote:
Coreutils doesn't use the gnulib maintainer-makefile module, I believe,
so at minimum it would need a patch that made it use maint.mk from
gnulib.
Or it could use maintainer-makefile, unless there's some reason why not?
Further, some of the rules in
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?
It would be nice to have a top-level INSTALL file that gives this
in
On Thu, 2 Apr 2009, Kamil Dudka wrote:
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
On Wed, 1 Apr 2009, Karl Berry wrote:
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
On Wed, 1 Apr 2009, Alfred M. Szmidt wrote:
Any problem with adding gnulib to your path?
I prefer to add executable-only directories.
--
http://rrt.sc3d.org/ | RSA, n. safety in numbers
On Wed, 1 Apr 2009, Alfred M. Szmidt wrote:
You do not need a internet connection to compile a project that uses
gnulib, the project will include whatever parts of gnulib it uses.
I think the point is that you can install the gnulib Debian package without
an internet connection, just like any
On Wed, 1 Apr 2009, Alfred M. Szmidt wrote:
> 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.
Sorry, I was unclear. I meant directories containing
On Wed, 1 Apr 2009, Karl Berry wrote:
I think the point is that you can install the gnulib Debian package
without an internet connection
That may be, but it doesn't make distributing a snapshot of gnulib as a
"package" any less problematic. It is still the wrong thing to do.
I don't se
On Thu, 2 Apr 2009, Bruno Haible wrote:
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.
--
http://rrt.sc3d.org/ | Aphorisms work only in retrospect
On Thu, 2 Apr 2009, Bruno Haible wrote:
That's the common convention for when you receive a package in the form of a
tarball. For CVS or git checkouts, there is no such conventions.
Well, most packages that have INSTALL have it also in the VCS. And gnulib
doesn't seem to have any of the optio
On Thu, 2 Apr 2009, Bruno Haible wrote:
Reuben Thomas wrote:
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.
Ah, that was the real question behind the question!
Not r
On Wed, 1 Apr 2009, Alfred M. Szmidt wrote:
> 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.
I guess we mean different thing
On Thu, 2 Apr 2009, Bruno Haible wrote:
Reuben Thomas wrote:
It didn't occur to me to read the manual, as I hadn't figured out
how to build it. I looked in Makefile, but that didn't seem to do much.
This can be improved:
[add doc-building targets to Makefile]
That looks
On Wed, 1 Apr 2009, Reuben Thomas wrote:
Would you like to suggest what I should do next to my patch?
Not having had a reply, I've come up with my own answer: start with a little
bit of merging.
What I've done so far is to add the macros _prohibit_regexp and
_header_with
Why is this rule valid? GCC gives warnings if const pointers are not cast to
non-const before passing to C. As far as I can see, this is correct: free
takes a non-const argument. Should malloced memory simply not be assigned to
a const pointer?
--
http://rrt.sc3d.org/ | Bathe or shower daily:
On Fri, 3 Apr 2009, Reuben Thomas wrote:
On Wed, 1 Apr 2009, Reuben Thomas wrote:
Would you like to suggest what I should do next to my patch?
Not having had a reply, I've come up with my own answer: start with a little
bit of merging.
What I've done so far is to add
On Fri, 3 Apr 2009, Jim Meyering wrote:
I'll take your word that it doesn't change anything.
Someone who uses it may want to try it or give it a closer look.
Let me know, and I can do some more work. The next thing I'm interested in
is adding some more source checking rules, particularly thos
On Sat, 4 Apr 2009, Jim Meyering wrote:
Those buglets were from coreutils' maint.mk.
Just to be clear, the buglets were from coreutils' maint.mk, but the patch I
sent was a patch to gnulib's maint.mk. So your push below:
Subject: [PATCH] tests: make syntax-checks more robust
is to coreut
On Sat, 4 Apr 2009, Jim Meyering wrote:
Reuben Thomas wrote:
On Sat, 4 Apr 2009, Jim Meyering wrote:
Those buglets were from coreutils' maint.mk.
Just to be clear, the buglets were from coreutils' maint.mk, but the
patch I sent was a patch to gnulib's maint.mk. So
On Mon, 6 Apr 2009, Jim Meyering wrote:
Ok by me. Though I don't like the use of $(C_SOURCES), as I mentioned.
I do understand you're trying to do this gradually. I'd be inclined to
make bigger changes ;-) It's only "make syntax-check", after all.
OK, I'm just trying to make changes that I
just made trivial changes, it's not a problem. I have in any case
requested an assignment which was apparently mailed on 19th March but hasn't
reached me in the UK yet.)
--
http://rrt.sc3d.org/ | humour, n. unexpected recognitionFrom ce5497a2c9fd85cfa14226d5fb814786d0b44fcf Mon Sep 1
On Tue, 7 Apr 2009, Jim Meyering wrote:
- your summary/subject was needlessly utf8-encoded.
That makes it harder to read.
For the sake of one apostrophe. It's a pity, I made Emacs do smart quotes in
text mode, and now it looks like I need an exception. What's the problem
with UTF-8 in
On Tue, 7 Apr 2009, Jim Meyering wrote:
Didn't you notice how it was harder to read your UTF8-encoded Subject
line in what I quoted?
Yes, but that's because you pasted an encoded mail header into your reply. I
normally only read mail headers in an MUA where they are displayed properly.
Are y
On Tue, 14 Apr 2009, Simon Josefsson wrote:
So if you have time, please proceed in trying to merge these files. I
am sorry that I have been quite busy and haven't had time to review and
comment. But in general I support your approach.
I'm not bothered about the speed as I'm not in any hurry,
I'm delighted to see that maint.mk has now been fully merged into gnulib by
Jim (at least, from a cursory reading of coreutils's logs). Naturally I
shall credit this achievement to myself, under the heading of "tactical
ineptitude". Seriously, thanks Jim and anyone else who was involved.
--
ht
Hi,
I'm sorry, I have a memory of asking about this before, but I can't
after much searching find the previous correspondence, if any.
When building with -ansi -pedantic, I get warnings like this:
In file included from printf-args.c:30:
printf-args.h:105: warning: ISO C90 does not support 'long
Line 516 of hash.c (current git), there's a declaration of "float
epsilon" after we've already had some statements.
--
http://rrt.sc3d.org
Every act of belief is an act of unbelief (Carse)
Using getopt-posix on FreeBSD 6, with current git gnulib, I get the
following compilation error:
/usr/bin/cc -std=gnu99 -DHAVE_CONFIG_H -I. -I..
-I/usr/local/include -Wall -W -Wmissing-prototypes -Wstrict-prototypes
-D_FORTIFY_SOURCE=2 -MT getopt.o -MD -MP -MF .deps/getopt.Tpo -c -o
getopt.o getop
As far as I can see, there is an implementation of isblank in gnulib
for systems that lack it, but I can't see how I'm supposed to use it:
I can see the module c-ctypes which seems to be specifically for the C
locale, and unictype/ctype-blank module, which mentions
"generalisation", though it's not
2009/10/6 Bruno Haible :
> Reuben Thomas wrote:
>> As far as I can see, there is an implementation of isblank in gnulib
>> for systems that lack it, but I can't see how I'm supposed to use it:
>> I can see the module c-ctypes which seems to be specifically for the
2009/10/7 Eric Blake :
> Can we add a summary of this logic to the isblank.texi documentation, to
> point people to better replacements?
Proposed patch:
diff --git a/doc/posix-functions/isblank.texi b/doc/posix-functions/isblank.texi
index 2547793..a4924c7 100644
--- a/doc/posix-functions/isblank
You star, Bruno!
Hi,
strrstr, which is to strstr as strrchr is to strchr, is a useful and
moderately widely-used function. It's included in source form in quite a few
programs. I have written an implementation that is part of a GNU program
(GNU Zile). I'd be happy to see it in gnulib. Any chance of that? What
I compile my code with -pedantic, because I want it to work with compilers
other than GCC. This means that my compiler output is littered with warnings
about #include_next. How can I stop this? It's a pain to read through; of
course I can grep out the warnings, but that's that's an annoyance too
On Sun, 24 Aug 2008, Bruno Haible wrote:
Hello,
Reuben Thomas wrote:
I compile my code with -pedantic, because I want it to work with compilers
other than GCC. This means that my compiler output is littered with warnings
about #include_next.
gnulib is clever enough to use #include_next only
On Sun, 24 Aug 2008, James Youngman wrote:
On Sun, Aug 24, 2008 at 10:52 PM, Reuben Thomas <[EMAIL PROTECTED]> wrote:
Sounds interesting, but I can't find it. Have you a pointer to where this
comes from? I can't find it in any obvious place.
It was attached to the email t
On Mon, 25 Aug 2008, Bruno Haible wrote:
Reuben Thomas wrote:
it'd need some way for gnulib to turn it off, and
gnulib would then have to use it.
gnulib cannot avoid the use of #include_next. On non-glibc platforms it
would be possible, by use of #include ,
but with glibc it is not pos
On Mon, 25 Aug 2008, Bruno Haible wrote:
Paolo Bonzini wrote:
You can put "#pragma GCC system_header" in the gnulib files.
However, this pragma not only affects warnings, it also causes __STDC__ to
evaluate to 0 in such a file, on some platforms (those which define
STDC_0_IN_SYSTEM_HEADERS, n
Trying to build some code I wrote using gnulib on an old machine, it choked
on #include_next. It is using gcc 3.3.3. Some other machines with non-GNU
compilers seem to work OK, so is the problem that gnulib assumes that
too-old versions of GCC support #include_next?
--
http://rrt.sc3d.org/ | P
On Sun, 21 Sep 2008, Bruno Haible wrote:
Hi,
Reuben Thomas wrote:
Trying to build some code I wrote using gnulib on an old machine, it choked
on #include_next. It is using gcc 3.3.3. Some other machines with non-GNU
compilers seem to work OK, so is the problem that gnulib assumes that
too-old
On Sat, 20 Sep 2008, Eric Blake wrote:
According to Reuben Thomas on 9/20/2008 4:22 PM:
gnulib checks that the compiler supports #include_next before actually
stuffing #include_next into the generated .h files.
I think I might be confused here. I am running gnulib on my computer,
and
On 3 October 2010 20:05, Reuben Thomas wrote:
> On 30 September 2010 10:54, Simon Josefsson wrote:
>> Reuben Thomas writes:
>>> Either way, if we have a consensus, I'll happily make a patch to
>>> pmccabe2html to make the figures in the report consistent wi
On 3 November 2010 18:56, Reuben Thomas wrote:
> I just noticed that this mail was sent only to me; I presume it was
> meant for the list.
>
> Perhaps someone who knows what posix-modules does could actually carry
> out my request and make --help say what posix-modules does? (Or
/home/rrt/repo/gnulib/m4/unlink.m4
35: AC_CACHE_CHECK([whether unlink of a parent directory fails is it should],
Presumably "is it should" should be "if it should" or "as it should"?
--
http://rrt.sc3d.org
On 10 November 2010 22:41, Bruce Korb wrote:
> On 11/10/10 14:04, Reuben Thomas wrote:
>> On 3 November 2010 18:56, Reuben Thomas wrote:
>>> I just noticed that this mail was sent only to me; I presume it was
>>> meant for the list.
>>>
>>> Perhaps so
This patch seems to have been overlooked again. Is there some problem
with it? It just adds text to posix-modules --help...
--
http://rrt.sc3d.org
0001-Rebase.patch
Description: Binary data
ot; wrote:
On 11/30/10 14:39, Reuben Thomas wrote:
> This patch seems to have been overlooked again. Is there s...
I was going to put it into the libposix branch, but I left town
for Thanksgiving and only got back the other day. Today, I'm
on an interview. RSN. Sorry. - Bruce
configure does not complain if gperf is not installed.
--
http://rrt.sc3d.org
>From a current checkout from git, I get, from make:
make[3]: *** No rule to make target `version.lo', needed by
`libposix.la'. Stop.
I have followed the bootstrapping instructions I found on the list
(./bootstrap; ./configure; make)...
Help please?
--
http://rrt.sc3d.org
On 8 December 2010 14:11, Gary V. Vaughan wrote:
> Hi Reuben,
>
> I've fixed the version.c and bootstrap problems, but I don't think we
> ever settled on the right way to deal with not having `program_name`
> defined at build time.
>
> If you are on a glibc system, I think the library provides the
I have an autotools project with no C in. I still want to use gnulib's
maintainer-makefile module, but I don't want to use C. If I leave
"lib" in the top-level SUBDIRS, then I'm forced to us AC_PROG_CC, or C
source is (correctly: dummy.c) detected, and make fails, because I
didn't set up a C compil
On 26 February 2011 02:21, Bruno Haible wrote:
> Reuben Thomas wrote:
>> I have an autotools project with no C in. I still want to use gnulib's
>> maintainer-makefile module, but I don't want to use C. If I leave
>> "lib" in the top-level SUBDIRS, then I&
On 26 February 2011 16:40, Reuben Thomas wrote:
> This is correct. However, there is no advice printed to create the
> directory lib/. The two lines of advice that no longer apply are:
>
> [Don't forget to]
> - add "lib/Makefile" to AC_CONFIG_FILES in ./confi
On 26 February 2011 16:44, Reuben Thomas wrote:
> On 26 February 2011 16:40, Reuben Thomas wrote:
>> This is correct. However, there is no advice printed to create the
>> directory lib/. The two lines of advice that no longer apply are:
>>
>> [Don't forget
regex-quote seems only to support two syntaxes at the moment, and it
does it in a rather odd way: by a single boolean flag.
I wonder if there's scope to change this.
The obvious representation of syntaxes from a GNU point of view would
be a bitmask of type reg_syntax_t as passed to re_set_syntax.
On 5 March 2011 14:51, Bruno Haible wrote:
> Hello Reuben,
>
>> regex-quote seems only to support two syntaxes at the moment
>
> Yes. POSIX specifies two syntaxes.
regex.h suggests that in practice there are a couple more:
RE_SYNTAX_POSIX_EGREP
RE_SYNTAX_POSIX_AWK
each of which is different fro
On 6 March 2011 13:41, Bruno Haible wrote:
>
>> RE_NO_BK_REFS -> [:digit:]
>
> I don't know what you mean by that? '[' and ']' are already in the list of
> characters to be escaped. So no need to look at RE_NO_BK_REFS, right?
I'm not sure what it has to do with '[' and ']', but indeed if the
inpu
On 6 March 2011 13:51, Reuben Thomas wrote:
> On 6 March 2011 13:41, Bruno Haible wrote:
>>
>>> RE_NO_BK_REFS -> [:digit:]
>>
>> I don't know what you mean by that? '[' and ']' are already in the list of
>> characters to be escap
Another day, another nice surprise from gnulib: it supports valgrind,
so I can remove my own code for that...only, no I can't, because I add
options (I add --error-exitcode=1 --leak-check=full).
So, two alternative suggestions:
1. Agree that these options are must-haves (rationale: one's code
sho
The documentation for the warnings module says:
"It allows to use ‘-Werror’ at ‘make distcheck’ time"
but gives no clue as to how this is done; nor is -Werror mentioned in
warnings.m4. Could we have a hint, please? (The documentation shows
how to make the set of warnings chosen only apply to cert
I was a bit perplexed to find that one of the tests in maint.mk
instructs me to use STREQ/STRNEQ instead of strcmp, but, while this is
eminently sensible, not only is no definition of STRNEQ provided, but
that of STREQ isn't the one meant, but rather an optimised 11-argument
horror for short litera
They're specified in POSIX, so if that doesn't count as portable, it'd
be nice to have a little more explanation in the comment in maint.mk.
--
http://rrt.sc3d.org
On 13 March 2011 15:22, Paul Eggert wrote:
> On 03/13/2011 07:30 AM, Reuben Thomas wrote:
>> They're specified in POSIX
>
> They're marked as an obsolescent XSI extension in POSIX.1-2008.
Pity that the POSIX man pages say none of this (but I don't know that
they e
make syntax-check is complaining about space-tabs (sc_space_tab) in a
sort of file where this is perfectly permissable: a .diff file. Why do
I have a diff file in version control? Because I'm patching gnulib.
Of course, I can add this to VC_LIST_ALWAYS_EXCLUDE_REGEX, but maybe
.diff files should b
i.e. just before
gnulib_dir ?= $(srcdir)/gnulib
have
gnulib_dir ?= $(GNULIB_SRCDIR)
?
--
http://rrt.sc3d.org
Currently, maint.mk has the line (1077):
$$(git cat-file tag v$(VERSION) > .ann-sig \
Is this v$(VERSION) somehow different from the one that is the
definition of this-vc-tag for the git case? i.e. why's $(this-vc-tag)
not used here instead of v$(VERSION)?
--
http://rrt.sc3d.org
What's the intended use of VC-tag in maint.mk? I can't seem to find
anything on this in the manual, or in the code, and only a short note
when it was added in the ChangeLog. $(VC-tag) doesn't seem to be used
anywhere. This seems to be connected with the comment:
# If it's not already specified, de
Someone kindly pointed out privately that some of my suggestions would
have a better chance of being implemented if I provided patches.
I am only backward in doing so because a) I'm often wrong, b) even
some of my better ideas are rightly rejected for other reasons; and c)
many of my suggestions a
On 14 March 2011 14:23, Jim Meyering wrote:
> - exit (1);
> - exit (0);
> + return 1;
> + return 1;
Was that intentional? i.e. should second return be return 0?
--
http://rrt.sc3d.org
This line in maint.mk:
VC-tag = git tag -s -m '$(VERSION)' -u '$(gpg_key_ID)'
does appear to be unused, because its syntax is wrong: there's no
message (argument to -m), or equivalently, no tag name is specified.
Is something like:
VC-tag = git tag -s -m 'Sign version $(VERSION)' '$(VERSION)' -
On 14 March 2011 15:45, Jim Meyering wrote:
> http://git.sv.gnu.org/cgit/coreutils.git/tree/README-release
This is just the sort of document it would be useful to have in
gnulib, though obviously the more of it that can be translated into
rules in maint.mk the better.
Before I started using mai
On 14 March 2011 20:17, Simon Josefsson wrote:
>
> Do you think this is useful? Maybe warnings.m4 should unconditionally
> check for -Werror since it actually is a standard gcc parameter. Then
> all projects doesn't have to hard code that test themselves.
>
> Alternatively, we could just documen
I finally cajoled maint.mk into actually making a stable release of GNU Zile.
There are a couple of odd things about the final stages:
1. It doesn't upload the release tarball &c. itself, it emits commands
to do so. Why?
2. There's no post-release hook which I can use for my Freshmeat
announceme
On 16 March 2011 16:09, Jim Meyering wrote:
> Reuben Thomas wrote:
>> I finally cajoled maint.mk into actually making a stable release of GNU Zile.
>>
>> There are a couple of odd things about the final stages:
>>
>> 1. It doesn't upload the release tarball
On 16 March 2011 16:45, Jim Meyering wrote:
>
> Currently the gnupload command is emitted at the end of a successful
> "make stable". Just because that succeeded does not always mean I am
> ready to release.
OK, so an extra target is needed. I used to use "make release". This
would seem to make
On 16 March 2011 21:22, Bernd Becker wrote:
> Hi Thomas,
>
> Am 12.03.2011 18:41, schrieb Reuben Thomas:
>> Another day, another nice surprise from gnulib: it supports valgrind,
>> so I can remove my own code for that...only, no I can't, because I add
>> options
On 16 March 2011 19:59, Jim Meyering wrote:
> Reuben Thomas wrote:
>>
>> OK, so an extra target is needed. I used to use "make release". This
>> would seem to make sense to cover uploading and announcing the
>> release.
>
> There's already a t
On 16 March 2011 23:42, Bernd Becker wrote:
> Am 16.03.2011 22:52, schrieb Reuben Thomas:
>> Sounds like what's needed is a pair of variables that works like
>> CPPFLAGS/AM_CPPFLAGS.
>>
> how about an approach passing a variable into make like
> test_a_VALGRIND_O
1 - 100 of 616 matches
Mail list logo
