Re: MIssing "location" in automake-1.6.3 error message

[Alexandre Duret-Lutz]

>>> "adl" == Alexandre Duret-Lutz <address@hidden> writes:

[...]

 adl> why does it disallow

 adl> if COND1
 adl> bin_PROGRAMS = foo
 adl> endif
 adl> if COND2
 adl> bin_PROGRAMS = bar
 adl> endif

 adl> ?  

It seems this is due to way &append_exeext works.
&append_exeext tries to rewrite the above as

if !COND1
  if !COND2
    bin_PROGRAMS =
  else
    bin_PROGRAMS = bar
  endif
else
  if !COND2
    bin_PROGRAMS = foo
  else
    bin_PROGRAMS = ???
endif

Of course, defining bin_PROGRAMS for condition "COND1_TRUE COND2_TRUE" is
a bit hard...

[If you are reading &append_exeext: calling
&variable_conditions_recursive ('bin_PROGRAMS') returns this
list of conditions:

  COND1_FALSE COND2_TRUE
  COND1_FALSE COND2_FALSE
  COND1_TRUE COND2_TRUE
  COND1_TRUE COND2_FALSE

And &variable_value_as_list_recursive_worker (called by
&variable_conditions_recursive, itself called by &append_exeext)
chokes on `COND1_TRUE COND2_TRUE'.]

I guess it should be possible to rewrite bin_PROGRAMS in place
without introducing new conditions.  For a start, do we care
about inlining subvariables?

Presently

  FOO = foo
  bin_PROGRAMS = $(FOO)

is rewritten as 

  FOO = foo
  bin_PROGRAMS = foo$(EXEEXT)

What about rewritting it as

  FOO = foo$(EXEEXT)
  bin_PROGRAMS = $(FOO)

or, probably safer

  FOO = foo
  am__exeext_FOO = foo$(EXEEXT)
  bin_PROGRAMS = $(am__exeext_FOO)

?

Note that the latter idiom is the same we use with _OBJECTS
variables to limit combinatoric explosion in presence of
conditionals.  It might be interesting to factor this logic out.
-- 
Alexandre Duret-Lutz