microsoft
/
winrtc
зеркало из https://github.com/microsoft/winrtc.git
1
0
Форкнуть 0
Код Задачи Пакеты Проекты Релизы Вики Активность
Страница: Home
Страницы
Home
8 Home
Osahumen Uyi Aghasomwan редактировал(а) эту страницу 2020-06-26 16:54:52 -07:00
Содержание

Objective

The goal of this documentation is to provide information for newcomers to winRTC or a person who wish to understand how the build system of winRTC works and how to make changes to it. These information is used to provide details about the different aspect of the winRTC build system. This documentation will give show what file in the build system is the most important in in executing a successful build. Shows how to make changes to the build system to melt a desired need, also shows how to add a build to the build system.

WINRTC BUILD SYSTEM

The winRTC build system uses the build system from webRTC. Ninja is a build system that focus on speed. Ninja build was designed to have input file generated by a high-level build system. Ninja low-level approach makes it possible for embedding into more featureful build systems. Ninja has different generators for producing ninja file (i.e. GN, Blade Build, Blueprint, CMake. See Full list). WebRTC uses the GN to generate the ninja files. gn was chosen as the generator for the ninja-build used for webRTC because it can generate Ninja files for all platforms supported by Chrome. Some other reason GN was used are, it files are more readable and more maintainable compare to other generators, and GN supports automatically re-running itself as needed by Ninja as part of the build.

HOW THE WEBRTC BUILD IS SYSTEM STRUCTURED

The Build system is made up of build files that targets specific platforms containing all the libraries, variable and dependencies required for building webRTC application on a specific platform. There are also lots of file in the build system that the BUILD.gn depend on (i.e. gni files and BUILDCONFIG). gni files are one of the essential files that the build system because .gni is usually used to create template and used for holding global or shared variable that will be used across multiple build files. The master GN build configuration is the BUILDCONFIG.gn (c:\webRTC\src\build\config\BUILDCONFIG.gn). After the BUILDCONFIG is built the result is then used to executed other build file in the build. To the BUILDCONFIG you should almost never need to add flags to this file. GN allows any file in the build to declare build flags. If you need a flag for a single component, you can just declare it in the corresponding BUILD.gn file.

CREATING AND REMOVING DEPENDENCIES TO THE BUILD SYSTEM

When creating a dependency for the build, create you C++ source file that your executable is going to depend on.

Creating a Dependency:

Add a directory in the winRTC directory. In the new created directory create a BUILD.gn file, example.cc and example.h.

To the example.cc add your desire code

#include example.h

namespace webrtc{

}

To your example.h

#ifndef EXAMPLE_HELLO
#define EXAMPLE-HELLO

namespace webrtc{

}

#endif

Creating the BUILD.gn file.

Import(“../webRTC/src/webrtc.gni”)

If (is_win) {
  rtc_source_set(“example_hello”){
	deps=[
		“../webRTC/src/example:examples”,
	  	“../webRTC/src/example: read_auth_file”,
	]
	
	source = [“example.cc”, “example.h”,]
	
	libs = [“windowsapp.lib”]
  }
}

Adding this to desire BUILD.gn you wish to make adjustment to. This example is making the change to webrtc/src/BUILD.gn. When adding your dependencies make sure its in an alphabetical order.

If (!build_with_chromim){
  deps =[ ":rtc_unittests",
          ":slow_tests",
          ":video_engine_tests",
	  # Adding the dependency created 
          "../winrtc/examples:example_hello",
          "modules/video_capture:video_capture_internal_impl",
          "pc:peerconnection_unittests",
          "pc:rtc_pc_unittests",
          "rtc_tools:rtp_generator",
    ]
}

OR

Also, a dependency can be added by using conditions, therefore when the conditions is met the build system will add the list of dependencies.

If (!build_with_chromim){
	If (is_win){
		deps += ["../winrtc/examples:example_hello",]
 }
}

Removing a Dependency from a build

To remove a dependency can also be done using conditions, therefore when the conditions is met the build system will remove the list of dependencies.

If (!build_with_chromim){
	If (current_os == "winuwp"){
		deps -= ["../winrtc/examples:example_hello",]
 }
}

Other to delect dependecies is commenting the dependency out, this will prevent the build system from including the dependecy in the build process.

If (!build_with_chromim){
  deps =[ ":rtc_unittests",
          ":slow_tests",
          ":video_engine_tests",
        "../winrtc/examples:example_hello",
          "modules/video_capture:video_capture_internal_impl",
          "pc:peerconnection_unittests",
          "pc:rtc_pc_unittests",
          "rtc_tools:rtp_generator",
    ]
}

ADDING OPTION AND VARIABLE TO BUILD SYSTEM

Variable:

Adding variable the build system using variable name equals to the desired value. This example shows how a variable is added to build.gn file created in the above example. Adding the visibility variable to the build. Visibility define which targets can depend on the current one.

if(is_win){
	rtc_source_set(“example_hello”){
	
		# adding the visbility to the build.
		# Passing ("*") as the value defaults to public 
		visibility = ["*"]
	
		deps=[
			“c:/webRTC/src/example:examples”,
	  		“c:/webRTC/src/example: read_auth_file”,
		]
	
		sources = [“example.cc”, “example.h”,]

		libs = [“windowsapp.lib”]
	}
}

There are different variables used for file name handling(see list).

Options:

Adding option to the build system

--testonly= true \\ Restrict outputs to targets with the testonly flag set
      accordingly
--type= executable \\ Restrict outputs to targets matching the given type.
--as= (buildfile|output|output) \\ used for printing target

There are different options variables(see list).

A target is a node in the build graph. It usually represents executable or library file that will be generated. Targets depend on other targets.

ADDING AND REMOVING LIBRARIES TO THE BUILD SYSTEM

When adding library to the build system, make sure your libs is inside a config. Config is used to hold configurations objects. Configs solve a problem where the build system needs to have a higher- understanding of various compiler settings.

Adding a libraries:

Config(“myconfig”) {
libs = [
	"advapi32.lib",
      	"comdlg32.lib",
      	"dbghelp.lib",
    ]
}

or

Config(“myconfig”) {
libs = [
	"advapi32.lib",
      	"comdlg32.lib",
      	"dbghelp.lib",
    ]

#Adding to the list of libraries
if (current_os == "winuwp") {
      libs += [
        "dloadhelper.lib",
        "WindowsApp.lib",
	]
}

Removing a library:

Config(“myconfig”) {
	libs = [
		"advapi32.lib",
      		"comdlg32.lib",
      		"dbghelp.lib",
    	]

	if (current_os == "winuwp") {
      		libs += [
			"dloadhelper.lib",
			"WindowsApp.lib",
		]

	#removing from list of libraries
	if (current_cpu == “x86”) {
		libs -= [
			"comdlg32.lib",
      			"dbghelp.lib",
		]
   	}
}

HOW TO UPDATE THE DEPENDENCIES FROM UPSTREAM

The way to update a dependencies from upstream is using Patch file. Patch file is used to updates files according to instructions contained in a separate file.

Using the same example for creating and adding a dependency to the build system. Using of patch file, the previous file will be used to update the dependency from upstream.

Using this following command. adding the directory example created above to upstream.

# Adding the directory to the repo
$git add examples

# commit the changes
$git commit -m "comment"

# pushing the change
$

# creating the patch file
$git format-patch -1 -0 <patches>

if the dependency is already added to the repo. The dependency can be acquired using the;

# pulling the changes for upstream
$ git Pull

#used the patch file to check the changes made from on line
$ git format-patch -1 -0 <patches>

FILES INVOLVED (AND THEIR PURPOSES) IN THE BUILD PROCESS FOR UWP AND WIN32

These files are used to declare all the targets, flags, defines, dependencies, and libraries needed to run the winuwp, win32 successfully. The files also allow build system to set the environment for the winuwp and win32 to compile with all the required SDKs and libraries.

The file that are involved in the build of UWP are:

UWP WIN32
config\BUILD.gn win\BUILD.gn
config\BUILDCONFIG.gn config\win\BUILD.gn
config\win\BUILD.gn toolchain\win\midl.gni
toolchain\win\BUILD.gn toolchain\win\midl.py
toolchain\win\setup_toolchain.py toolchain\win\setup_toolchain.py
toolchain\win\tool_wrapper.py toolchain\win\tool_wrapper.py
vs_toolchain.py vs_toolchain.py

build\config\BUILD.gn: This file holds the legacy features defines applied to all targets.These defines are applied to most compile in the build and they are relevant to to a few files. This file works with BUILDCONfig, using the buildflag system which will create headers containing the defines needed for UWP and win32.

build\config\BUILDCONFIG.gn: This file holds the configuration for build files. After this file executes that resulting context is used for excuting other files in the build win32 and uwp needs. This file also used to hold the configuration for platform selection.

build\config\win\BUILD.gn: This purpose of this file is to separate out the logic that is used by Windows-only.

build\toolchain\win\BUILD.gn: This file is used to setup the visual studio state. This file helps in development environment for win x86 and Win x64 and its arguments holds the compiler wrapper tool.

build\toolchain\setup_toolchain.py: This file copies the given "win tool" (which the toolchain uses to wrap compilerinvocations) and the environment blocks for the 32-bit and 64-bit builds on Windows to the build directory.

build\toolchain\win\tool_wrapper.py: This file is copied to the build directory as part of toolchain setup and is used to set up calls to tools used by the build that need wrappers.

<<<<<<< HEAD build\vs_toolchain.py: This file is used to set up the OS environment to use the depot_tools (Tools for working with Chromium development. [Read more](https://chromium.googlesource. com/chromium/tools/depot_tools) ) VS toolchain with gyp, and returns the location of the VC runtime DLLs F

build\vs_toolchain.py: This file is used to set up the OS environment to use the depot_tools (Tools for working with Chromium development. Read more ) VS toolchain with gyp, and returns the location of the VC runtime DLLs

efe73e7aa2f7503618f68b82c4ba6b3a39b93213 build\win\BUILD.gn: This file holds the output and scripts files needed for creating the toolchain configuration need for the window environment.

These files are used to declare all the targets, flags, defines, dependencies, and libraries needed to run the winuwp, win32 successfully. The files also allow build system to set the environment for the winuwp and win32 to compile with all the required SDKs and libraries.

HOW THE TOOLCHAINS (AND PLATFORM BUILD TOOLS/SDKS) ARE BUILT AND USED

A toolchain is a set of commands and build flags used to compile the source code. Toolchains are used for setting the platform environment. Toolchain can be used to set the visual Studio state. For the toolchain/win, the argument in the BUILD.gn are the visual Studio path and the compiler wrapper tools. There three variables used for the toolchain, they are:

  • current_toolchain tells you the toolchain for the current execution environment.
  • host_toolchain is set by the Chrome build to be the appropriate toolchain to run on the compiling computer.
  • default_toolchain is the “main output”, which is the target in GYP.

There are more than one toolchain in use at once in the webRTC build and a target can exist simultaneously in multiple toolchains. The webRTC build files is executed once for each toolchain it is referenced in so the GN code can vary all parameters of each target (or which targets exist) on a per-toolchain basis. The toolchain configuration is two-way. In the default toolchain (i.e. the main build target) the configuration flows from the build config file to the toolchain. The webrtc build config file looks at the state of the build (OS type, CPU architecture, etc.) and decides which toolchain to use (via current_toolchain). In secondary toolchains, the configuration flows from the toolchain to the build config file: the "toolchain_args" in the toolchain definition specifies the arguments to re-invoke the build.

For more information: