On Monday 2014-01-13 10:56, Patrick McHardy wrote:
>On Mon, Jan 13, 2014 at 10:47:24AM +0100, Jan Engelhardt wrote:
>> >
>> >Why aren't we instead evaluating the results?
>>
>> I don't know - I did not write those lines in the first place. A
>> reasonable hypothesis is that this is just old boilerplate copied
>> from somewhere else rather than actually looking for what the
>> commands executed by make really need.
>
>That was not my question. I asked why we're not evaluating *instead* of
>removing them.
Evaluation would be redundant: nftables is not (meant to be) portable!:
>> Furthermore, like a lot of NF software, it is tied to Linux where the
>> existence of arpa/inet.h, fcntl.h, malloc(3), and so on is
>> pretty much guaranteed.
>> How so? Commit says:
>>
>> If -I. is on the command line …
>>
>> and -I. is on the command line with autoconf (more precisely,
>> -I${srcdir} -I${builddir} -I${path_to_config_h} is).
>>
>> … #include <parser.h> becomes (=matches) ./parser.h
>> instead of ../include/parser.h.
>>
>> Basically you never ever want to have a header with the same include
>> path. Even #include <regex.h> is prone to ambiguity if you had
>> -I/usr/include/boost (which you should not of course, but people
>> do all kinds of weird things sometimes), suddenly matching
>> /usr/include/boost/regex.h instead of /usr/include/regex.h.
>>
>> It's all about distributions, and it takes a regular packager to know.
>
>Jan, the changelog simply needs a description what is wrong
Naming two header files the same.
>why it is wrong
When same-name header files can both potentially be in the include
search path, it creates an ambiguity as to which one is chosen.
>what is changed.
The filename.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
