The list of required tools is getting long, and nim in particular is proving hard to install on certain environments. On top of that all the PATH and environment settings increase the barrier further, which is starting to reintroduce what the project set out to solve to begin with.
I can think of two options:
Provide a compiled binary instead of an interpreted script
Build in a container
Both of these approaches require that the build script is made into a tool that can be accessible on the PATH, rather than included as part of the project. The details regarding this change is tracked in #12
Option 1 could be done as a nim program and potentially remove the need for ruby and the need to install neverwinter_utils.nim if statically linked (although I don't know if this is true), but would still require an NSS compiler to be installed. In addition, rewriting everything in a new language is not a task I find very attractive at the moment, and the current lack of YAML support in neverwinter_utils.nim means the output would be limited to JSON.
Option 2 removes everything except for the docker requirement. This way is significantly faster than option 1, and should provide all the same flexibility compared to running on the host. The intention is to provide an image from which module developers can spawn containers that issue a command to build.rb and dies quietly when the command returns. Coupled with command aliases the use of docker can be completely transparent to the user. For instance, the below alias would look and behave exactly the same as having nwn-build on PATH symlinked to build.rb in devbase
alias nwn-build="docker run --rm -it -v '$(pwd):/root' devbase:latest"
Docker hub provides automated builds with github webhooks, and should cover all the need for CI. The only problem I see is that there is no apparent way of triggering builds on updates to the third party tools - nwnsc compiler and neverwinter_utils.nim - other than those tools also being available as automated builds on docker hub and using linked builds.
The list of required tools is getting long, and nim in particular is proving hard to install on certain environments. On top of that all the PATH and environment settings increase the barrier further, which is starting to reintroduce what the project set out to solve to begin with.
I can think of two options:
Both of these approaches require that the build script is made into a tool that can be accessible on the PATH, rather than included as part of the project. The details regarding this change is tracked in #12
Option 1 could be done as a nim program and potentially remove the need for ruby and the need to install neverwinter_utils.nim if statically linked (although I don't know if this is true), but would still require an NSS compiler to be installed. In addition, rewriting everything in a new language is not a task I find very attractive at the moment, and the current lack of YAML support in neverwinter_utils.nim means the output would be limited to JSON.
Option 2 removes everything except for the docker requirement. This way is significantly faster than option 1, and should provide all the same flexibility compared to running on the host. The intention is to provide an image from which module developers can spawn containers that issue a command to build.rb and dies quietly when the command returns. Coupled with command aliases the use of docker can be completely transparent to the user. For instance, the below alias would look and behave exactly the same as having
nwn-buildon PATH symlinked to build.rb in devbaseDocker hub provides automated builds with github webhooks, and should cover all the need for CI. The only problem I see is that there is no apparent way of triggering builds on updates to the third party tools - nwnsc compiler and neverwinter_utils.nim - other than those tools also being available as automated builds on docker hub and using linked builds.