On Unix-based systems, one can simply run any apps a project defines by invoking their .tcl files directly, e.g., "./bin/myapp.tcl ...". On Windows (unless you use a bash shell), invoking a .tcl script executes it using wish.exe, which is annoying (especially if the app is a non-gui app).
The solution is to execute the .tcl files using tclsh.exe, i.e., "tclsh ./bin/myapp.tcl". This works for project apps, since the app loader script sets up the environment properly.
But there's also a need to run other scripts in the context of the project code base, and for that simply using tclsh isn't enough. One can simply write the script to point at the project's code, but that's contrary to the spirit of Quill, which is supposed to make everything simple. We can reach this goal by adding two features to Quill.
First, 'quill run' needs to invoke the primary app (the first app listed in project.quill), passing any additional arguments along to it. It will invoke using tclsh.exe on Windows; and if the app 'package requires' Tk, it can do so without any trouble. It will remain a console app, and any debugging puts statements will output to the console.
Second, 'quill filename.tcl args....' should invoke the named script in the context of the project's code base. Quill can do this by setting up the TCLLIBPATH appropriately, and then executing the script using the platform tclsh. This will allow the user to execute arbitrary scripts in the project context.
These two features will work just as well on Windows as they do on other platforms.
On Unix-based systems, one can simply run any apps a project defines by invoking their .tcl files directly, e.g., "./bin/myapp.tcl ...". On Windows (unless you use a bash shell), invoking a .tcl script executes it using wish.exe, which is annoying (especially if the app is a non-gui app).
The solution is to execute the .tcl files using tclsh.exe, i.e., "tclsh ./bin/myapp.tcl". This works for project apps, since the app loader script sets up the environment properly.
But there's also a need to run other scripts in the context of the project code base, and for that simply using tclsh isn't enough. One can simply write the script to point at the project's code, but that's contrary to the spirit of Quill, which is supposed to make everything simple. We can reach this goal by adding two features to Quill.
First, 'quill run' needs to invoke the primary app (the first app listed in project.quill), passing any additional arguments along to it. It will invoke using tclsh.exe on Windows; and if the app 'package requires' Tk, it can do so without any trouble. It will remain a console app, and any debugging puts statements will output to the console.
Second, 'quill filename.tcl args....' should invoke the named script in the context of the project's code base. Quill can do this by setting up the TCLLIBPATH appropriately, and then executing the script using the platform tclsh. This will allow the user to execute arbitrary scripts in the project context.
These two features will work just as well on Windows as they do on other platforms.