On 17 Aug, To: [email protected] wrote:
> On 16 Aug, Don Lewis wrote:
>> On 7 Aug, Damjan Jovanovic wrote:
>>> Hi
>>>
>>> branches/gbuild-reintegration has been merged to trunk. It has > 136
>>> patches and makes many changes throughout the code, so you probably need to
>>> "dmake clean" before rebuilding.
>>>
>>> I haven't fixed the Windows build performance regression caused by issue
>>> #117845, so if you're building on Windows use --disable-pch which only
>>> extends your build time by around 2 hours instead of 6. If you aren't happy
>>> with this, please help me figure out the problem.
>>
>> I did some sleuthing ...
>>
>> I compared build logs between --enable-pch and --disable-pch builds. The
>> compiler command line for the --enable-pch build has the additional
>> option
>> -DPRECOMPILED_HEADERS
>> which causes precompiled_foo.hxx to pull in a whole wad of headers even
>> if they aren't needed to compile an individual .cxx file. That's why
>> the build is taking longer. A precompiled version of
>> precompiled_foo.hxx is build beforehand by passing
>> -Ycprecompiled_foo.hxx to the compiler, but gbuild neglects to tell the
>> compiler to use it when building all the .cxx files because it never
>> passes -Yuprecompiled_foo.hxx to the compiler.
>>
>> That option is supposed to come from
>> gb_PrecompiledHeader_get_enableflags or
>> gb_NoexPrecompiledHeader_get_enableflags in LinkTarget.mk, but for some
>> reason that isn't getting activated.
>>
>> I don't see any obvious recent changes that might have broken this.
>
> More digging ...
>
> LinkTarget.mk contains some logic to that only enables the use of
> precompiled headers when the compiler flags that were used to build the
> precompiled header match the flags used to compile the target source
> file. If I compare the compiler flags used to build the precompiled
> header with the flags used to compile one of the source files, I see
> these differences:
>
> @@ -33,7 +33,6 @@
> -D_DLL_
> -DPRECOMPILED_HEADERS
> -DSW_DLLIMPLEMENTATION
> --DSW_DLLIMPLEMENTATION
> -Gd
> -GR
> -Gs
> @@ -78,13 +77,13 @@
> -wd4826
> -Zc:wchar_t-
> -Zm500
> +-DEXCEPTIONS_ON
> +-EHa
> -Ob1
> -Oxs
> -Oy-
> --DEXCEPTIONS_ON
> --EHa
> --Fd$W/LinkTarget/pdb/Library/isw.lib.pdb
> --I$S/sw/inc/pch/
> +-Fd
> +-I$S/sw/source/core/access/
> -IC:/aoo/aoo-trunk/main/solver/420/wntmsci12.pro/inc/stl
> -I$S/sw/source/core/inc
> -I$S/sw/source/filter/inc
> @@ -108,7 +107,5 @@
> -I$O/inc/udkapi
> -I$O/inc/offapi
> -c
> -$S/sw/inc/pch/precompiled_sw.cxx
> --Ycprecompiled_sw.hxx
> --Fp$W/PrecompiledHeader/nodebug/precompiled_sw.hxx.pch
> --Fo$W/PrecompiledHeader/nodebug/precompiled_sw.hxx.pch.obj
> +$S/sw/source/core/access/acccell.cxx
> +-Fo$W/CxxObject/sw/source/core/access/acccell.o
>
> The potentially important differences are:
>
> * When building the precompiled header, -DSW_DLLIMPLEMENTATION is
> repeated
>
> * These flags are used when building the precompiled header:
> -Fd$W/LinkTarget/pdb/Library/isw.lib.pdb -I$S/sw/inc/pch/
> whereas these flags are used when building the target:
> -Fd -I$S/sw/source/core/access/
>
> Another observation is that if an override of the compiler flags for
> a particular target disables the use of precompiled headers, then
> -DPRECOMPILED_HEADERS should not be passed to the compiler if -Yu is
> not. That would avoid the pessimization of including all of those extra
> headers that are not used.
The answer turns out to be none of the above. I didn't find the cause
for the duplication of -DSW_DLLIMPLEMENTATION, but it doesn't matter
because the duplicate is squashed by the comparison which uses
$(sort ...). I don't think the latter difference is part of the
comparison.
The cause turns out to be that $(PCH_NAME) is not inherited by the
compile, so the -Yu compile flag is not used. I've fixed this in
r1758061.
Doing "build --all -P2 -- -P2" on a two-core machine now takes:
377 minutes with --disable-pch
278 minutes with --enable-pch
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]