Re: /bzr/squid3/trunk/ r9573: SourceLayout: acl/, take 1

> I did some research and the situation appears to be clear now: The
> "Registry" design pattern used by ACLs and some other Squid code is not
> going to work "as is" with static libraries. On platforms where
> convenience libraries are, essentially, static libraries, the current
> "registration" code will not work.
>
> There is nothing wrong with that design as such. In short, GNU linker
> and possibly other folks have decided that "static initialization" code
> in a static library is not something that should be linked by default.
> Since the design relies on static initialization to "register" objects
> with Squid, the design does not work.
>
> Our options are:
>
> 1) Various fancy linker options and tricks such as --whole-archive.
> Simple but probably not portable.
>
> 2a) Moving registration code from static libraries to directly linked,
> register-this-class object files. Simple but ugly: The result would be
> similar to very long lists of source files that we are trying to
> eliminate. This is similar to (2b) but on a linker level.
>
> 2b) Moving registration code from static libraries to a directly linked,
> register-everything object file. Simple but ugly: The whole idea of
> registration is to avoid creation of "I know of every class that needs
> to be registered" source code. This is similar to (2a) but on a compiler
> level.
>
> 2c) Replacing implicit registration code with explicit "module"
> initialization, including explicit registration of ACL types. This is
> what Amos is proposing above, essentially. This option is similar to
> option (2b) but the register-everything code would only know about
> "modules" and not individual leaf classes used by those modules. We will
> probably run into problems with circular dependencies among modules,
> which will require splitting modules into several sub-modules, all known
> to the init-everything master code (like we had to split acl and auth
> libraries).
>
> 3) Moving registration code from static libraries to shared libraries. I
> am not sure this will work on platforms where shared libraries are not
> supported. It also feels wrong because using convenience libraries is
> the recommended approach for what we are trying to accomplish, in general.
>
> 4) Adding a pure virtual method that must be implemented in all classes
> that register themselves. This should force the linker to include object
> files defining those virtual methods (and, hence, the registration
> code). This sounds simple and localized, but I have not tested it.
>
>
> I think we should try (4) if it works and do (2c) if it does not.

I'd try (4) first and (2b) as a fallback. But the choice is up to
whoever actually does it (you).
Rationale: if it needs to be ugly, then let it be the simplest possible.

> The key question for me right now is how to test this to avoid
> committing code that does not link right in some environments. Any
> suggestions?

Build-farm.
The memory for eu has been bought, and will be installed soon. This
will allow us to have many x86-based OSes available, hopefully doing a
full test-build at each bzr commit.

-- 
    /kinkie