Poll: Which option would be best for autogenerating code?
You do not have permission to vote in this poll.
A perl script commited to the repositry
0%
0 0%
A python script commited to the repositry
100.00%
3 100.00%
A one off script in either language not in the repository
0%
0 0%
a C++ program that could be commited to the repository.
0%
0 0%
other
0%
0 0%
Total 3 vote(s) 100%
* You voted for this item. [Show Results]

python or perl as additional dependecy for generating code.
#1
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?
Reply
Thanks given by:
#2
I"m not an expert but we could maybe use Lua since that is what MCServer uses as scripting language?
Reply
Thanks given by:
#3
Good point, I'll use that.
Reply
Thanks given by:
#4
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 aheadTongue
Reply
Thanks given by:
#5
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++.
Reply
Thanks given by:
#6
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.
Reply
Thanks given by:
#7
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.
Reply
Thanks given by:
#8
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.
Reply
Thanks given by:
#9
That will do for this but it does seem like a hack and will only work for hook processing without losing incremental compilation.
Reply
Thanks given by:




Users browsing this thread: 1 Guest(s)