noah/ngen
1
0
Fork 0
Code Issues Pull requests Packages Projects Releases Wiki Activity

more typos (i should proofread before i commit)

Browse source
This commit is contained in:
Noah Swerhun 2024-03-06 14:18:36 -06:00
parent 846fe14573
commit 7f3dfe1506
1 changed files with 10 additions and 9 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

19
README.md
View file

@ -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 <SOMEWHERE>.
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"]