+- Cuberite Forum (https://forum.cuberite.org)
+-- Forum: Cuberite (https://forum.cuberite.org/forum-4.html)
+--- Forum: Development (https://forum.cuberite.org/forum-13.html)
+--- Thread: python or perl as additional dependecy for generating code. (/thread-1310.html)
python or perl as additional dependecy for generating code. - worktycho - 01-12-2014
I'm just going through the cPluginManager::Call* methods to add locks and it seems to me that it would be far easier to autogenerate the methods from a list of Hooks. However that is somewhat beyond to c++ preprocessor. At the moment we have no dependent programs capable of generating the code and it seems slightly over the top to write a program in c++ to generate these methods. So how do you feel about adding a perl or python script to generate the methods?
RE: python or perl as additional dependecy for generating code. - NiLSPACE - 01-12-2014
I"m not an expert but we could maybe use Lua since that is what MCServer uses as scripting language?
RE: python or perl as additional dependecy for generating code. - worktycho - 01-12-2014
Good point, I'll use that.
RE: python or perl as additional dependecy for generating code. - xoft - 01-12-2014
Too many obstructions for a regular windows developer. I know there are perl and python implementations for windows, but that's just too many dependencies to install just to compile the code.
Now, we do have full Lua sources in the repo. We could compile the Lua executable out of it and generate the code using a lua script. But that's just like the Bindings.*, and you said it cannot be done for Windows using cmake without using some advanced dark magic. I still want cmake more than autogenerated code.
I guess I'm too slow responding, before I type everything, the discussion is already two miles ahead
RE: python or perl as additional dependecy for generating code. - worktycho - 01-12-2014
We have lua in the repository and you can invoke msbuild from the command line so i'll just write a batch script that will compile lua, generate the hooks and generate the buindings. You just then call the script whenever you currently run tolua++.
RE: python or perl as additional dependecy for generating code. - xoft - 01-12-2014
A silly idea: could we bend tolua++ to actually execute a Lua script for us? Then we won't need to compile Lua at all - the tolua++ executable is already in the repository for Windows to use.
Because invoking msbuild means you need to execute it in a shell that has been VisualStudio-lized (typically from the start menu -> visual studio -> visual studio command prompt, then chdir to your folder, then execute script), it is rather difficult for newcomers.
Yup, it should be possible - tolua++ has the -L option that runs any Lua file before doing the tolua run, so it could be done.
Unfortunately it only supports one such file and we already use one for generating the bindings. So the code will have to be appended to that file, rather than in a separate file - or use a "dofile()" function.
RE: python or perl as additional dependecy for generating code. - worktycho - 01-12-2014
So if lua is impractical as well is there any sensible way of doing code generation or am I going to have horrible macros or have bindings regenerate on completely irrelevant things so that they can generate something completely different or can you think of a practical way of generating code in visual studio that isn't T4 files.
How about we just commit a lua interpreter executable to the repository for windows. Its only windows that has the problem with autogenerated files so only windows needs the special handling.
RE: python or perl as additional dependecy for generating code. - xoft - 01-12-2014
Lua is practical and the interpreter is already there in tolua++, you can use it - just append your code to $/src/Bindings/virtual_method_hooks.lua. Even better, this file is called when generating the Bindings.cpp, so it will regenerate the hooks code at the same time.
RE: python or perl as additional dependecy for generating code. - worktycho - 01-12-2014
That will do for this but it does seem like a hack and will only work for hook processing without losing incremental compilation.