libdragon 10.2.0 → 10.4.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CHANGELOG.md +100 -13
- package/README.md +3 -51
- package/index.js +78 -33
- package/modules/actions/exec.js +91 -0
- package/modules/actions/help.js +157 -0
- package/modules/actions/index.js +43 -0
- package/modules/actions/init.js +190 -0
- package/modules/actions/install.js +52 -0
- package/modules/actions/start.js +114 -0
- package/modules/actions/update.js +48 -0
- package/modules/actions/utils.js +314 -0
- package/modules/constants.js +9 -4
- package/modules/globals.js +5 -0
- package/modules/helpers.js +82 -276
- package/modules/project-info.js +232 -0
- package/package.json +5 -4
- package/skeleton/src/main.c +0 -2
- package/modules/actions.js +0 -567
package/CHANGELOG.md
CHANGED
|
@@ -1,5 +1,93 @@
|
|
|
1
1
|
# Change Log
|
|
2
2
|
|
|
3
|
+
## [10.4.0] - 2022-03-23
|
|
4
|
+
|
|
5
|
+
### Fixed
|
|
6
|
+
|
|
7
|
+
- Update the root makefile to utilize `SOURCE_DIR` for example builds. Then we are
|
|
8
|
+
able to map container files to local files properly with a generic regex in the
|
|
9
|
+
problem matcher. This fixes #13 and does not change any behaviour.
|
|
10
|
+
- Add missing examples to the vscode run configurations.
|
|
11
|
+
- Install and build libdragon related things in the container when `exec` and
|
|
12
|
+
`make` causes a new container run. This was previously prevented on `v10.3.1`
|
|
13
|
+
because it was unnecessarily delaying all exec operations when the container
|
|
14
|
+
is started. Refactoring things allowed me to realize this can be improved
|
|
15
|
+
instead of forcing the user to do a manual `install`.
|
|
16
|
+
- Fix a potential issue that may cause the git commands to run in current folder
|
|
17
|
+
instead of the project root.
|
|
18
|
+
- Attach the error handler once for spawnProcess.
|
|
19
|
+
- Update vulnerable dependencies.
|
|
20
|
+
|
|
21
|
+
### Added
|
|
22
|
+
|
|
23
|
+
- `--directory` option to customize vendoring location.
|
|
24
|
+
- `--strategy` option to select a vendoring strategy. Currently supported options
|
|
25
|
+
are `submodule`, `subtree` and `manual`. The default is `submodule` and `manual`
|
|
26
|
+
can be used to opt-out of auto vendoring. Useful if the user wants to utilize
|
|
27
|
+
a different vendoring strategy and opt-out of the auto-managed git flows.
|
|
28
|
+
|
|
29
|
+
### Changed
|
|
30
|
+
|
|
31
|
+
- Migrate to a json file for persistent project information.
|
|
32
|
+
- Only save the configuration file on successful exit except for the initial
|
|
33
|
+
migration.
|
|
34
|
+
- Do not prevent init if there is a file named libdragon in the target folder.
|
|
35
|
+
This used to cause problems on windows but I cannot reproduce it anymore
|
|
36
|
+
with `2.33.1.windows.1`. It may be something caused by my old configuration.
|
|
37
|
+
- Minor performance improvements.
|
|
38
|
+
|
|
39
|
+
## [10.3.1] - 2022-01-25
|
|
40
|
+
|
|
41
|
+
### Fixed
|
|
42
|
+
|
|
43
|
+
- Do not try to parse arguments after exec/make. They used to get evaluated as
|
|
44
|
+
libdragon paramaters previously, preventing passing down -v to the container
|
|
45
|
+
make for example.
|
|
46
|
+
- Docker image update issues
|
|
47
|
+
- Attempt an image update whenever the image flag is provided. Previously this
|
|
48
|
+
was only done if a different image name is provided, preventing the update of
|
|
49
|
+
the latest image. Previously not providing an image name was behaving the same
|
|
50
|
+
so this is not a breaking change.
|
|
51
|
+
- Start action used to update the image if provided but this bug was already
|
|
52
|
+
prevented by previous fixes by not accepting the image flag for actions other
|
|
53
|
+
than init/update/install. Start action no longer tries to update the image
|
|
54
|
+
regardless.
|
|
55
|
+
|
|
56
|
+
### Changed
|
|
57
|
+
|
|
58
|
+
- Only accept the image flag for init, install, and update actions as documented.
|
|
59
|
+
- Improve documentation for the `init` and `install` actions.
|
|
60
|
+
- Do not attempt an `install` when running `exec`, just start the container. If
|
|
61
|
+
there is a half-baked container, a manual `install` will potentially restore it.
|
|
62
|
+
- Update libdragon.
|
|
63
|
+
|
|
64
|
+
### Added
|
|
65
|
+
|
|
66
|
+
- Extra information for skipping the image flag when doing init for an already
|
|
67
|
+
initialized project.
|
|
68
|
+
|
|
69
|
+
## [10.3.0] - 2022-01-20
|
|
70
|
+
|
|
71
|
+
### Changed
|
|
72
|
+
|
|
73
|
+
- Update dependencies.
|
|
74
|
+
- Detailed help output.
|
|
75
|
+
- Move action descriptions to `libdragon help`.
|
|
76
|
+
- Update libdragon to latest version for local build.
|
|
77
|
+
|
|
78
|
+
### Added
|
|
79
|
+
|
|
80
|
+
- Shorthand flag support.
|
|
81
|
+
|
|
82
|
+
## [10.2.1] - 2021-10-14
|
|
83
|
+
|
|
84
|
+
### Changed
|
|
85
|
+
|
|
86
|
+
- Updated ed64.
|
|
87
|
+
|
|
88
|
+
### Fixed
|
|
89
|
+
|
|
90
|
+
- Fix skeleton project to match latest libdragon.
|
|
3
91
|
|
|
4
92
|
## [10.2.0] - 2021-10-10
|
|
5
93
|
|
|
@@ -7,42 +95,42 @@
|
|
|
7
95
|
|
|
8
96
|
- Container discovery. The tool can now find a container even if `.git` is lost.
|
|
9
97
|
- A few additional error messages for some potentially confusing cases such as
|
|
10
|
-
already having a file with `libdragon` like name.
|
|
98
|
+
already having a file with `libdragon` like name.
|
|
11
99
|
|
|
12
100
|
### Changed
|
|
13
101
|
|
|
14
102
|
- Show more output for downloading the container and initial git operations.
|
|
15
103
|
- Remove an extra log during initialization.
|
|
16
104
|
- The submodule was always being initialized when a container is started. This
|
|
17
|
-
was making some actions inconsistent. For example `install` or `make` action
|
|
18
|
-
was trying to re-initialize the submodule unnecessarily. This is fixed by only
|
|
19
|
-
initializing it with the `init` action. If any of those need to re-init the
|
|
20
|
-
container, now they assume there is an intact libdragon folder to use.
|
|
105
|
+
was making some actions inconsistent. For example `install` or `make` action
|
|
106
|
+
was trying to re-initialize the submodule unnecessarily. This is fixed by only
|
|
107
|
+
initializing it with the `init` action. If any of those need to re-init the
|
|
108
|
+
container, now they assume there is an intact libdragon folder to use.
|
|
21
109
|
- Similarly a git repository is not initialized unnecessarily anymore.
|
|
22
110
|
- `update` and `install` are now able to start containers if necessary.
|
|
23
111
|
- Always try to copy skeleton files, they won't overwrite anything already.
|
|
24
112
|
- Do not re-initialize if there is a `.libdragon` folder. We now only try to
|
|
25
|
-
start it in this case. If it is not a complete container, it can probably be
|
|
26
|
-
recovered by a `libdragon install` or `libdragon update`.
|
|
113
|
+
start it in this case. If it is not a complete container, it can probably be
|
|
114
|
+
recovered by a `libdragon install` or `libdragon update`.
|
|
27
115
|
|
|
28
116
|
### Fixed
|
|
29
117
|
|
|
30
118
|
- Fix wording for libdragon install on the container.
|
|
31
119
|
- Improve image name persitence such that the tool finds and updates it more
|
|
32
|
-
consistently.
|
|
120
|
+
consistently.
|
|
33
121
|
|
|
34
122
|
## [10.1.0] - 2021-10-07
|
|
35
123
|
|
|
36
124
|
### Added
|
|
37
125
|
|
|
38
126
|
- `exec` action to execute arbitrary commands in the container with TTY support.
|
|
39
|
-
This also improves the color output support as docker now knows it is using TTY.
|
|
127
|
+
This also improves the color output support as docker now knows it is using TTY.
|
|
40
128
|
- Add more verbose logging for skeleton project copy.
|
|
41
129
|
|
|
42
130
|
### Changed
|
|
43
131
|
|
|
44
132
|
- Removed partially not working `--byte-swap` option. It does not already work
|
|
45
|
-
with the new libdragon build system so there is no need keeping it in the tool.
|
|
133
|
+
with the new libdragon build system so there is no need keeping it in the tool.
|
|
46
134
|
|
|
47
135
|
### Fixed
|
|
48
136
|
|
|
@@ -53,14 +141,14 @@ with the new libdragon build system so there is no need keeping it in the tool.
|
|
|
53
141
|
### Changed
|
|
54
142
|
|
|
55
143
|
- A complete re-write of the tool. Check documentation for the new usage. It is
|
|
56
|
-
much more straightforward to use now. `libdragon make` behaves almost the same.
|
|
144
|
+
much more straightforward to use now. `libdragon make` behaves almost the same.
|
|
57
145
|
|
|
58
146
|
## [9.0.0] - 2021-09-06
|
|
59
147
|
|
|
60
148
|
### Changed
|
|
61
149
|
|
|
62
150
|
- Updated libdragon. We will be changing the update mechanism to be based on a
|
|
63
|
-
git pull, so listing them here will not be useful anymore, let's not bother now.
|
|
151
|
+
git pull, so listing them here will not be useful anymore, let's not bother now.
|
|
64
152
|
- Start using the new build system.
|
|
65
153
|
- Update node engine spec to be at least 14.
|
|
66
154
|
- Added minimum docker version to readme.
|
|
@@ -110,7 +198,6 @@ git pull, so listing them here will not be useful anymore, let's not bother now.
|
|
|
110
198
|
- Support for RTC status/read/write commands (https://github.com/DragonMinded/libdragon/pull/152)
|
|
111
199
|
- Generic libdragon NPM script
|
|
112
200
|
|
|
113
|
-
|
|
114
201
|
## [7.0.0] - 2021-06-06
|
|
115
202
|
|
|
116
203
|
### Changed
|
package/README.md
CHANGED
|
@@ -22,7 +22,7 @@ To update the library and rebuild/install all the artifacts;
|
|
|
22
22
|
|
|
23
23
|
libdragon update
|
|
24
24
|
|
|
25
|
-
|
|
25
|
+
`git` is not strictly required to use this tool as docker's git will be used instead. Still, it is highly recommended to have git on your host machine.
|
|
26
26
|
|
|
27
27
|
## Overall usage
|
|
28
28
|
|
|
@@ -36,55 +36,7 @@ You can invoke libdragon as follows;
|
|
|
36
36
|
|
|
37
37
|
libdragon [flags] <action>
|
|
38
38
|
|
|
39
|
-
|
|
40
|
-
|
|
41
|
-
__`init`__
|
|
42
|
-
|
|
43
|
-
Creates a libdragon project in the current directory. Every libdragon project will have its own docker container instance. If you are in a git repository or an NPM project, libdragon will be initialized at their root also marking there with a `.libdragon` folder.
|
|
44
|
-
|
|
45
|
-
A git repository and a submodule at `./libdragon` will also be created. Do not remove the `.libdragon` folder and commit its contents if you are using git, as it keeps persistent libdragon project information.
|
|
46
|
-
|
|
47
|
-
If this is the first time you are creating a libdragon project at that location, this action will also create skeleton project files to kickstart things.
|
|
48
|
-
|
|
49
|
-
__`make`__
|
|
50
|
-
|
|
51
|
-
Runs the libdragon build system in the current directory. It will mirror your current working directory to the container.
|
|
52
|
-
|
|
53
|
-
This action is a shortcut to the `exec` action under the hood.
|
|
54
|
-
|
|
55
|
-
__`exec`__
|
|
56
|
-
|
|
57
|
-
Executes the given command in the container passing down any arguments provided. If you change your host working directory, the command will be executed in the corresponding folder in the container as well.
|
|
58
|
-
|
|
59
|
-
This action will first try to execute the command in the container and if the container is not accessible, it will attempt a complete `start` cycle.
|
|
60
|
-
|
|
61
|
-
This will properly passthrough your TTY if you have one. So by running `libdragon exec bash` you can start an interactive bash session with full TTY support.
|
|
62
|
-
|
|
63
|
-
__`install`__
|
|
64
|
-
|
|
65
|
-
Attempts to build and install everything libdragon related into the container. This includes all the tools and third parties used by libdragon except for the toolchain. If you have made changes to libdragon, you can execute this action to build everything based on your changes. Requires you to have an intact `libdragon` at the root of the project. If you are not working on libdragon, you can just use the `update` action instead.
|
|
66
|
-
|
|
67
|
-
__`update`__
|
|
68
|
-
|
|
69
|
-
This action will update the submodule from the remote branch (`trunk`) with a merge strategy and then perform a `libdragon install`. You can use the `install` action to only update all libdragon related artifacts in the container.
|
|
70
|
-
|
|
71
|
-
__`start`__
|
|
72
|
-
|
|
73
|
-
Start the container assigned to the current libdragon project. Will first attempt to start an existing container if found, followed by a new container run and installation similar to the `install` action. Will always print out the container id on success.
|
|
74
|
-
|
|
75
|
-
__`stop`__
|
|
76
|
-
|
|
77
|
-
Stop the container assigned to the current libdragon project.
|
|
78
|
-
|
|
79
|
-
### Available flags
|
|
80
|
-
|
|
81
|
-
__`--image <docker-image>`__
|
|
82
|
-
|
|
83
|
-
Use this flag to provide a custom image to use instead of the default. It should include the toolchain at `/n64_toolchain`. It will be effective for `init`, `install` and `update` actions and will cause a re-initialization of the container if an image different from what was written to project configuration is provided.
|
|
84
|
-
|
|
85
|
-
__`--verbose`__
|
|
86
|
-
|
|
87
|
-
Be verbose. This will print all commands dispatched and their outputs as well.
|
|
39
|
+
Run `libdragon help [action]` for more details on individual actions.
|
|
88
40
|
|
|
89
41
|
## Working on this repository
|
|
90
42
|
|
|
@@ -130,7 +82,7 @@ To update the submodule and re-build everything;
|
|
|
130
82
|
|
|
131
83
|
### Local test bench
|
|
132
84
|
|
|
133
|
-
This repository also uses [ed64](https://github.com/anacierdem/ed64), so you can just hit F5 on vscode (The `Run Test Bench` launch configuration) to run the test code in `src` folder to develop libdragon itself quicker if you have an everdrive.
|
|
85
|
+
This repository also uses [ed64](https://github.com/anacierdem/ed64), so you can just hit F5 on vscode (The `Run Test Bench` launch configuration) to run the test code in `src` folder to develop libdragon itself quicker if you have an everdrive.
|
|
134
86
|
|
|
135
87
|
There are also additional vscode launch configurations to build libdragon examples and tests based on the currently built and installed libdragon in the docker container. Most of these will always rebuild so that they will use the latest if you made and installed an alternative libdragon. The test bench itself and a few examples (that use the new build system) will already rebuild and reinstall libdragon automatically. These will always produce a rom image using the latest libdragon code in the active repository via its make dependencies. You can clean everything with the `clean` task (open the command palette and choose `Run Task -> clean`).
|
|
136
88
|
|
package/index.js
CHANGED
|
@@ -1,91 +1,132 @@
|
|
|
1
1
|
#!/usr/bin/env node
|
|
2
2
|
|
|
3
3
|
const chalk = require('chalk');
|
|
4
|
-
const { readProjectInfo, CommandError, globals } = require('./modules/helpers');
|
|
5
|
-
const actions = require('./modules/actions');
|
|
6
|
-
|
|
7
|
-
const STATUS_OK = 0;
|
|
8
|
-
const STATUS_ERROR = 1;
|
|
9
|
-
const STATUS_BAD_PARAM = 2;
|
|
10
|
-
|
|
11
|
-
// Command line options
|
|
12
|
-
const options = {
|
|
13
|
-
DOCKER_IMAGE: undefined,
|
|
14
|
-
VERBOSE: false,
|
|
15
4
|
|
|
16
|
-
|
|
17
|
-
|
|
18
|
-
|
|
19
|
-
|
|
20
|
-
|
|
21
|
-
|
|
5
|
+
const actions = require('./modules/actions');
|
|
6
|
+
const { fn: printUsage } = require('./modules/actions/help');
|
|
7
|
+
const {
|
|
8
|
+
STATUS_OK,
|
|
9
|
+
STATUS_BAD_PARAM,
|
|
10
|
+
STATUS_ERROR,
|
|
11
|
+
} = require('./modules/constants');
|
|
12
|
+
const { globals } = require('./modules/globals');
|
|
13
|
+
const { CommandError, ParameterError } = require('./modules/helpers');
|
|
14
|
+
const { readProjectInfo, writeProjectInfo } = require('./modules/project-info');
|
|
15
|
+
|
|
16
|
+
let options = {},
|
|
17
|
+
currentAction;
|
|
22
18
|
|
|
23
19
|
for (let i = 2; i < process.argv.length; i++) {
|
|
24
20
|
const val = process.argv[i];
|
|
25
21
|
|
|
26
|
-
|
|
22
|
+
// Allow console here
|
|
23
|
+
/* eslint-disable no-console */
|
|
24
|
+
|
|
25
|
+
if (['--verbose', '-v'].includes(val)) {
|
|
27
26
|
options.VERBOSE = true;
|
|
28
27
|
globals.verbose = true;
|
|
29
28
|
continue;
|
|
30
29
|
}
|
|
31
30
|
|
|
32
|
-
if (
|
|
31
|
+
if (['--image', '-i'].includes(val)) {
|
|
33
32
|
options.DOCKER_IMAGE = process.argv[++i];
|
|
34
33
|
continue;
|
|
34
|
+
} else if (val.indexOf('--image=') === 0) {
|
|
35
|
+
options.DOCKER_IMAGE = val.split('=')[1];
|
|
36
|
+
continue;
|
|
37
|
+
}
|
|
38
|
+
|
|
39
|
+
if (['--directory', '-d'].includes(val)) {
|
|
40
|
+
options.VENDOR_DIR = process.argv[++i];
|
|
41
|
+
continue;
|
|
42
|
+
} else if (val.indexOf('--directory=') === 0) {
|
|
43
|
+
options.VENDOR_DIR = val.split('=')[1];
|
|
44
|
+
continue;
|
|
45
|
+
}
|
|
46
|
+
|
|
47
|
+
if (['--strategy', '-s'].includes(val)) {
|
|
48
|
+
options.VENDOR_STRAT = process.argv[++i];
|
|
49
|
+
continue;
|
|
50
|
+
} else if (val.indexOf('--strategy=') === 0) {
|
|
51
|
+
options.VENDOR_STRAT = val.split('=')[1];
|
|
52
|
+
continue;
|
|
35
53
|
}
|
|
36
54
|
|
|
37
55
|
if (val.indexOf('--') >= 0) {
|
|
38
56
|
console.error(chalk.red(`Invalid flag \`${val}\``));
|
|
39
|
-
|
|
57
|
+
printUsage();
|
|
40
58
|
process.exit(STATUS_BAD_PARAM);
|
|
41
59
|
}
|
|
42
60
|
|
|
43
|
-
if (
|
|
61
|
+
if (currentAction) {
|
|
44
62
|
console.error(
|
|
45
63
|
chalk.red(`Expected only a single action, found: \`${val}\``)
|
|
46
64
|
);
|
|
47
|
-
|
|
65
|
+
printUsage();
|
|
48
66
|
process.exit(STATUS_BAD_PARAM);
|
|
49
67
|
}
|
|
50
68
|
|
|
51
|
-
|
|
69
|
+
currentAction = actions[val];
|
|
52
70
|
|
|
53
|
-
if (!
|
|
71
|
+
if (!currentAction) {
|
|
54
72
|
console.error(chalk.red(`Invalid action \`${val}\``));
|
|
55
|
-
|
|
73
|
+
printUsage();
|
|
56
74
|
process.exit(STATUS_BAD_PARAM);
|
|
57
75
|
}
|
|
58
76
|
|
|
59
|
-
if (
|
|
77
|
+
if (currentAction.forwardsRestParams) {
|
|
60
78
|
options.PARAMS = process.argv.slice(i + 1);
|
|
61
79
|
break;
|
|
62
80
|
}
|
|
63
81
|
}
|
|
64
82
|
|
|
65
|
-
if (!
|
|
83
|
+
if (!currentAction) {
|
|
66
84
|
console.error(chalk.red('No action provided'));
|
|
67
|
-
|
|
85
|
+
printUsage();
|
|
68
86
|
process.exit(STATUS_BAD_PARAM);
|
|
69
87
|
}
|
|
70
88
|
|
|
71
|
-
if (
|
|
89
|
+
if (currentAction === actions.exec && options.PARAMS.length === 0) {
|
|
72
90
|
console.error(chalk.red('You should provide a command to exec'));
|
|
73
|
-
|
|
91
|
+
printUsage(undefined, [currentAction.name]);
|
|
92
|
+
process.exit(STATUS_BAD_PARAM);
|
|
93
|
+
}
|
|
94
|
+
|
|
95
|
+
if (
|
|
96
|
+
![actions.init, actions.install, actions.update].includes(currentAction) &&
|
|
97
|
+
options.DOCKER_IMAGE
|
|
98
|
+
) {
|
|
99
|
+
console.error(chalk.red('Invalid flag: image'));
|
|
100
|
+
printUsage(undefined, [currentAction.name]);
|
|
101
|
+
process.exit(STATUS_BAD_PARAM);
|
|
102
|
+
}
|
|
103
|
+
|
|
104
|
+
if (
|
|
105
|
+
options.VENDOR_STRAT &&
|
|
106
|
+
!['submodule', 'subtree', 'manual'].includes(options.VENDOR_STRAT)
|
|
107
|
+
) {
|
|
108
|
+
console.error(chalk.red(`Invalid strategy \`${options.VENDOR_STRAT}\``));
|
|
109
|
+
printUsage();
|
|
74
110
|
process.exit(STATUS_BAD_PARAM);
|
|
75
111
|
}
|
|
76
112
|
|
|
77
113
|
readProjectInfo()
|
|
78
114
|
.then((info) =>
|
|
79
|
-
|
|
115
|
+
currentAction.fn(
|
|
80
116
|
{
|
|
81
117
|
...info,
|
|
82
118
|
options,
|
|
83
|
-
...
|
|
119
|
+
...currentAction,
|
|
84
120
|
},
|
|
85
|
-
options.PARAMS
|
|
121
|
+
options.PARAMS ?? []
|
|
86
122
|
)
|
|
87
123
|
)
|
|
88
124
|
.catch((e) => {
|
|
125
|
+
if (e instanceof ParameterError) {
|
|
126
|
+
console.error(chalk.red(e.message));
|
|
127
|
+
printUsage(undefined, [currentAction.name]);
|
|
128
|
+
process.exit(STATUS_BAD_PARAM);
|
|
129
|
+
}
|
|
89
130
|
const userTargetedError = e instanceof CommandError && e.userCommand;
|
|
90
131
|
|
|
91
132
|
// Show additional information to user if verbose or we did a mistake
|
|
@@ -108,6 +149,10 @@ readProjectInfo()
|
|
|
108
149
|
// We don't have a user targeted error anymore, we did a mistake for sure
|
|
109
150
|
process.exit(STATUS_ERROR);
|
|
110
151
|
})
|
|
152
|
+
.then(() => {
|
|
153
|
+
// Everything was done, update the configuration file if not exiting early
|
|
154
|
+
return writeProjectInfo();
|
|
155
|
+
})
|
|
111
156
|
.finally(() => {
|
|
112
157
|
process.exit(STATUS_OK);
|
|
113
158
|
});
|
|
@@ -0,0 +1,91 @@
|
|
|
1
|
+
const path = require('path');
|
|
2
|
+
|
|
3
|
+
const { CONTAINER_TARGET_PATH } = require('../constants');
|
|
4
|
+
const { log, dockerExec, toPosixPath } = require('../helpers');
|
|
5
|
+
|
|
6
|
+
const { fn: start } = require('./start');
|
|
7
|
+
const { dockerHostUserParams, installDependencies } = require('./utils');
|
|
8
|
+
|
|
9
|
+
function dockerRelativeWorkdir(libdragonInfo) {
|
|
10
|
+
return (
|
|
11
|
+
CONTAINER_TARGET_PATH +
|
|
12
|
+
'/' +
|
|
13
|
+
toPosixPath(path.relative(libdragonInfo.root, process.cwd()))
|
|
14
|
+
);
|
|
15
|
+
}
|
|
16
|
+
|
|
17
|
+
function dockerRelativeWorkdirParams(libdragonInfo) {
|
|
18
|
+
return ['--workdir', dockerRelativeWorkdir(libdragonInfo)];
|
|
19
|
+
}
|
|
20
|
+
|
|
21
|
+
const exec = async (libdragonInfo, commandAndParams) => {
|
|
22
|
+
log(
|
|
23
|
+
`Running ${commandAndParams[0]} at ${dockerRelativeWorkdir(
|
|
24
|
+
libdragonInfo
|
|
25
|
+
)} with [${commandAndParams.slice(1)}]`,
|
|
26
|
+
true
|
|
27
|
+
);
|
|
28
|
+
|
|
29
|
+
const tryCmd = (libdragonInfo) =>
|
|
30
|
+
libdragonInfo.containerId &&
|
|
31
|
+
dockerExec(
|
|
32
|
+
libdragonInfo,
|
|
33
|
+
[
|
|
34
|
+
...dockerRelativeWorkdirParams(libdragonInfo),
|
|
35
|
+
...dockerHostUserParams(libdragonInfo),
|
|
36
|
+
],
|
|
37
|
+
commandAndParams,
|
|
38
|
+
true,
|
|
39
|
+
true // Cannot use "full" here, we need to know if the container is alive
|
|
40
|
+
);
|
|
41
|
+
|
|
42
|
+
let started = false;
|
|
43
|
+
const startOnceAndCmd = async () => {
|
|
44
|
+
if (!started) {
|
|
45
|
+
const newId = await start(libdragonInfo);
|
|
46
|
+
started = true;
|
|
47
|
+
|
|
48
|
+
// Re-install vendors on new container if one was created upon start
|
|
49
|
+
// Ideally we would want the consumer to handle dependencies and rebuild
|
|
50
|
+
// libdragon if necessary. Currently this saves the day with a little bit
|
|
51
|
+
// extra waiting when the container is deleted.
|
|
52
|
+
if (libdragonInfo.containerId !== newId) {
|
|
53
|
+
await installDependencies({
|
|
54
|
+
...libdragonInfo,
|
|
55
|
+
containerId: newId,
|
|
56
|
+
});
|
|
57
|
+
}
|
|
58
|
+
await tryCmd({
|
|
59
|
+
...libdragonInfo,
|
|
60
|
+
containerId: newId,
|
|
61
|
+
});
|
|
62
|
+
return newId;
|
|
63
|
+
}
|
|
64
|
+
};
|
|
65
|
+
|
|
66
|
+
if (!libdragonInfo.containerId) {
|
|
67
|
+
log(`Container does not exist for sure, restart`, true);
|
|
68
|
+
await startOnceAndCmd();
|
|
69
|
+
return;
|
|
70
|
+
}
|
|
71
|
+
|
|
72
|
+
try {
|
|
73
|
+
await tryCmd(libdragonInfo);
|
|
74
|
+
} catch (e) {
|
|
75
|
+
if (
|
|
76
|
+
!e.out ||
|
|
77
|
+
// TODO: is there a better way?
|
|
78
|
+
!e.out.toString().includes(libdragonInfo.containerId)
|
|
79
|
+
) {
|
|
80
|
+
throw e;
|
|
81
|
+
}
|
|
82
|
+
await startOnceAndCmd();
|
|
83
|
+
}
|
|
84
|
+
};
|
|
85
|
+
|
|
86
|
+
module.exports = {
|
|
87
|
+
name: 'exec',
|
|
88
|
+
fn: exec,
|
|
89
|
+
forwardsRestParams: true,
|
|
90
|
+
showStatus: true,
|
|
91
|
+
};
|
|
@@ -0,0 +1,157 @@
|
|
|
1
|
+
const chalk = require('chalk');
|
|
2
|
+
const commandLineUsage = require('command-line-usage');
|
|
3
|
+
|
|
4
|
+
const { log } = require('../helpers');
|
|
5
|
+
|
|
6
|
+
const printUsage = (_, actionArr) => {
|
|
7
|
+
const globalOptionDefinitions = [
|
|
8
|
+
{
|
|
9
|
+
name: 'verbose',
|
|
10
|
+
description:
|
|
11
|
+
'Be verbose. This will print all commands dispatched and their outputs as well. Will also start printing error stack traces.',
|
|
12
|
+
alias: 'v',
|
|
13
|
+
typeLabel: ' ',
|
|
14
|
+
group: 'global',
|
|
15
|
+
},
|
|
16
|
+
];
|
|
17
|
+
|
|
18
|
+
const optionDefinitions = [
|
|
19
|
+
{
|
|
20
|
+
name: 'image',
|
|
21
|
+
description:
|
|
22
|
+
'Use this flag to provide a custom image to use instead of the default. It should include the toolchain at `/n64_toolchain`. It will cause a re-initialization of the container if a different image is provided.\n',
|
|
23
|
+
alias: 'i',
|
|
24
|
+
typeLabel: '<docker-image>',
|
|
25
|
+
group: 'docker',
|
|
26
|
+
},
|
|
27
|
+
{
|
|
28
|
+
name: 'directory',
|
|
29
|
+
description: `Directory where libdragon files are expected. It must be a project relative path as it will be mounted on the docker container. The cli will create and manage it when using a non-manual strategy. Defaults to \`./libdragon\` if not provided.\n`,
|
|
30
|
+
alias: 'd',
|
|
31
|
+
typeLabel: '<path>',
|
|
32
|
+
group: 'vendoring',
|
|
33
|
+
},
|
|
34
|
+
{
|
|
35
|
+
name: 'strategy',
|
|
36
|
+
description: `libdragon Vendoring strategy. Defaults to \`submodule\`, which safely creates a git repository at project root and a submodule at \`--directory\` to automatically update the vendored libdragon files.
|
|
37
|
+
|
|
38
|
+
With \`subtree\`, the cli will create a subtree at \`--directory\` instead. Keep in mind that git user name and email must be set up for this to work. Do not use if you are not using git yourself.
|
|
39
|
+
|
|
40
|
+
To disable auto-vendoring, init with \`manual\`. With \`manual\`, libdragon files are expected at the location provided by \`--directory\` flag and the user is responsible for vendoring and updating them. This will allow using any other manual vendoring method.
|
|
41
|
+
|
|
42
|
+
With the \`manual\` strategy, it is still recommended to have a git repository at project root such that container actions can execute faster by caching the container id inside the \`.git\` folder.
|
|
43
|
+
|
|
44
|
+
It is also possible to opt-out later on by running \`init\` with \`--strategy manual\`, though you will be responsible for managing the existing submodule/subtree.\n`,
|
|
45
|
+
alias: 'v',
|
|
46
|
+
typeLabel: '<strategy>',
|
|
47
|
+
group: 'vendoring',
|
|
48
|
+
},
|
|
49
|
+
];
|
|
50
|
+
|
|
51
|
+
const actions = {
|
|
52
|
+
help: {
|
|
53
|
+
name: 'help [action]',
|
|
54
|
+
summary: 'Display this help information or details for the given action.',
|
|
55
|
+
},
|
|
56
|
+
init: {
|
|
57
|
+
name: 'init',
|
|
58
|
+
summary: 'Create a libdragon project in the current directory.',
|
|
59
|
+
description: `Creates a libdragon project in the current directory. Every libdragon project will have its own docker container instance. If you are in a git repository or an NPM project, libdragon will be initialized at their root also marking there with a \`.libdragon\` folder. Do not remove the \`.libdragon\` folder and commit its contents if you are using source control, as it keeps persistent libdragon project information.
|
|
60
|
+
|
|
61
|
+
By default, a git repository and a submodule at \`./libdragon\` will be created to automatically update the vendored libdragon files on subsequent \`update\`s. If you intend to opt-out from this feature, see the \`--strategy manual\` flag to provide your self-managed libdragon copy. The default behaviour is intended for users who primarily want to consume libdragon as is.
|
|
62
|
+
|
|
63
|
+
If this is the first time you are creating a libdragon project at that location, this action will also create skeleton project files to kickstart things with the given image, if provided. For subsequent runs, it will act like \`start\` thus can be used to revive an existing project without modifying it.`,
|
|
64
|
+
group: ['docker', 'vendoring'],
|
|
65
|
+
},
|
|
66
|
+
make: {
|
|
67
|
+
name: 'make [params]',
|
|
68
|
+
summary: 'Run the libdragon build system in the current directory.',
|
|
69
|
+
description: `Runs the libdragon build system in the current directory. It will mirror your current working directory to the container.
|
|
70
|
+
|
|
71
|
+
This action is a shortcut to the \`exec\` action under the hood.`,
|
|
72
|
+
},
|
|
73
|
+
exec: {
|
|
74
|
+
name: 'exec <command>',
|
|
75
|
+
summary: 'Execute given command in the current directory.',
|
|
76
|
+
description: `Executes the given command in the container passing down any arguments provided. If you change your host working directory, the command will be executed in the corresponding folder in the container as well.
|
|
77
|
+
|
|
78
|
+
This action will first try to execute the command in the container and if the container is not accessible, it will attempt a complete \`start\` cycle.
|
|
79
|
+
|
|
80
|
+
This will properly passthrough your TTY if you have one. So by running \`libdragon exec bash\` you can start an interactive bash session with full TTY support.`,
|
|
81
|
+
},
|
|
82
|
+
start: {
|
|
83
|
+
name: 'start',
|
|
84
|
+
summary: 'Start the container for current project.',
|
|
85
|
+
description:
|
|
86
|
+
'Start the container assigned to the current libdragon project. Will first attempt to start an existing container if found, followed by a new container run and installation similar to the `install` action. Will always print out the container id on success.',
|
|
87
|
+
},
|
|
88
|
+
name: {
|
|
89
|
+
name: 'stop',
|
|
90
|
+
summary: 'Stop the container for current project.',
|
|
91
|
+
description:
|
|
92
|
+
'Stop the container assigned to the current libdragon project.',
|
|
93
|
+
},
|
|
94
|
+
install: {
|
|
95
|
+
name: 'install',
|
|
96
|
+
summary: 'Vendor libdragon as is.',
|
|
97
|
+
group: ['docker'],
|
|
98
|
+
description: `Attempts to build and install everything libdragon related into the container. This includes all the tools and third parties used by libdragon except for the toolchain. If you have made changes to libdragon, you can execute this action to build everything based on your changes. Requires you to have an intact vendoring target (also see the \`--directory\` flag). If you are not working on libdragon itself, you can just use the \`update\` action instead.
|
|
99
|
+
|
|
100
|
+
This can be useful to recover from a half-baked container.`,
|
|
101
|
+
},
|
|
102
|
+
update: {
|
|
103
|
+
name: 'update',
|
|
104
|
+
summary: 'Update libdragon and do an install.',
|
|
105
|
+
description:
|
|
106
|
+
'If you are using auto-vendoring (see `--strategy`), this action will update the submodule/subtree from the remote branch (`trunk`) with a merge/squash strategy and then perform a `libdragon install`. This is the same as an `install` when the vendoring strategy is `manual`. You can use the `install` action to only update all libdragon related artifacts in the container.',
|
|
107
|
+
group: ['docker'],
|
|
108
|
+
},
|
|
109
|
+
};
|
|
110
|
+
|
|
111
|
+
const actionsToShow = actionArr
|
|
112
|
+
?.filter((action) => Object.keys(actions).includes(action))
|
|
113
|
+
.filter((action) => !['help'].includes(action));
|
|
114
|
+
|
|
115
|
+
const sections = [
|
|
116
|
+
{
|
|
117
|
+
header: chalk.green('Usage:'),
|
|
118
|
+
content: 'libdragon [flags] <action>',
|
|
119
|
+
},
|
|
120
|
+
...(actionsToShow?.length
|
|
121
|
+
? actionsToShow.flatMap((action) => [
|
|
122
|
+
{
|
|
123
|
+
header: chalk.green(`${action} action:`),
|
|
124
|
+
content: actions[action].description,
|
|
125
|
+
},
|
|
126
|
+
actions[action].group
|
|
127
|
+
? {
|
|
128
|
+
header: `accepted flags:`,
|
|
129
|
+
optionList: optionDefinitions,
|
|
130
|
+
group: actions[action].group,
|
|
131
|
+
}
|
|
132
|
+
: {},
|
|
133
|
+
])
|
|
134
|
+
: [
|
|
135
|
+
{
|
|
136
|
+
header: chalk.green('Available Commands:'),
|
|
137
|
+
content: Object.values(actions).map((action) => ({
|
|
138
|
+
name: action.name,
|
|
139
|
+
summary: action.summary,
|
|
140
|
+
})),
|
|
141
|
+
},
|
|
142
|
+
]),
|
|
143
|
+
{
|
|
144
|
+
header: chalk.green('Global flags:'),
|
|
145
|
+
optionList: globalOptionDefinitions,
|
|
146
|
+
},
|
|
147
|
+
];
|
|
148
|
+
const usage = commandLineUsage(sections);
|
|
149
|
+
log(usage);
|
|
150
|
+
};
|
|
151
|
+
|
|
152
|
+
module.exports = {
|
|
153
|
+
name: 'help',
|
|
154
|
+
fn: printUsage,
|
|
155
|
+
showStatus: true,
|
|
156
|
+
forwardsRestParams: true,
|
|
157
|
+
};
|