Building CEF with media codecs on Windows Server 2012

[callum]

I was able to get a repo case set up that triggered quickly.

After printing the return from "variables, _ = popen.communicate()" statement at line 82 of setup_toolchain.py, the message written to stdout is "The input line is too long".

I think maybe in my build environment, every time a new batch file is called, (like when I hit "call cef_create_projects.bat") a new copy of the environment is added to the existing one - seems to happen a bunch - there are 4 copies of each environment variable at that point - and once it exceeds, 8191 bytes in length, that message appears.

This doesn't happen if I run the batch files directly from a command window and so that line is okay.

[callum]

If I prune the OS PATH of duplicate entries using this :

Code: Select all

os.environ["PATH"] = os.pathsep.join(collections.OrderedDict((dir.rstrip('/'), 1) for dir in os.getenv("PATH").split(os.pathsep)))

the build progresses. Not that useful since I have no control over the original source file but it tells me that fixing the PATH duplication issue will help.

My joy lasted barely a minute before the next error:

Code: Select all

../../base/win/windows_version.cc(28,2): error: October 2018 SDK (10.0.17763.0) or higher required.
#error October 2018 SDK (10.0.17763.0) or higher required.

The docs here https://bitbucket.org/chromiumembedded/ ... ldSetup.md suggest the version of the Windows 10 SDK required is *exactly* Windows 10.0.15063.468 SDK but maybe that is outdated.

[linuxcef9]

I was able to get a repo case set up that triggered quickly.

You're welcome

The docs here https://bitbucket.org/chromiumembedded/ ... ldSetup.md suggest the version of the Windows 10 SDK required is *exactly* Windows 10.0.15063.468 SDK but maybe that is outdated.

Which version are you trying to build? I usually follow this guide : https://bitbucket.org/chromiumembedded/ ... dows-setup and it works fine for me. It has updated SDK version too btw

I think maybe in my build environment, every time a new batch file is called, (like when I hit "call cef_create_projects.bat") a new copy of the environment is added to the existing one - seems to happen a bunch - there are 4 copies of each environment variable at that point - and once it exceeds, 8191 bytes in length, that message appears.

Just curious - how did you find/verify that there are 4 copies ? What happens in your local environment - 4 copies too?

[callum]

Which version are you trying to build? I usually follow this guide : https://bitbucket.org/chromiumembedded/ ... dows-setup and it works fine for me. It has updated SDK version too btw

Got it and bookmarked; Thank you! - I wish there was one source of truth for this - maybe that's it. My local builds have been working just fine with the older SDK so maybe that's a avery recent requirement change - last few days perhaps?

In any case, installing the newer version of the SDK seemed to do the trick.

Just curious - how did you find/verify that there are 4 copies ? What happens in your local environment - 4 copies too?

The system environment of the box (it's an EC2 instance) is okay. It's the (insane but necessary) chain of python -> Cygwin -> bash -> python -> bash -> batch scripts that all runs inside TeamCity that causes the issue I think. The path appears in the build log and splitting it at ';' then sorting makes it clear each entry is there in triplicate.

Working on starting batch files from Cygwin bash without inheriting the environment and then I might get a build (he said overly optimistically...)

[callum]

I got my builds to work by writing a fragment of Python that asks for the current OS PATH variable, de-duplicates it and writes it to a file which is then picked up in the batch file and used to reset the PATH. Not very elegant but seems to work and the version of CEF I generate worked with my application and supports proprietary media codecs.

[linuxcef9]

I got my builds to work by writing a fragment of Python that asks for the current OS PATH variable, de-duplicates it and writes it to a file which is then picked up in the batch file and used to reset the PATH. Not very elegant but seems to work and the version of CEF I generate worked with my application and supports proprietary media codecs.

Uhh, what if you prune the OS PATH variable and then pass it as a command line argument to your batch file and there, just do
set PATH=%dp0% or something like that?

[callum]

Yep - that might have worked too although I seem to remember the path grew during the lifetime of the batch file. It's all a bit of a mess and triggered by pushing the boundaries of our internal build system past what it was designed for.

Just happy to get a working build that my app can consume.