blob: 9b8796eeddbbe74c8c62be73030b9032b9414c58 [file] [log] [blame]
# Copyright 2014 The Chromium Authors. All rights reserved.
# Use of this source code is governed by a BSD-style license that can be
# found in the LICENSE file.
# Modifications Copyright 2017 Google Inc. All Rights Reserved.
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
# =============================================================================
# WHAT IS THIS FILE?
# =============================================================================
#
# This is the master GN build configuration. This file is loaded after the
# build args (args.gn) for the build directory and after the toplevel ".gn"
# file (which points to this file as the build configuration).
#
# This file will be executed and the resulting context will be used to execute
# every other file in the build. So variables declared here (that don't start
# with an underscore) will be implicitly global. Note that unlike in GYP, in
# GN the practice is to limit the number of global variables and define
# variables in .gni files instead.
#
# YOU SHOULD ALMOST NEVER NEED TO ADD FLAGS TO THIS FILE. GN allows any file in
# the build to declare build flags.
#
# - If you want to add a new per-platform variable (e.g. javascript_engine,
# enable_map_to_mesh, etc.), add that to //cobalt/build/config/base.gni or
# //starboard/build/config/base.gni.
#
# - If you want to add an actual build arg (i.e. something a developer would
# specify at compile time, such as cobalt_use_fastbuild or use_asan):
#
# - If your build arg will only be used in a single target, say //cobalt/foo,
# you can put a declare_args() block in //cobalt/foo/BUILD.gn and use it
# there. Nobody else in the build needs to see the flag.
#
# - Otherwise, you can put the argument in a .gni file. This should be put in
# the lowest level of the build that knows about this feature (which should
# almost always be outside of "build" directories!).
#
# - If your flag toggles a target on and off or toggles between different
# versions of similar things, write a "group" target that forwards to the
# right target (or no target) depending on the value of the build flag. This
# group can be in the same BUILD.gn file as the build flag, and targets can
# depend unconditionally on the group rather than duplicating flag checks
# across many targets.
# =============================================================================
# PLATFORM SELECTION
# =============================================================================
#
# There are two main things to set: "cobalt_config" and "target_platform".
# These are set via `gn args`. The starboard platform path is then calculated
# from target_platform. Finally, we import a file containing platform-specific
# configuration (such as the default toolchain and target OS/architecture) that
# must be set in BUILDCONFIG.gn.
declare_args() {
# The current build configuration.
cobalt_config = "gold"
# The platform we are building for.
target_platform = ""
}
assert(target_platform != "", "You must specify a target platform")
# The relative path from // to the directory containing the
# BUILD.gn file defining the starboard_platform target
starboard_path = rebase_path(exec_script("//cobalt/build/get_starboard_path.py",
[ target_platform ],
"trim string"),
"//")
# Import platform-specific build config variables
import("//$starboard_path/buildconfig.gni")
# =============================================================================
# THE TARGET OS AND ARCHITECTURE
# =============================================================================
#
# GN has three families of built in variables:
# - host_os, host_cpu, host_toolchain
# - target_os, target_cpu, default_toolchain
# - current_os, current_cpu, current_toolchain.
#
# There are three different types of each of these things: The "host"
# represents the computer doing the compile and never changes. The "target"
# represents the main thing we're trying to build. The "current" represents
# which configuration is currently being defined, which can be either the
# host, the target, or even (in theory) something completely different. GN will
# run the same build file multiple times for the different required
# configuration in the same build.
#
# Note the default_toolchain isn't symmetrical (you would expect
# target_toolchain). This is because the "default" toolchain is a GN built-in
# concept, and "target" is something our build sets up that's symmetrical with
# its GYP counterpart. Potentially the built-in default_toolchain variable
# could be renamed in the future.
#
# When writing build files, to do something only for the host:
# if (current_toolchain == host_toolchain) { ...
if (defined(target_os_)) {
target_os = target_os_
} else {
target_os = "unknown"
}
target_cpu = target_cpu_
if (current_os == "") {
current_os = target_os
}
if (current_cpu == "") {
current_cpu = target_cpu
}
# =============================================================================
# TARGET DEFAULTS
# =============================================================================
#
# Set up the default configuration for every build target of the given type.
# The values configured here will be automatically set on the scope of the
# corresponding target. Target definitions can add or remove to the settings
# here as needed.
# All binary targets will get this list of configs by default.
_shared_binary_target_configs = [
"//cobalt/build/config:compiler_defaults",
"//cobalt/build/config:compiler_defaults_$cobalt_config",
"//starboard/build/config:compiler_defaults",
"//$starboard_path:compiler_defaults",
"//$starboard_path:compiler_defaults_$cobalt_config",
"//cobalt/build/config:final_executable_target_config",
"//starboard/build/config:no_pedantic_warnings",
"//starboard/build/config:default_rtti",
"//starboard/build/config:default_optimizations",
]
# Apply that default list to the binary target types.
set_defaults("executable") {
configs = _shared_binary_target_configs
}
set_defaults("static_library") {
configs = _shared_binary_target_configs
}
set_defaults("shared_library") {
configs = _shared_binary_target_configs
}
set_defaults("source_set") {
configs = _shared_binary_target_configs
}
# =============================================================================
# TARGET TYPE SETUP
# =============================================================================
# Define some additional target types. These are useful on platforms where the
# native code may require an additional packaging step (ex. Android).
if (!defined(test_target_type)) {
test_target_type = "executable"
}
template("test") {
target(test_target_type, target_name) {
# Explicitly forward visibility, implicitly forward everything else.
# Forwarding "*" doesn't recurse into nested scopes (to avoid copying all
# globals into each template invocation), so won't pick up file-scoped
# variables. Normally this isn't too bad, but visibility is commonly
# defined at the file scope. Explicitly forwarding visibility and then
# excluding it from the "*" set works around this problem.
# See http://crbug.com/594610
forward_variables_from(invoker, [ "visibility" ])
forward_variables_from(invoker, "*", [ "visibility" ])
}
}
if (!defined(final_executable_type)) {
final_executable_type = "executable"
}
template("final_executable") {
target(final_executable_type, target_name) {
# See comment above
forward_variables_from(invoker, [ "visibility" ])
forward_variables_from(invoker, "*", [ "visibility" ])
}
}
# Set the default toolchain and the host toolchain
set_default_toolchain(target_toolchain)
assert(defined(host_toolchain))