[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Fwd: sed porting trouble
From: |
Jim Meyering |
Subject: |
Re: Fwd: sed porting trouble |
Date: |
Tue, 05 Oct 2010 12:49:43 +0200 |
Bruno Haible wrote:
> Eric Blake wrote:
>> Personally, I don't mind a two-pronged approach:
>>
>> Lines less than 80 columns are nicer in my opinion, and we might as well
>> do that whether or not -Wcolumns is in effect when the end result looks
>> nicer. But I agree with Bruno that some lines should not be broken, as
>> breaking them makes them less readable, and that we shouldn't have to
>> worry about whether a particular commit is going to resurrect the
>> problem. Therefore, using the #pragma will make the code immune to
>> column width, whether or not we also reduce line length.
>
> Thanks for your opinion (or may I say: arbitration).
>
> With this, and silence from Jim and Simon, I'm committing this fix. With
As you can see, my silence was not indicative of indifference
or agreement ;-) I find it counter to the gnulib philosophy
to let a misfeature like the this evoke changes to so many files.
Normally we try hard to make it so feature-poor systems do not
evoke ugliness in the code we maintain, and we try even harder to
avoid letting those systems induce a process burden (however small)
on gnulib development.
Maybe it was infeasible to ensure that all generated .h files
toe the 80-column line. I don't know and am not motivated to
pursue it, now that you've already done the work.
> a consistent idiom across all 44 .in.h files.
Hmm.. I see 62 .in.h files:
$ git ls-files|grep '\.in\.h$'|wc -l
62
Oh. You mean the ones that use PRAGMA_SYSTEM_HEADER:
$ git ls-files|grep '\.in\.h$'|xargs grep SYSTEM_HEADER|wc -l
44
> lib/regex.h is not handled by this patch. For this file, we will have the
> choice: either keep the line lengths bounded, or convert it to a .in.h as
> well.
>
>
> 2010-10-04 Bruno Haible <address@hidden>
>
> Avoid line length limitation from HP NonStop system header files.
> * m4/include_next.m4 (gl_INCLUDE_NEXT): Define also PRAGMA_COLUMNS.
> * lib/arpa_inet.in.h: Use PRAGMA_COLUMNS.
> * lib/ctype.in.h: Likewise.
Thus, technically we must now remember that for each new
@address@hidden .in.h file, we must also use @address@hidden
That deserves a syntax-check rule in Makefile.
I've added this:
>From 138795ddedc0b8b9fbf2dfd210ddbd6bbbf1383a Mon Sep 17 00:00:00 2001
From: Jim Meyering <address@hidden>
Date: Tue, 5 Oct 2010 12:44:20 +0200
Subject: [PATCH] tests: require @PRAGMA_COLUMNS@ with each
@PRAGMA_SYSTEM_HEADER@
* Makefile (sc_pragma_columns): New syntax-check rule.
---
ChangeLog | 5 +++++
Makefile | 13 +++++++++++++
2 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index f588069..edc7c8b 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,8 @@
+2010-10-05 Jim Meyering <address@hidden>
+
+ tests: require @PRAGMA_COLUMNS@ with each @PRAGMA_SYSTEM_HEADER@
+ * Makefile (sc_pragma_columns): New syntax-check rule.
+
2010-10-04 Bruno Haible <address@hidden>
gnulib-tool: Synthesize appropriate _LDFLAGS for a libtool library.
diff --git a/Makefile b/Makefile
index 345e302..e40a77c 100644
--- a/Makefile
+++ b/Makefile
@@ -15,6 +15,7 @@ info html dvi pdf:
# Perform some platform independent checks on the gnulib code.
check: \
sc_prohibit_augmenting_PATH_via_TESTS_ENVIRONMENT \
+ sc_pragma_columns \
sc_prefer_ac_check_funcs_once
sc_prefer_ac_check_funcs_once:
@@ -32,6 +33,18 @@ sc_prohibit_augmenting_PATH_via_TESTS_ENVIRONMENT:
" see <$$url>" 1>&2; exit 1; } || : \
else :; fi
+sc_pragma_columns:
+ if test -d .git; then \
+ git ls-files|grep '\.in\.h$$'
\
+ | xargs grep -l 'address@hidden@' \
+ | xargs grep -L 'address@hidden@' \
+ | grep . \
+ && { printf '%s\n' \
+ 'the files listed above use @PRAGMA_SYSTEM_HEADER@' \
+ 'without also using @PRAGMA_COLUMNS@' 1>&2; \
+ exit 1; } || :; \
+ else :; fi
+
# Regenerate some files that are stored in the repository.
regen: MODULES.html
--
1.7.3.1.45.g9855b
- RE: Fwd: sed porting trouble, Schmitz, Joachim, 2010/10/01
- Re: Fwd: sed porting trouble, Paolo Bonzini, 2010/10/01
- RE: Fwd: sed porting trouble, Schmitz, Joachim, 2010/10/01
- Re: Fwd: sed porting trouble, Paolo Bonzini, 2010/10/01
- Re: Fwd: sed porting trouble, Bruno Haible, 2010/10/01
- RE: Fwd: sed porting trouble, Schmitz, Joachim, 2010/10/02
- Re: Fwd: sed porting trouble, Bruno Haible, 2010/10/02
- RE: Fwd: sed porting trouble, Schmitz, Joachim, 2010/10/02
- Re: Fwd: sed porting trouble, Eric Blake, 2010/10/04
- Re: Fwd: sed porting trouble, Bruno Haible, 2010/10/04
- Re: Fwd: sed porting trouble,
Jim Meyering <=
- Re: Fwd: sed porting trouble, Eric Blake, 2010/10/05
- Re: Fwd: sed porting trouble, Jim Meyering, 2010/10/05
- Re: Fwd: sed porting trouble, Paul Eggert, 2010/10/05
- Re: Fwd: sed porting trouble, Jim Meyering, 2010/10/05
- Re: Fwd: sed porting trouble, Bruno Haible, 2010/10/05
- Re: Fwd: sed porting trouble, Ralf Wildenhues, 2010/10/05
- Re: Fwd: sed porting trouble, Bruno Haible, 2010/10/05
- Re: Fwd: sed porting trouble, Ralf Wildenhues, 2010/10/05
- Re: multiline substitutions, Bruno Haible, 2010/10/05
- Re: multiline substitutions, Paul Eggert, 2010/10/05