Previously with the right number of parameters that take values and the
right order it could happen that a parameter value got replaced by an
action when the script output the parameters. This change fixes this.
Fixes: #11676
These changes come out of discussion in the team; we want to make use of
git trailers and improve the quality of our commit messages. Starting by
adding more hints to the commit suggestions. Includes some minor cleanup
of the hooks, and hopefully also improves tests so that they don't
interfere with interactions with non-Keyman repos.
Note: the scopes list may need maintenance as the list still includes
sub-scopes and 'oem'.
`langtags.json` is directly downloaded from master branch at the GitHub repo
68cf82943c
because the version served at ldml.api.sil.org still has a duplicate.
The build agents use a fixed location for signtool.exe, but this is not
the case for other devs, so we need to grab our VS environment in order
to locate it.
Use a new flag `--npm-publish` in conjunction with `publish` action,
so that the default will always be to `npm pack` if the new flag is not
specified. This flag is also guarded in the actual npm publish code to
ensure that it can only run in the appropriate CI alpha/beta/stable
environment, and not in local or test.
This then also removes the separate `pack` action.
Also removes legacy boilerplate from a number of build scripts.
Now builds from a clean repo:
developer/src/build.sh configure build test publish
* Splits kmbrowserhost into kmdbrowserhost for Developer; this means
that Developer Browser Host now inherits the Developer settings rather
than the Keyman for Windows settings, and simplifies distribution and
management. The only difference between the two is in the startup code
so this seems like a good split.
* Cleanup of various build scripts and dependencies.
Relates to #11317.
Initial baby steps for configuring build environment for Delphi and VC++
within build.sh without needing to call out to batch files.
Proof-of-concept build.sh for setup.dpr.
The call to the command listed for `builder_run_action` was not properly
quoted, which meant that quoted parameters would have been corrupted,
for example:
builder_run_action clean rm -rf "temp folder/"
Would have run:
rm -rf temp folder/
When using module:target style dependencies, Builder would not track the
individual targets within the module, causing only the first target to
be built; subsequent dependency targets within that module would be
treated as already built.
This change means that builder will track individual targets within
the dependency. However, it is possible for targets to be built multiple
times if there a dependency listed for the entire module as well as for
the individual target within dependency, as in the following example,
where building project1 and project2 in one command would cause
module:mytarget to be built twice.
builder_describe project1 \
@/module
builder_describe project2 \
@/module:mytarget
This scenario should not break builds as they any configure+build
actions should be idempotent, but it could cause builds to be a little
slower, so should be corrected if identified. I do not currently plan to
further modify the dependency calculations to cater for this scenario.
Finally, if :mytarget is a child build, it is better to reference the
child module directly than the parent's target, for example:
builder_describe projec1 \
@/module/mytarget
