bug#13378: [IMPORTANT] Make the 'subdir-objects' setup the default, and only available one

[Stefano Lattarini]

Hi Peter, thanks for the feedback.

On 01/07/2013 10:55 PM, Peter Johansson wrote:
> On 1/8/13 6:08 AM, Stefano Lattarini wrote:
>> Severity: wishlist
>>
>> Inspired from Automake-NG commit 'v1.12.1-313-g14fe163' of 2012-06-07,
>> "[ng] subdir-objects: enable unconditionally".
>>
>> The fact that Automake-generated Makefiles place compiled object files in
>> he current directory by default, also when the corresponding source file
>> is in a subdirectory, is basically an historical accident, due to the fact
>> that the 'subdir-objects' option had only been introduced in April 1999,
>> starting with commit 'user-dep-gen-branchpoint-56-g88b5959', and never
>> made the default (likely to avoid backwards-compatibility issues).
>
> If the maintainer didn't wanna break compatibility backwards back then,
> why is it a better idea to break it today?
>
Because the 'subdir-objects' option has since been extensively tested
on field, and shown to be reliable and offer better semantics.  Also,
more importantly, in my experience the great majority of projects that
have source files in a subdirectory not in SUBDIRS already use the
'subdir-objects' option anyway, so they wouldn't experience any kind of
compatibility issue.

>> Since I believe the behaviour enabled by the 'subdir-objects' is the most
>> useful one, and in fact the *only* natural one, I'd like to make it the
>> the only one available, simplifying the Automake implementation and APIs
>> a little in the process.
>>
>> Alas, since this also means changing the default behaviour of Automake
>> ('subdir-objects' is not enabled by default, sadly), this means the
>> transition path will be less smooth than I'd like.  Here it is a sketch
>> for it:
>>
>>    Automake 1.13.2
>>    ---------------
>>
>>    Give a warning in the category 'unsupported' if the 'subdir-objects'
>>    option is not specified.
> 
> I assume user will get no warning when irrelevant, i.e., if all source files
> sit in current directory there is no need to give this warning.
>
Indeed, good point.  The same way we will not require AM_PROG_CC_C_O
if all source files sit in current directory.

>>   This should give the users enough forewarning
>>    about the planned change, and give them time to update their packages
>>    to the new semantic.
> You assume users install every version of Automake you release.
>
This "smoother transition" is more intended to be of help for distro packagers
actually.  They tend to test with more Automake versions, and will likely make
this kind of warnings percolate to the upstream maintainers.  Not perfect, but
the best we can do, reasonably.

> In my understanding going from 1.13 to 1.14 is similar to go from Autoconf
> 2.68 to 2.69.
>
Actually no, the change tend to be much more extensive (as they've been
between 1.12 and 1.13, not always smoothly or pleasantly).  Maybe, to make
this clear, we should name release a 2.0 version instead of a 1.14?

Thanks,
  Stefano