Re: inlining and squid-3

On Wed, 2003-01-08 at 08:05, Guido Serassio wrote:

> This it should work without problems on the compile side, I'm not sure on
> what happens on dependency side. Now I don't have time to make a test, but
> it will try an experiment ASAP.

Cool.

I've put a sample into the fix_ranges branch (it didn't seem worth
setting a new branch up for - it's trivial in most respects).

Naive dependency tracking may bring the .cci file in into the dependency
tree for every file that includes the .h file, regardless of the inline
setting. Can't do much about that. Automake w/ gcc 3 is doing the right
thing here, and only adding the .cci file to the dependencies when
inlining is turned on.

Oh, and for the record, switching the inline flag on and off is (mostly)
fine:

Case 1: Define changes, No files change. No recompilation occurs, it's
all ok.
Case 2: Define changes, .h file changes. All code is recompiled,
everything is consistent.
Case 3a: Define changes (inline enabled), .cci changes. .cc is rebuilt,
link will fail, as external function is now not available to other
users. Solution: touch the .h file.
Case 3b: Define changes (inline disabled), .cci changes. All dependent
code is recompiled, everything is consistent.
Case 4a: Define changes (inline enabled), .cc changes. Same as 3a.
Case 4b: Define changes (inline disabled), .cc changes. .cc is
recompiled, but not other dependent source files. (So, the function is
inlined everywhere but in the .cc file). If breakpointing is needed...
touch the .h file.

In short, as with most define changes, a global rebuild on change
safest, and as the define is in config.h, this will occur anyway.

Rob

-- 
GPG key available at: <http://users.bigpond.net.au/robertc/keys.txt>.