Open aminya opened 3 years ago
Some more points about the docs:
package.json
, which prevents copy-pasting. We also need to support the CMAKE_TS
env variables inside Cmake files. Using CMAKE_JS
is nice for backward compatibility, but not supporting CMAKE_TS
is confusing.
In this issue, I want to discuss things related to options and CLI. As we already discussed, I think we can improve the options and also make
cmake-ts
CLI more ergonomic.Here are the suggestions:
package.json
configuration. It should be possible to use cmake-ts with zero configuration. We already provide default values for many of the options.The following should build with the default config if no option is specified in the package.json
cwd
is used to find package.json. We can make this configuration by accepting a path to the projectBy default
process.cwd
should be considered if the path is not specifiedA flag should be passed to the CLI to specify the build type instead of the package.json entry. This removes the need for adding buildType to package.json or having to modify package.json for debugging/testing.
Allowing building only a certain configuration from CLI. We should allow selecting a certain configuration that is specified in package.json. For that, we need to add a
name
entry so the user can refer to it later from the CLI. This is useful during the development stage as the user only wants to test a certain config.When the previous option is added, we should remove/rename
--nativeonly
and--osonly
. The user can specify the config for that native building to their package.json. If we want to keep them, we should rename them to--defaultConfig
and--currentConfig
that are more explanatory. As discussed in #16--currentConfig
can be useful in unknown envs.Allow passing extra options to Cmake. We should make it possible to pass configs/env variables to Cmake from Cmake-ts CLI.
or
Commander package handles these pretty good