ToLua and tardis

[1337]

As already mentioned in the commit message, two hours of FuK are very "enlightening".
It wasn't that easy to make things go. The problem was mostly the path, which was always the root directory of the trunk when executing a process from cmake files. I was finally able to deal with it by using scripts:
tolua-build
bin/exec-tolua-script

These are called in the root CMLs to build tolua and later create the tolua_bind files.

For now it seems to work on tardis (compile at least, couldn't test yet), but there are at least 2 problems left:
- write batch files for windows boxes and write #IF (WIN32) to the CMLs
- tolua can't handle makro definition. For instance in class _CoreExport Script {}; how could tolua know that _CoreExport is a makro?
--> I had to copy Script.h to Script_clean.h
This is not a very solution frankly. But I have got an idea: we could use gcc (maybe even cmake to ensure compatibility) and its preprocessor output to create those Class_clean.h files automatically. The problem is: #include <librarfile> won't be found, but doesn't have to be --> use grep to remove alle #include lines.
However, I'm no grepper and it's not portable.

[beni]

I experimented on a better way than those _clean files, because I agree those are troublesome.

Check out this link

I wrote a hack like something like this:

Code: Select all

#if 0
// tolua_begin
#define _CoreExport
// tolua_end
#endif

It didn't work and I'm not sure why. Anyhow there has to be a possibility to find a workaround. Class definitions can also be written directly into the package file. This means you could - with some changes maybe - copy Script_clean.h directly into the package file.
Well, I dunno, but there's gotta be a way.
Good work there Reto.

[1337]

sample.oxw: empty file

Does anyone know why this would happen? I only see a loading screen of some kind in this case.

Is it possible that I messed up something with the scripting? Probably not, because if I remove the lua tags, the error stays the same

About the _CoreExport: No idea. that really should work

EDIT: Found a workaround: Disable lua parsing
I removed the asteroids and reverted Loader.cc and everything works fine.
ticpp was actually complaining about an empty file... I already did dos2unix, with no success.
What might be the problem? Curiously things work with windows... this is the wrong way round!

[beni]

Well. It means that the luaparsing is not working. Lua's stdout is redirected into a string. If this string is emtpy, ticpp complains. Have a look for a lua compiling error along the way.

Since that #define doesn't work, there maybe something wrong with the tolua parsing. Maybe we can edit that so it DOES replace "_CoreExport" with nothing.

EDIT: This would have to be in package.lua in the tolua++ source code (tolua/src/bin/lua)

The lua version could be the source of the problem, that it works on Windows only. Maybe if you try with the old lua-version on your system this would shed some light on this.

[1337]

I'll try the old, but first I have to find a way to organise tolua with VC++. There are Pre-Build commands. I should be able to do something.

HA: you were so right. I was finally able to compile lua50 (I might have made a little bit of a mess with the version, so took me some time... ).

--> Exactly the same error. ticpp finds an empty file.
I hope this is the last thing to deal with until the trunk is working alright.

[beni]

Okay, now it works. The error was the modulo operator '%' which is not supported in lua50. It's a new feature of lua 5.1

However, we still have to find a solution for the macro...

[1337]

/* Open function */
TOLUA_API int tolua_orxonox_open (lua_State* tolua_S)
{
...
tolua_beginmodule(tolua_S,NULL);
tolua_constant(tolua_S,"_CoreExport",_CoreExport);
tolua_module(tolua_S,"orxonox",0);
...
return 1;
}


Do you spot the _CoreExport? The 'defining constants' in the tolua++ reference was meant a little bit differently...
It seems to me that theses constants can then be used when writing lua code, as demonstrated here: http://www.codenix.com/~tolua/tolua++.html#using (see #define TRUE and the blow in lua code somewhere)

--> whenever we use macros or preproc. constants, tolua will screw up.

Therefore (if what I claim is actually true) we will have to write clean header files ourselves or let something do it for us.
I have just made a few tests and can state the following:
- tolua_bind.cc includes all the 'cleaned' files, which means they have to be syntactically (c++) correct.
- We can use gcc preprocessor output.
- grep can only operate on a single line, but if we were to write tolua_export on every line, grep is extremely helpful

So far I came up with the idea to create the preprocessor output, then use grep to skip all the lines not containing // tolua_export. There is one thing missing: in tolua_bind.cc, we'll have to replace
#include "MyHeader_clean.h" with
#include "MyHeader.h"
because tolua_bind needs the right header with all #inlcude <string> etc.
On unix systems, sed can do the job and replace all MyHeader_clean.h with MyHeader.h
sed 's/_clean//g' tolua_bind.cc > tolua_bind2.cc
mv tolua_bind2.cc tolua_bind.cc
(of course '_clean' is not very unique and therefore not very suitable)

I haven't even started to script any of this, but I'm pretty convinced that it is possible. What hasn't been tested yet is how to find the preprocessed files and pick the right ones to pass to grep. We could use the tolua.pkg file formatted in a special way, so that cmake READ can store all the values and with a FOR EACH we could process them...

It all sounds very hypothetical, but with a little bit of time...
Or, we simply write the cleaned ourselves (should not be that difficult...)