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
