I’m using the compiler as described here to compile a plugin: Rhino Script Compiler for Rhino5, second Beta
and I’ve written a piece of code that generates the xml for the .rhc rhino compiler project file so that I don’t have to navigate RhinoScriptCompiler when I want to recompile, add new commands, etc - I just load up the xml file I’ve created and compile. But is there a way to streamline this process by not even opening the RhinoScriptCompiler?
Hi Sean, not sure if I understand. Here the script compiler is the default application to open rhc files. If I open or execute a rhc file the script compiler automatically compiles the defined plugin. Is this what you want?
Yes, it is – it does exactly what I want it to do already. Silly misunderstanding on my part. Thanks!
When you automatize your scripting process, are you doing it from a physical Shell (like manually executing a batch file which starts “RhinoScriptCompiler.exe file.rhc”) or did you manage to do it through a tool like Jenkins?
Hi Nathan - right now I’m executing the batch file manually, I was wondering about Jenkins but I see from your most recent topic you’re having trouble with RhinoScriptCompiler.exe, is that still the case?
Yes still issues… I didn’t get any answer from developers yet.
On my side, I use the RhinoScriptCompiler.exe only to compile the .RHP, the rest is done via scripts as I need to include a .RUI and other extra files. Hence, as my .RHP doesn’t change very often I have decided (as a workaround) to manually generate the RHP every time I modify it.
To be continued…
Sounds somewhat similar to my case. Haven’t got around to automating the build of the RUI yet; I plan to look into that next.
I figure that given the size of my project it might be fine to just trigger the batch every day at lunchtime or something like that. Would be great to get some clarity on RhinoScriptCompiler…
Given the tests that I’ve performed, this seems to be related to the RhinoScriptCompiler trying to have an interaction with a physical Shell window, which is absent in Jenkins. So a “true batch” methodology should be the key, but only access to the sources could confirm that.