lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] Makefile.am backslashes and check_concinnity


From: Greg Chicares
Subject: Re: [lmi] Makefile.am backslashes and check_concinnity
Date: Mon, 01 Sep 2008 18:39:31 +0000
User-agent: Thunderbird 2.0.0.16 (Windows/20080708)

On 2008-09-01 17:19Z, Vadim Zeitlin wrote:
> 
>  I was getting strange errors from automake after updating to latest cvs
> and it took me some time to realize that they were due to extraneous line
> continuations characters in Makefile.am and that this patch is needed to
> fix them:
[...]

The same issue has arisen again, here for example:

<example>
test_calendar_date_SOURCES =    \
  $(common_test_objects) \
  calendar_date.cpp \
  calendar_date_test.cpp
  null_stream.cpp \
test_calendar_date_CXXFLAGS = $(AM_CXXFLAGS)
</example>

I copied the last line:
  null_stream.cpp \
to the clipboard, and added it (in alphabetical order, I hope) to
every test that required 'calendar_date.cpp', because of a new
dependency I had just created. This habit of mine is explained here:
  http://tech.groups.yahoo.com/group/boost/message/14449?var=0

Could I persuade you to accept my rewriting that file as in the
following snippet?

<example>
test_calendar_date_CXXFLAGS = $(AM_CXXFLAGS)
test_calendar_date_SOURCES =    \
  $(common_test_objects) \
  calendar_date.cpp \
  calendar_date_test.cpp \
  null_stream.cpp \

test_callback_SOURCES = \
</example>

Then I'd be able to maintain it without thinking about line
continuations, which I know I won't always remember.

> I hope there is no objection to committing this but beyond fixing it this
> time I'd like to ensure that this problem doesn't happen again

I embrace that philosophy.

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

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

But we do similar things already in 'test_coding_rules.cpp', and I
wouldn't object to adding it there (with tests intended both to fail
and to pass in 'test_coding_rules_test.sh') as long as it has no
material effect on run time, e.g.:
  time test_coding_rules lmi/*
(That file uses the less poetic ECMAScript language, but that's what
the C++ LWG standardized.) However, I'm unlikely to introduce such
defects if we adopt the
  list-item-0 \
  list-item-1 \
  list-item-N \

[preceding line deliberately blank] style that I have internalized,
in which case we needn't change 'test_coding_rules*' and you can
avoid adding ECMAScript to your own toolkit.

If you wanted to write a script to transform relevant parts of
  objects.make --> Makefile.am
so that we'd only have to maintain one list of object dependencies,
then I wouldn't object to whatever language you wrote it in. Those
two files aren't exactly analogous, but they share a common kernel
that wants to be expressed once and only once. Perhaps this doesn't
even require a scripting language: it might be easier to write it
as a 'make' target, because 'make' already parses 'objects.make'.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]