Wiki

Clone wiki

CefGlue / Build

Build Instructions

Prerequirements

Build (Common)

To build CefGlue use build script from command line:

Windows (.NET):

build

Windows (Mono):

build-mono

Posix (Linux, MacOSX):

./build

This will perform all build steps, using auto-configured values. After project was builded, output files will be placed in ./bin/configuration-name/.

Build (Windows)

Default search location of Python it is C:\Python26\python.exe or C:\Python27\python.exe. You can override path to python if you set Python property which will point to python.exe. For example:

build /p:"Python=C:\My Location\Python27\python.exe"

To perform build with Mono, use build-mono instead of build script.

Note: that project originally targeted on .NET 4 Client Profile, but Mono dosn't support Client profile - and code will be compiled using .NET 4 Profile (Full).

Build (Linux)

TODO: (describe it, currently is doesn't have any differences)

Build (Internals)

CefGlue uses XBuild (Mono) and MSBuild (.NET) as build tool, mainly 'cause:

  • it is doesn't require additional dependencies;
  • it is simple cross-platform solution.

But while XBuild it is restricted subset of MSBuild - it is important to do not use MSBuild-specific features.

Build targets:

  1. BuildInterop: builds interop files using CEF translator tool;
  2. BuildCore: builds CefGlue assembly;
  3. BuildDecorator: builds decorators using CefGlue assembly;
  4. BuildRemains: builds everything included in solution file;
  5. BuildBin: Copy project outputs into bin directory for packaging.

Once BuildInterop and BuildDecorator steps are done, you can ignore this steps, unless you do not change dependents. It means, that you can perform BuildRemains step from development environment.

Development environments:

On Windows: Visual Studio it is best choice: it is internally uses msbuild for building and managing project files, as result - it know about all defines to compiler and etc. even if them evaluated (not defined as constants).

On other systems - MonoDevelop not bad choice, but it has much simpler project file management, as result - it is doesn't know about compiler defines, output paths, and etc. if them evaluated.

So, avoid complex evaluations for important properties, like CompilerDefines, OutputPath, etc. For example, if OutputPath will be calculated for all configurations - then MonoDevelop can't find executables, and as result your builds will be failed, and MonoDevelop becomes completely useless.

Updated