From 7f3dfe1506b2a211af21978f446196331b558e3a Mon Sep 17 00:00:00 2001 From: Noah Swerhun Date: Wed, 6 Mar 2024 14:18:36 -0600 Subject: [PATCH] more typos (i should proofread before i commit) --- README.md | 19 ++++++++++--------- 1 file changed, 10 insertions(+), 9 deletions(-) diff --git a/README.md b/README.md index 8d642b4..dcc0bd3 100644 --- a/README.md +++ b/README.md @@ -39,7 +39,7 @@ Uninstall: `sudo sh uninstall.sh` ## Usage What follows is a tutorial of how to set up ngen for an existing executable -project. If you are looking for a reference, look . +project. ### Basics @@ -170,8 +170,8 @@ these values will be automatically picked up by Ninja and accounted for in the build. Running `ninja -v` immediately after saving `ngen.toml` should show that the options you set were recognized, and your files were rebuilt accordingly. -Now, this is a good start. But, it often the case that in a project, you want to -have multiple different build *targets,* or configurations, that build the +Now, this is a good start. But, it often the case that, in a project, you want +to have multiple different build *targets,* or configurations, that build the project with slightly different parameters; for example, it is common to have a "debug" build target that is unoptimized and includes debugging symbols, and a "release" build that is optimized at compile time. ngen is designed to make this @@ -184,7 +184,7 @@ scope," so to speak, of the TOML file. Without knowing it, we were actually configuring the `main` target (this is why the outfiles were placed in `build/*main/*`. The main target is special because it does not need to be labeled: all build parameters placed in the global scope (or, more accurately, -the TOML"root table"), will be used for the `main` target. To specify +the TOML "root table"), will be used for the `main` target. To specify additional targets, we create a TOML table with the name of our target. Let's create a target called `debug`. Add the following to your `ngen.toml`: @@ -202,7 +202,7 @@ according to two simple rules: **a**rrays **a**ppend, **s**trings **s**upercede. The first thing that happens is `debug` takes on all the same parameters from main. Then, ngen reads the outfile key in `debug`. Becuase outfile is a string, `debug.outfile` is overwritten as the value specified, in this case -"example\_dbg". On the othe hand, since compiler\_flags is a list, the elements +"example\_dbg". On the other hand, since compiler\_flags is a list, the elements sepecified in `debug.compiler_flags` are appended to the list of flags specified in `main`. So in this case, the effective value of `debug.compiler_flags` is `["-Wall", "-Wextra -O2", "-g"]`. @@ -237,8 +237,8 @@ your `ngen.toml`: the special `main` target should only contain the largest subset of all your build parameters. Additonal targets should add specific parameters for specific use cases, as we saw in the above example. -In a nutshell, inheritance allows you to easily create multiple targets with small variations, -without having to rewrite the same thing over and over again. +In a nutshell, inheritance allows you to easily create multiple targets with +small variations, without having to rewrite the same thing over and over again. Save `ngen.toml`, and try running `ninja -v debug` or `ninja -v release`. You should see that each of these targets uses the parameters that we specified with @@ -253,7 +253,7 @@ Note that by default, running `ninja` alone with no target specifed will run `default = true` key to the targets you want to be built when Ninja is invoked with no arguments. Say that this example project is under active developemnt, and you will be building the `debug` target alot. You can add the `default = -true` flag to the `[debug]` table, and now running `ninja` by it self will only +true` flag to the `[debug]` table, and now running `ninja` by itself will only build the `debug` target. You can still build the release and main targets by running `ninja release` and `ninja main`. @@ -280,7 +280,7 @@ make sure that this file is kept up to date as well. Just set the option in your ngen.toml and forget about it. By default, the compile\_commands.json will be generated according to the build -specs of the `main` target. To change which target it is generated for use the +specs of the `main` target. To change which target it is generated, for use the `config.compile_commands_target` key. For example, ```toml @@ -308,6 +308,7 @@ sources = [ [debug] outfile = "example_dbg" compiler_flags = ["-g"] +default = true [release] compiler_flags = ["-O2"]