Home » Premake » Forums » General Discussion

Executing Lua function as prebuild/postbuild/prelinkcommand

annulen | 07 Jun 2011

I've implemented exec action which executes given file with Lua code or bytecode in full environment of project so any global variables and functions could be used inside:

https://bitbucket.org/annulen/premake-dev/changeset/23824755b3ef

Now I can implement this feature request:
https://sourceforge.net/tracker/index.php?func=detail&aid=3301258&group_...

I think it should be implemented the next way:
1) Add new set of project fields (e.g. 'prebuildexec', 'postbuildexec', 'prelinkexec') with argument being string or function
2) Before calling action:
2a) If we got a string, write it to file as is (Lua code)
2b) If we got a function, write string.dump() of it to file (bytecode)
3) Append to list of appropriate *commands new command _PREMAKE_COMMAND.." exec ".. filename
4) Steps 2 and 3 should be executed only for "project generation" actions. They must not be executed on "exec" or "clean"

Is it OK?

Some questions:
1) Do we need to support string input? It's easy to implement but I'm not sure it's worthwhile
2) Is it enough to add new fields to premake.fields in api.lua to get them working? Is it possible for one field to contain string or function?
3) Where should I place code for steps 2 and 3? Seems like it should be called form _premake_main.lua, but it may be more effective to perform this operations in some other place where iteration over projects is being done (bake.lua?)
4) Is there any generic way to determine if action generates project (gmake, vs*, ...) or does something else (clean, user defined action, ...)?

‹ Sharing Projects Between Solutions Support for projects using Qt Framework ›
annulen | 07 Jun 2011 16:25

Figured out 4th question: I need to check if action has onsolution and onproject

starkos | 08 Jun 2011 12:59

This seems like overkill. With the addition of _PREMAKE_COMMAND it is really easy to do what you're suggesting without all the new APIs.

newaction {
   trigger = "prebuild",
   execute = function ()
      -- do prebuild stuff here
   end
}
 
prebuildcommands
{
   _PREMAKE_COMMAND .. " /prebuild"
}
annulen | 08 Jun 2011 13:26

Great solution, I didn't think about this way.

Some minor issues:
1. There's no protection against trigger name clash
2. Premake requires option description ("action needs a description"). Now I must device not only unique trigger but also add a description.
3. These action(s) will be shown in help but there may be no sense in running them manually

starkos | 09 Jun 2011 13:12

I think private or internal actions might be worthy of a feature request.

annulen | 09 Jun 2011 13:36

Done
https://sourceforge.net/tracker/?func=detail&aid=3314218&group_id=71616&...

annulen | 29 Nov 2011 08:35

Actions without name and description could be treated as internal.

annulen | 08 Dec 2011 08:33

Added new 'isinternal' boolean flag to make things more clear

annulen | 06 Jan 2012 15:58

It still seems too low-level for me (in general, exposing built-in variables in public API doesn't seem right to me).

I propose to add new APIs prebuild/postbuild/prelinkaction, taking action name or in-place action declaration as a parameter. In-place declaration should have isinternal = true by default.

annulen | 14 Jan 2012 13:49

>I propose to add new APIs prebuild/postbuild/prelinkaction

...or even make possible to use actions anywhere inside build process (like Ant tasks)