What would you think about breaking up the tasks in siwin.nimble into config.nims and 'build_util' modules? Then you can use the tasks with or without Nimble by running them directly with nim, e.g. nim test or nimble test.
In the nimble file you do:
when fileExists("config.nims"):
include "config.nims"
when fileExists("src/siwin/build_utils/android.nim"):
include "src/siwin/build_utils/android.nim"
A benefit of this sort of setup is being able to reuse build tasks for Android, etc. This is difficult to do in a Nimble file since it creates a bootstrap issue.
Then in user projects they can do:
## config.nims or .nimble in their project:
include siwin/build_utils/android
I did that with Nesper with a https://github.com/elcritch/nesper/blob/devel/src/nesper/build_utils/builds.nim and then used like https://github.com/elcritch/nesper/blob/eadd2f9e5b5187f88369611047d608d7ebc808df/esp-idf-examples/uart_echo/config.nims#L1 which has been very easy and reliable.
What would you think about breaking up the tasks in siwin.nimble into config.nims and 'build_util' modules? Then you can use the tasks with or without Nimble by running them directly with nim, e.g.
nim testornimble test.In the nimble file you do:
A benefit of this sort of setup is being able to reuse build tasks for Android, etc. This is difficult to do in a Nimble file since it creates a bootstrap issue.
Then in user projects they can do:
I did that with Nesper with a https://github.com/elcritch/nesper/blob/devel/src/nesper/build_utils/builds.nim and then used like https://github.com/elcritch/nesper/blob/eadd2f9e5b5187f88369611047d608d7ebc808df/esp-idf-examples/uart_echo/config.nims#L1 which has been very easy and reliable.