[squid-dev] src/forward.h

[Amos Jeffries]

On 20/06/17 21:06, Christos Tsantilas wrote:
> Στις 20/06/2017 01:59 πμ, ο Alex Rousskov έγραψε:
>>> revno: 15212
>>> committer: Amos Jeffries <squid3 at treenet.co.nz>
>>> branch nick: 5
>>> timestamp: Tue 2017-06-20 01:53:03 +1200
>>> message:
>>>    Fix build errors with automake after rev.15194
>>>       We cannot name files in src/ the same as files in
>>> sub-directories due to
>>>    certain automake still implicitly using -I. for search paths.
>>
>>
>> Aggregating frequently used forward declarations for src/ code is a good
>> idea IMO. If we cannot use a src/forward.h name, then we should use
>> another name to implement that idea (rather than to kill the idea
>> itself). I can suggest:
>>
>> 1. src/fwd.h (sufficient but should not be replicated to other dirs)
>> 2. src/forward_.h (emphasizes that we are working around a problem)
>> 3. src/src_fwd.h (lowers the chance of replication in other dirs)
>
> We can use the $topdir/include/forward.h

Nope. While automake is the source of the problem, the file paths in .am 
it is dealing with are fine.

The problem is how the problematic automake's add -I. implicitly to the 
compiler path search strings. So the bug shows up when .h files use:

  #include "forward.h"

. For any name where the local src/foo/bar.h matches a src/bar.h (or 
includes/bar.h) and build is running for src/foo/ we cannot be sure 
which of the bar.h files will be loaded - usually the wrong (./bar.h) one.



The duplicate code you had to add to src/servers/forward.h to predefine 
the Pointer class despite src/forward.h supposedly being included 
earlier shows what this can lead to.
src/servers/Server.cc was loading servers/Server.h which was loading -I. 
forward.h and resulting in undefined errors unless src/servers/forward.h 
contained cut-n-paste identical definitions to src/forward.h.


>>
>> I suggest #1, but it is not a strong preference. Any string preferences,
>> objections, or better ideas?
>>

For the general case of all src/*.h definitions having some code 
duplication on the pre-defines is not too terrible.

The SourceLayout project plan was to move things into sub-dirs and 
remove that duplication with subdir/forward.h files. While that project 
is proceeding very slowly, there is progress and when things like this 
cause pain points that just makes more incentive to fix that pain in the 
way long-term plan laid out.

FYI: Now that the build is working consistently again I am testing 
whether MasterXaction can be moved into libbase, which was defined as 
being the subdir for these type of widespread things without a clear 
component.


Amos