More details on "official" build type setting?

[HarmlessDave]

To perform an “official” build set GYP_DEFINES=buildtype=Official. This will disable debugging code and enable additional link-time optimizations in Release builds.

Would you mind adding a little more detail to this, about what changes in Release (not Debug) builds when the Official build type is used? I don't recall seeing it when I was building from source in early 2015.

One reason I'm interested is for Windows 32-bit the size of a zipped Release build of chromium+CEF3 has increased by around 4 MB from 2272. I'm wondering how much space we can get back.

But I'm also a little wary of the compiler optimizations being too aggressive. Many years ago when I was at another company we would (rarely) get incorrect double precision floating point results by turning on higher optimization levels in Visual Studio 6, apparently because of compiler bugs.

[magreenblatt]

See https://groups.google.com/a/chromium.or ... BhJhWmBwAJ for additional background.

[amaitland]

One reason I'm interested is for Windows 32-bit the size of a zipped Release build of chromium+CEF3 has increased by around 4 MB from 2272. I'm wondering how much space we can get back.

There have been quite a few resource files added, they are surprisingly quite large. Whilst libcef it's self has grown, most of that is a result of ffmpeg and pdf viewer being statically compiled into libcef.

[HarmlessDave]

See https://groups.google.com/a/chromium.or ... BhJhWmBwAJ for additional background.

Thanks!

For some reason I needed to set the buildtype before other flags, but that might have been a PEBKAC error

Code: Select all

source did not rebuild:
GYP_DEFINES             "proprietary_codecs=1 ffmpeg_branding=Chrome buildtype=Official"

source did rebuild:
GYP_DEFINES             "buildtype=Official proprietary_codecs=1 ffmpeg_branding=Chrome"


[magreenblatt]

How are you setting the variables? It may be confused by the quotes.

[HarmlessDave]

I'm setting it using Control Panel > System > Advanced System Settings. I had the other 2 flags in quotes last year, so added the buildtype inside the quotes.

I think you're right about the quotes breaking the flag, since building that way didn't remove the XP error.

I've removed the quotes and tried again, but now I'm getting an out of memory error at the link step, when I've done 4 (non-Official) builds of this source before without errors.

This is a Windows 8.1 Pro 64-bit system with 8 GB RAM and 12 GB free disk space on the boot drive, 168 GB free space on disk E: where I'm building CEF. I'm using Visual Studio 2013 Premium Update 4.

Code: Select all

GYP_DEFINES=buildtype=Official proprietary_codecs=1 ffmpeg_branding=Chrome
GYP_GENERATORS=ninja,msvs-ninja
GYP_MSVS_VERSION=2013

Code: Select all

ninja: Entering directory `out\Debug'
[2/4] LINK_EMBED(DLL) libcef.dll
FAILED: libcef.dll libcef.dll.lib libcef.dll.pdb
e:\cef-2526\depot_tools\python276_bin\python.exe gyp-win-tool link-with-manifest
s environment.x86 True libcef.dll "e:\cef-2526\depot_tools\python276_bin\python.
exe gyp-win-tool link-wrapper environment.x86 False link.exe /nologo /IMPLIB:lib
cef.dll.lib /DLL /OUT:libcef.dll @libcef.dll.rsp" 2 mt.exe rc.exe "obj\cef\libce
f.libcef.dll.intermediate.manifest" obj\cef\libcef.libcef.dll.generated.manifest
 ..\..\cef\libcef_dll\libcef.dll.manifest
Generating code
Finished generating code
LINK : fatal error LNK1102: out of memory
Traceback (most recent call last):
  File "gyp-win-tool", line 313, in <module>
    sys.exit(main(sys.argv[1:]))
  File "gyp-win-tool", line 29, in main
    exit_code = executor.Dispatch(args)
  File "gyp-win-tool", line 71, in Dispatch
    return getattr(self, method)(*args[1:])
  File "gyp-win-tool", line 169, in ExecLinkWithManifests
    subprocess.check_call(ldcmd + add_to_ld)
  File "e:\cef-2526\depot_tools\python276_bin\lib\subprocess.py", line 540, in c
heck_call
    raise CalledProcessError(retcode, cmd)

A google search of the LNK1102 error turned up a Microsoft page suggesting I upgrade to VS2013 (which I already use) and a Google Groups thread from 2014 suggesting I use the latest toolchain (which automate-git.py fetched for me last week).

If anyone else has run into this and solved it, any suggestions would be helpful.

[magreenblatt]

The official build performs whole program optimization so 8GB of RAM is likely not enough.

[HarmlessDave]

Thanks, I've ordered a RAM kit.

This chromium issue has a poster who argues that buildtype=official might not make sense for Debug builds but gets applied anyway: https://bugs.chromium.org/p/chromium/is ... ?id=457499
... but sadly they decided on "wontfix."

I suppose I cod try '--no-debug-build'' for Official and then '--no-release-build' with Official removed but then I have to be careful about copying the right files from each build into the visual studio project I link to.

Edit: for anyone else trying this, more RAM is the answer. I managed to get it to build with just 8 GB by forcing Windows to create a 16GB min / 24 GB max pagefile on another drive, then watched in Task Manager as memory use hit 99%, but 16 GB+ of RAM would have been faster.