Re[2]: [lmi] Makefile.am backslashes and check_concinnity

[Vadim Zeitlin]

On Mon, 01 Sep 2008 18:39:31 +0000 Greg Chicares <address@hidden> wrote:

GC> Could I persuade you to accept my rewriting that file as in the
GC> following snippet?
GC> 
GC> <example>
GC> test_calendar_date_CXXFLAGS = $(AM_CXXFLAGS)
GC> test_calendar_date_SOURCES =    \
GC>   $(common_test_objects) \
GC>   calendar_date.cpp \
GC>   calendar_date_test.cpp \
GC>   null_stream.cpp \
GC> 
GC> test_callback_SOURCES = \
GC> </example>

 Automake doesn't like trailing slashes like this (unlike make). I don't
remember off hand if it's an error or a warning but it definitely does
provoke a diagnostic and I'd rather avoid this.

GC> > in the
GC> > future (or, at least, make it less likely that it happens) so I'd also 
like
GC> > to propose this patch:
GC> > 
GC> > --- GNUmakefile 2008-07-19 14:50:18 +0000
GC> > +++ GNUmakefile 2008-09-01 17:14:07 +0000
GC> > @@ -342,6 +342,8 @@
GC> >           done;
GC> >         @$(ECHO) "  Miscellaneous problems:"
GC> >         @-$(TEST_CODING_RULES) *
GC> > +       @perl -Mstrict -we 'undef $$/;exit(<>=~/\\\n[^ \t]/)' Makefile.am 
\
GC> > +           || $(ECHO) "Makefile.am contains incorrect continuation 
lines."
GC> 
GC> I'd much rather avoid making that makefile depend on perl.

 I thought about introducing this but perl is now found on any Unix system,
including Cygwin, and after confirming that it is also part of MSYS I felt
there was no reason to not use it.

GC> Off this list, you saw some awk stuff that someone else wrote years
GC> ago; when it needed maintenance, I was...well, lost and despondent,
GC> because I don't know awk and have no desire to learn it. I don't mean
GC> to equate what you've written here with that awk horror, of course; I
GC> only want to keep our toolset small.

 I could do the check in awk or even sed but it would look even worse (and
much longer). All Python vs Perl vs Ruby vs whatever debates aside, Perl is
really the undisputed king of one liners: I don't think there is any other
tool more suitable for this kind of checks. Well, maybe a special multi-
line grep in this particular case.

 BTW, just in case you wanted to know what the program above did (please
feel free to skip this paragraph if you want to remain unpolluted ;-), here
is an expanded and commented version:

        # undefine the input record separator in order to read the entire
        # file at once in input/output operations
        undef $/;

        # read (diamond operator is inspired by Unix I/O redirection) the
        # input, whether it comes from stdin or the file names specified on
        # the command line
        my $input = <>;

        # check if the regex match operator (=~) finds a bad continuation
        my $matches = $input =~ /\\\n[^ \t/;

        # return the code to the shell
        exit($matches)

The "undef $/" thing is, of course, Perl magic. But the rest is as
straightforward as it gets and $/ trick can be found by Google search for
just about any relevant term (e.g. "perl read entire file at once"). That's
one of the advantages of Perl: it's pretty magical but it's well-documented
magic ;-)

        
GC> But we do similar things already in 'test_coding_rules.cpp',

 I think that C++ is an entirely wrong language for doing the test like
this and in particular hard coding the special knowledge of Makefile.am
into it just doesn't seem like a good idea.

GC> and I wouldn't object to adding it there (with tests intended both to
GC> fail and to pass in 'test_coding_rules_test.sh')

 I can still do it, of course, but I'd like to ask you to reconsider... If
Perl is unacceptable we can use sed, although IMO it will be much more
cryptic in this case.

GC> [preceding line deliberately blank] style that I have internalized,

 Unfortunately it doesn't work with automake.

GC> If you wanted to write a script to transform relevant parts of
GC>   objects.make --> Makefile.am

 This could be done, of course, but it doesn't look totally trivial and so
far I don't think it's worse the trouble. OTOH now that we have bakefile
for MSVC we could ditch Makefile.am entirely and use bakefile with its
autoconf backend for Unix build too (automake wouldn't be used but autoconf
still would). This still wouldn't solve the problem though, just replace
one syntax (automake) with another one (XML).

 Regards,
VZ