Aiot application innovation competition -- I am the master of my project, and use gn+ninja to complete the system construction (vscode Development)

background

since 21 Contact in OpenHarmony after , That's right GN+Ninja Of particular interest , Then I tried to make a simplified version of the construction system . In this competition , If you don't consider using official IDE Words , I don't want to use makefile（ The main thing is that I can't write ）, So try to use GN+Ninja It's done rt1062 Building systems .windows Relevant configuration contents are not verified under , In theory, we can use .

Project address

https://gitee.com/walker2048/rt1060-gnu-gcc/tree/gn%2Bninja/

The content of this competition will be open source at this address

Source directory structure

.
├── build               # Compile build configuration file 
├── components          # General components （ Hardware independent components ）
├── hardware            # Hardware related code 
├── out                 # Compile product directory （ Run the compile command to generate ）
├── solutions           # Application directory 
└── TinyOS              # tencent TinyOS Kernel Directory 

For people who like to toss and turn , There is no happier thing about using your most familiar directory and source code structure ( I am in charge of my project , There are too many things to toss about ). After all, I am familiar with a RTOS It also takes a lot of time . Fortunately, Tencent TinyOS The positioning of is lightweight code , Simplify code functionality and configuration , Can easily adapt to . If you don't like this directory structure , You only need to modify the corresponding directory , And update the dependency configuration . Also remember to modify build/config/compiler/BUILD.gn In the document include_dirs Field contents , Just update the header file directory . The difficulty is not high .

GN + Ninja The advantages of building an environment

1. The code dependency tree is clear
2. GN The grammar is easy to understand
3. The construction script has a clear division of labor
4. Compilation parameters are visible
5. It's fast to build

in summary ,GN + Ninja Can be an individual or a company when considering a new build system , A very good choice .

Usage method

1、 Build configuration commands ( Use export BOARD=TencentOS_tiny_EVB_AIoT The command is set first BOARD environment variable , And then in bash Execution in environment )：

gn gen out/${BOARD} --args="product = \"${BOARD}\""

Command parsing ： If you modify the build script （ Such as BUILD.gn file ）, It should be carried out first gn gen Command to generate a new ninja Build file ,ninja Only then did I know that the construction content had changed . Generally, it is not necessary to use ninja Command split .out/${BOARD} Build the configuration directory for the specified build , --args="product = \"${BOARD}\"" For transmission to gn Parameters of , tell gn by product The name is ${BOARD} Environment variable configuration related parameters （ Such as looking for real executable Objects and related dependencies , And compile parameters ）.

2、 Compile build commands ：

ninja -C out/${BOARD}

3、 Recommended use ：

I compare lazy , Like to be directly in ~/.bashrc In the configuration BOARD environment variable , And set the command alias ：

alias gbuild='gn gen out/${BOARD} --args="product = \"${BOARD}\"" && ninja -C out/${BOARD}'
alias gdesc='gn desc out/${BOARD} --args="product = \"${BOARD}\"" //hardware/board/${BOARD}'
alias gformat='find . -name *\.gni | xargs gn format && find . -name BUILD.gn | xargs gn format'

For example, the above are gbuild command , Executed the build configuration command （ It is generally in the range of a few milliseconds to tens of milliseconds ） And compile build commands （ New build on 11 About seconds , Incremental compilation cannot 1 second , Much faster than official tools ）;gdesc command , Used to obtain the dependency tree related to the compilation configuration , Compile parameters, etc ;gformat command , For formatting gn The configuration file .

Maybe a friend will ask how to clean up the compiled products , direct rm -rf out directory .

4、 Burn command ：

Burn and use pyocd Burn , Carry out orders ( You can use elf file ,hex Burn the file , Both have addresses , There is no need to specify the burning address )

pyocd flash out/${BOARD}/bin/${BOARD}.hex

5、 Add source

It is inevitable to modify the source code to complete the function , add to c Source files and .h The header file . Let's start with adding c Source file , You can add... In the component directory c Source file , Only in the component of BUILD.gn Modify... In configuration file sources Field content is enough . If you need to add new components , Other components can be copied BUILD.gn File here , Modify component name , Component dependency （deps）, Source file （sources） And so on . If you need to add .h The header file , There are two cases .1、 The modified file is only used within the component , There is no need to define the header file directory （ Reference by relative path ）;2、 If the header file is a component external interface definition file , You need the above mentioned build/config/compiler/BUILD.gn In the document modify include_dirs Field contents .

For students who don't want to know the details , Just focus on the previous content , Interested in learning about GN To build a system , You can look down .

=====================================================================

Now let's explain GN Build configuration files and some knowledge points . because gn It is rarely used in domestic projects , Chinese materials are very few , Want to learn gn Knowledgeable , Only through gn help Commands and official website documents （ Basically help Orders are about the same ）, And practical application to learn . Fortunately gn The configuration file of is readable , Understand some basic knowledge points .

GN The components of depend on

GN Build system , The root node of its dependency tree is executable Object of type , Then on the dependent component of this object , Extend to end assembly . For example, the dependency tree of this project is expanded as follows （ By order gn desc out/${BOARD} --args="product = \"${BOARD}\"" //hardware/board/${BOARD} deps --tree To obtain a , Of the order ${BOARD} The environment variable is TencentOS_tiny_EVB_AIoT）

//TinyOS:TinyOS
  //TinyOS/arch/arm/arm-v7m/common:common
  //TinyOS/arch/arm/arm-v7m/cortex-m7:cortex-m7
  //TinyOS/kernel:kernel
//components:components
  //components/drivers:drivers
  //components/lists:lists
  //components/uart:uart
  //components/utilities:utilities
//hardware/board/TencentOS_tiny_EVB_AIoT:startup
//hardware/board/TencentOS_tiny_EVB_AIoT/device:device
//hardware/board/TencentOS_tiny_EVB_AIoT/xip:xip
//solutions/helloworld:helloworld

For example, the first line of //TinyOS:TinyOS, This is a executable The first dependent component referenced by the , Its path is under the root directory TinyOS Catalog , In this directory BUILD.gn In profile , It uses TinyOS Objects with the same name . The following example will illustrate GN Common configuration of components of .

GN Syntax description of component configuration file

for instance , We take TinyOS Component configuration file as an example （ The file path is TinyOS/BUILD.gn）

source_set("TinyOS") {
  deps = [
    "arch/arm/arm-v7m/common",
    "arch/arm/arm-v7m/cortex-m7",
    "kernel",
  ]
}

In this document , We defined a name as TinyOS Source code collection object for , Why should we name the object name consistent with the folder name ？ This is a GN One of the rules ： If the superior specifies dependency , Only the path is given , The default component object name is the folder name at the end of the path （ Implicit call ）. For example, as shown above ,TinyOS There are three components under the component , Namely arch The path of common Components and cortex-m7 Components , as well as kernel Components . Under these three component folders , Also have BUILD.gn The configuration file , It defines the component name and the content of the component （ If there are dependencies, add deps rely on , Add source code if there is no dependency ）.deps It means to define the component name that this component depends on

End component configuration syntax description

kernel The source code contained under the component is defined as follows （ The file path is TinyOS/kernel/BUILD.gn）. In this document , The component name is consistent with the folder , There is no need to specify the component name when calling the parent dependency . If the component name is inconsistent with the folder name , You need to specify the component name . In this case ,source_set("kernel"), If you want to define another component name （ The same directory has different components , And the directory name does not match the component name ）, You can change to source_set("kernel_name"), When the parent component calls , The component name should be added after the directory , such as "kernel:kernel_name", The previous is the relative directory of dependent components , Followed by the component name （ Explicit call ）.

source_set("kernel") {
  sources = [
    "core/tos_barrier.c",
    "core/tos_binary_heap.c",
    "core/tos_bitmap.c",
    "core/tos_char_fifo.c",
    "core/tos_completion.c",
    "core/tos_countdownlatch.c",
    "core/tos_event.c",
    "core/tos_global.c",
    "core/tos_mail_queue.c",
    "core/tos_message_queue.c",
    "core/tos_mmblk.c",
    "core/tos_mmheap.c",
    "core/tos_mutex.c",
    "core/tos_pend.c",
    "core/tos_priority_mail_queue.c",
    "core/tos_priority_message_queue.c",
    "core/tos_priority_queue.c",
    "core/tos_ring_queue.c",
    "core/tos_robin.c",
    "core/tos_rwlock.c",
    "core/tos_sched.c",
    "core/tos_sem.c",
    "core/tos_stopwatch.c",
    "core/tos_sys.c",
    "core/tos_task.c",
    "core/tos_tick.c",
    "core/tos_time.c",
    "core/tos_timer.c",
    "pm/tos_pm.c",
    "pm/tos_tickless.c",
  ]
}

As shown above ,GN The components of depend on , Relative to tradition makefile and cmake The file is , Easier to understand , It is also easier to read and maintain . In terms of component decoupling , It can really make all components complete the construction of the whole project through healthy dependency （ There is no circular dependency or malignant dependency ）, The function decoupling is good .

Build script analysis

build/                          # Build script Directory 
├── config                      # Configuration directory for the product 
│   ├── compiler                                   
│   │   └── BUILD.gn            # Common configuration contents of compiler , For example, compile optimization settings 
│   ├── product.gni             # Set some compile judgment parameters related to the product here 
│   └── rt1062 
│       └── BUILD.gn            #rt1062 Related macro definitions and special compilation parameters 
└── toolchain
    ├── BUILD.gn                # Tool chain configuration 
    ├── clang.gni               # Reserved for clang Configuration file for 
    └── gcc.gni                 #arm-none-eabi-gcc To configure , The compile command constitutes the configuration 
.gn                             #GN Read the root configuration of , Generally, only other documents are referenced 
BUILD.gn                        # The configuration here is convenient for adding development boards in the future 
BUILDCONFIG.gn                  # Here, the configuration of various tools and development boards are linked 

Basically, it only needs to be modified build Directory can complete the change of compilation parameters , The corresponding functions are also split in detail , It would be better if you could make detailed comments . Because I am not a professional engineer , There are a lot of inaccurate comments , Even mistakes can be made .

The above is the content of this sharing ,gn The functions of the are also relatively complicated , But after using habits , It's very comfortable .