14.03.2012, 23:06, "Jason McKesson" <korv...@gmail.com>:
> Wouldn't this make more sense?
>
> --add-on
>
> luacCompile = {
> description = 'Compiling "%(file.abspath)"',
> commands = {
> 'luac -o "%(cfg.objdir)/%(file.basename).out" "%(file.fullpath)"'
> },
> outputs = {
> '%(cfg.objdir)/%(file.basename).out'
> }
> }
>
> -- premake4.lua
>
> dofile(add-on) --or whatever else you want to do to call the add-on script.
>
> solution "A"
> project "B"
> configuration "**.lua"
> buildrule(luacCompile)
>
> `usage` is for defining usage projects, so that you can more easily link
> headers and libraries, to set up dependencies between projects.
> Overloading it in this case isn't a good idea, especially when we can
> just use the rules of Lua to easily achieve the same effect.
I thought the next way:
1) Usage is a special kind of project that copies its fields to projects where
it's
used
2) buildrule is just one of fields. Why not to copy it too?
I think "usage" should have more generic meaning than just "headers and
libraries".
For example, when using my Qt add-on you write
project "A"
uses "Qt"
-- ....
and it not only adds includes and libraries, but also sets up Qt-specific build
rules
and compiler flags.
>
>> 2. There is a duplication between commands and outputs. We need context
>> object outfiles:
>>
>> buildrule {
>> description = 'Compiling "%(file.abspath)"',
>> commands = {
>> 'luac -o "%(outfiles[1].fullpath)" "%(file.fullpath)"'
>> },
>> outputs = {
>> '%(cfg.objdir)/%(file.basename).out'
>> }
>> }
>>
>> 3. Customization of add-on buildrule properties for project
>>
>> buildrule("rulename").flags = { ... }
>>
>> => we need rule names to refer to them.
>>
>> 4. There should be one more context object - buildrule itself (e.g.,
>> %(rule)). This will allow to use rule properties such as flags in build
>> command, e.g.
>>
>> buildrule {
>> name = "luac",
>> compiler = "luac",
>> description = 'Compiling "%(file.abspath)"',
>> commands = {
>> '%(rule.compiler) -o %(if not rule.flags.DebugInfo then return
>> "-s" end) "%(cfg.objdir)/%(file.basename).out" "%(file.fullpath)"'
>> },
>> outputs = {
>> '%(cfg.objdir)/%(file.basename).out'
>> }
>> }
>> -----------------
>>
>> buildrule("luac").compiler = "/usr/local/bin/luac" -- Changes luac
>> executable
>> buildrule("luac").flags.DebugInfo = false -- Adds -s option to luac
>> invocations
>
> This is a needless overcomplication of what should be a simple system.
> Use Lua to your advantage: just have a global variable somewhere with
> the location of the Lua compiler in it, as well as flags. Then use those
> values as part of your command. You don't need to run conditional
> statements in the `%()` syntax; that just makes implementing the system
> that much more difficult.
I think it's an extremely bad practice to use global variables across bounds of
independent modules. Global variable can be redefined in other add-on by
accident, while access through methods may throw error or warning.
>
> That being said, it might not be a bad idea to allow a command to be a
> Lua function. That is, you can do something like this:
>
> commands = {
> function(context)
> return --string of the command to use.
> end
> },
>
> This would be a lot easier to implement than what you're trying to do.
> The `context` would just be some kind of object you could query things
> like `cfg.objdir` and so forth from.
AFAIU it does the same as %(--string of the command to use),
but provides one context table instead of several independent ones
--
Regards,
Konstantin
------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
_______________________________________________
Premake-users mailing list
Premake-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/premake-users
