[Top][All Lists]

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

Re: How do you set VERBOSE for parallel testin

From: Nick Bowler
Subject: Re: How do you set VERBOSE for parallel testin
Date: Thu, 14 May 2015 09:40:09 -0400
User-agent: Mutt/1.5.23 (2014-03-12)

On 2015-05-13 13:18 -0700, Arthur Schwarz wrote:
> > There are 3 "normal" ways a make variable can be set (this is not the
> > complete picture but it will do):
> > 
> >  (1) In the environment (FOO=bar make)
> >  (2) In the Makefile (FOO=bar in the Makefile)
> >  (3) on the make command line (make FOO=bar)
> Before I go out on a limb and say something I'll regret, if I understand
> this correctly any user variable (not developer variable) can always be
> defined via (1) and (3). Is this correct?

Not necessarily, because variables like prefix are going to have an
assignment in the Makefile.

> Can I do this with lists, e.g.: make TEST="test1 test2..."
> And for variables which have script commands associated with them?
> For example: make AM_TESTS_ENVIRONMENT=". $(srcdir)/; \
>                        if test -d /usr/xpg4/bin; then \
>                           PATH=/usr/xpg4/bin:$$PATH; export PATH; \
>                        fi;" 
> If I have several variables do I write: make FOO=bar BAZ=snafu ...?
> Suppose the variable has a generated Makefile component (TEST_LOGS) and a
> user can change it. What changes, if anything? In order to modify such a
> variable is the user required to use form (3)?
> Does anything change if the user variable name is different from the
> variable name, e.g. ext_LOG_FLAGS and AM_ext_LOG_FLAGS?
> Does anything change if the user variable name is the same as the
> variable name, e.g. TESTS?

The answer to all of these questions is "Yes, the user running 'make'
can override any make variable whatsoever and set it to whatever he or
she likes."  Whether this is a reasonable thing for the user to do is
another story.  Overriding a variable that was not designed to be
overridden by the makefile author is probably going to break the
build rather badly.

Make provides quite a lot of options that drastically alter its
behaviour.  Actually using these features will often break things.

But none of this really has much to do with Automake, except
tangentially because Automake is a tool to help generate portable
make programs.

Nick Bowler, Elliptic Technologies (

reply via email to

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