Re: [Enigma-devel] Re: tolua++ Makefile targets

[Daniel Heck]

> I rechecked the reasons why the old tolua rules have been commented out:
> 
> Indeed tools/tolua is build before the src directory - no problem.
> 
> But the subversion checkout modifications dates of *.cc, *.hh and *.pkg 
> are the dates the files are downloaded and stored on the local system. 
> Thus a *.pkg might be "newer" than the generated *.cc, *.hh. This causes 
> a rebuild of the *.cc, *.hh which is a modification:
> 
> ...
> 
> This causes trouble with the next commit ...

Yes, and this also happened with CVS.  It's annoying but not that much.
The worst thing that could possibly happen is that someone else edits
the .pkg files and you get a conflict on your next update.  But even
that is solvable with a simple "svn revert".

> There are several solutions to the problem:
> 1. comment out the rules as Daniel did
> 2. introduce a special target that you have to make manually if you 
> modify the *.pkg
> 3. eliminate the generated *.cc, *.hh from the repository and supply 
> appropriate build rules
> 
> Solution 3. looks like the best one. But you would have to fiddle with 
> makefile.am as automake supports only yacc and lex as *.cc generators. 
> You can test it by a fresh checkout and immediate deletion of src/lua-*. 
> As far as I know you would have to supply suffix-rules for automake. But 
> then we would have to rename the *.pkg to be suffix-rule compatible - I 
> guess that would be acceptable to Daniel? The distribution of the 
> correct source files would have to be checked, too.

You would not have to fiddle that much to achieve (3), actually the
outcommented rule in the makefile does everything except deleting
the .cc/.hh files afterwards.  But you could achieve that using
".INTERMEDIATE", though.

But there is another reason why (3) may not be the best idea: it breaks
cross-compilation because tolua is also compiled for the target system
not for the host system... It may work if you set something like TOLUA=
$HOME/bin/tolua during configuration, but it's still a mess.

So I would vote for either (2) or for uncommenting the old rules and
having to live with the occasional "svn revert" :-) I see neither
solution as a big problem: changes to the Lua interface tend to happen
very rarely anyway.

Cheers,
Daniel