Hi,
Well then you could say that it has sufficiently aged, so to speak :)
Thanks,
Jaap
On 03/11/2013 02:35 PM, David Arnold wrote:
> On 11/03/2013, at 2:18 PM, Jaap Keuter wrote:
>
> Hi Jaap,
>
>> I know it's a synonym, and I know the autotools guys push for it, and I'm all for it, but...
>> We have to have an idea what we break, on any of the platforms Wirehark is build for, if we do this.
>> So therefore my question how far back this symbiotic existence of INCLUDES and CPPFLAGS goes.
>
> Looks like it was introduced in automake-1.4. Quoting from the NEWS file:
>
> * Added `AM_FOOFLAGS' variable for each compiler invocation;
> e.g. AM_CFLAGS can be used in Makefile.am to set C compiler flags
>
> automake-1.5's documentation includes the same statement about INCLUDES being deprecated in favour of AM_CPPFLAGS as the latest docs do.
>
>
>
> d
>
>> On 2013-03-11 12:00, David Arnold wrote:
>>> On 11/03/2013, at 8:10 AM, Jaap Keuter wrote:
>>> Hi Jaap,
>>>> ref bug 8452.
>>>> When did autotools started to use AM_CPPFLAGS, which are now favorable over
>>>> INCLUDE? Do we break anything with this cleanup?
>>> (I submitted the bug)
>>> The automake documentation says:
>>> INCLUDES
>>> This does the same job as AM_CPPFLAGS (or any per-target
>>> _CPPFLAGS variable if it is used). It is an older name for
>>> the same functionality. This variable is deprecated; we
>>> suggest using AM_CPPFLAGS and per-target _CPPFLAGS instead.
>>> On that basis, I believe they're synonyms, and the automake folks are
>>> pushing everyone towards the AM_* style variables.
>>> I see the annoying logspew using OSX with MacPorts and
>>> automake-1.13.1 (and I *think* on Debian/testing as well, but that box
>>> is inaccessible right now, so I cannot confirm that).
>>> I've updated the bug,
>>> d
