Re: bug#13928: [PATCH] plans: enabling subdir-object by default is blocked on bug#13928

2014-07-05 Thread Johan Kristensen
Hi,

What is the current status of this bug? I spent some time tracking down the
reason for this bug, but I am totally new to the automake sources and what
would be required for a patch to be acceptable. The problem is that when
the dummy dependency-files is created by ./config.status (by code from
m4/depout.m4), only the DEPDIR variable is substituted. Any other
variable expansions are ignored.

I have a couple of suggestions for a fix. The first is to somehow delegate
the creation of the dummy dependency-files to make, and executing something
like make dummy-depfiles from config.status. This seems like the most
straightforward solution but raises the question of how to handle the
includes that are missing. One solution to this problem would be to have
some conditional include of the dependency-files based on if target
dummy-depfiles is built. An other solution would be to generate a
temporary Makefile without these includes.

The other alternative is to resolve all variables in depout.m4. To be
correct this would require a recursive lookup of all variable substitutions
in the Makefile. Perhaps the structure imposed by automake makes this kind
of trivial but I have no idea. Will automake under some circumstances
output something like +=, ?= or conditional assigns? This would make a
solution along these lines intractable.

kind regards,
Johan Kristensen


Re: bug#13928: [PATCH] plans: enabling subdir-object by default is blocked on bug#13928

2014-04-22 Thread Bert Wesarg
Stefano,

may it be possible to disable the 'subdir-object is the
default'-warning in the 1.14 release series than? We should have this
warning only active when we are sure that this bug is resolved.

Thanks.

Bert

On Mon, Apr 21, 2014 at 4:32 PM, Stefano Lattarini
stefano.lattar...@gmail.com wrote:
 Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com
 ---
  PLANS/subdir-objects.txt | 9 +
  1 file changed, 9 insertions(+)

 diff --git a/PLANS/subdir-objects.txt b/PLANS/subdir-objects.txt
 index 94c6305..3cf6101 100644
 --- a/PLANS/subdir-objects.txt
 +++ b/PLANS/subdir-objects.txt
 @@ -5,6 +5,9 @@ We want to make the behaviour currently enabled by the 
 'subdir-objects'
  the default one, and in fact the *only* one, in Automake 2.0.
  See automake bug#13378: http://debbugs.gnu.org/13378.

 +Sadly, **THIS IS IMPOSSIBLE** until automake bug#13928 is resolved:
 +http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13928
 +
  Details
  ---

 @@ -50,6 +53,12 @@ We also make sure to avoid the warning when it would be 
 irrelevant, i.e.,
  if all source files sit in current directory (thanks to Peter Johansson
  for suggesting this).

 +For some automake 1.x (*before* 2.0 can be released)
 +
 +
 +Find a proper way to fix the blocking automake bug#13928:
 +http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13928
 +
  For automake 2.0
  

 --
 1.9.1







Re: bug#13928: [PATCH] plans: enabling subdir-object by default is blocked on bug#13928

2014-04-22 Thread Stefano Lattarini
On 04/22/2014 09:11 AM, Bert Wesarg wrote:
 Stefano,
 
 may it be possible to disable the 'subdir-object is the
 default'-warning in the 1.14 release series than? We should have this
 warning only active when we are sure that this bug is resolved.

I'd rather not take this step back, since the 'subdir-objects'
option works correctly in most situations.

The right thing to do would be to fix the bug once and for all.
If somebody wants to give it a try, I will be happy to review any
patch in that direction.  Otherwise, I will try to make time to
attempt a fix myself in the coming weeks, but be warned that it
would likely entail dropping automatic dependency tracking support
for all those make implementations that doesn't support an
equivalent of GNU make -include directive.  (FWIW, I actually
believe that is the right way forward, but several people on this
list have expressed their dislike toward such a change, so I will
give them time to try a different approach themselves before
plunging ahead).

Regards,
  Stefano