I've just checked a new feature into the development repository: usages. Usages allow you to specify the settings that are required to link your project (as opposed to building it). For more information, check out the description of the original patch, which provides a little background and shows how to use it.
This is a great and much needed feature; many thanks to Korval for the original patch, and radman for getting it working against the latest code.
Now it needs testing. Grab the latest code from the development repository on BitBucket, try it out on your projects, and let me know what kinds of problems you run into. In the meantime I'll get started on unit tests and some proper documentation. I'd like to get this out as part of the upcoming 4.2.2 release (and soon!).
Thanks!
Share
After reading the description it strikes me that "aspect" might be a more descriptive name than "usage".
I like the feature so far but there is a small request. It would be nice if "defines" carried across in a usage also. I tend to break up my stuff to support alternate build styles based on need. So, for instance, I have the following:
usage "core"
kind "StaticLib"
defines "BUILD_STATIC=1"
includedirs .... etc
usage "core_dll"
kind "DynamicLib"
includedirs .... etc
If the defines were carried with the usage then certain of the base configuration items no longer need to be remembered when you are just "using" the libraries.
Maybe this is supposed to work? If so, it doesn't seem to work. The include paths and related come over but the defines are silently ignored.
Another little note about usage. It looks like the link paths are getting messed up if you split up the premake files and use dofile in various directories. I.e.:
external
somelib
include
lib
somelib.lib
somelib_usage.lua
build/vs2008
premake4.lua
The include path gets set correctly but the link libraries get the incorrect path. I.e. instead of "../../external/somelib/lib/somelib.lib" it puts in "external/somelib/lib/somelib.lib" no matter what I do to correct the path.
Bah, it striped the spaces..
external
-somelib
--include
---lib
----somelib.lib
-somelib_usage.lua
build/vs2008
premake4.lua
Pretend the '-'s are spaces. :)
At this point, usages are clearly incomplete. I am planning to address them once 4.3 goes out the door, and hopefully include them in the 4.4 release.
K, well, I love the idea and had written something very much like it for my build system based on premake. I break things into relatively small libraries and pull them into larger items as required. As such, usage seems like a kick ass little addition and I can remove a lot of lua support code I have.
So, I spent some time poking around the usages code and while I haven't had time to really do much debugging, I did find some viable work around items which may help to narrow down the problems I'm running into.
The primary item was the link path ending up generally being indirected too many levels down in the build tree, in fact, often outside of the base directory completely. This happens anytime I attempt to use fully rooted paths, paths relative to the base directory of the entire project etc etc. On the other hand, everything works just fine in the case that I use something such as the following:
somelib_dir = path.join( os.getcwd(), "../somelib" )
And then build all paths off of that, i.e. the ".." seems to prevent several problems.
The other change, is that instead of trying to put the external library solutions out in the external directory and I just let them be stored with the actual referencing project, that corrects all the issues with linkage.
So, my current debugging assumptions would be (if I can get back to looking at the code anytime soon):
1. The generated relative path is only relative to the solution file of the non-using project files and/or the location of the overall solution. The usage is not recording the location the usage was defined and as such it builds paths relative to users of the file instead of the usage file itself.
2. Having '..' in the path somehow is breaking the "path.getrelative" such that by side effect things work as desired?
Just some follow up information on the problems, will try and fix it myself if work lets up a bit or hopefully the above will help track down the problems.
Hi starkos,
So, I keep messing with usages and decided to start a little test suite for them. So far I believe I have a number of the bugs identified and duplicated in the testbed. (Will list current known bugs shortly.) Just curious if you would like a copy of this and/or have a place I could put it for folks to play with. Basically it is just 3 items, an "external" directory (dropped zlib into it for example) to simulate linking against (and building in some cases) externally supplied libraries, a little application (just main) and a library (one function). With this I believe I can exercise all the ways you would want to use usages and identify the failures better. It is incomplete but outlines some of the ways I would like to use usages in a very large project.
Anyway, here is the complete list of bugs as I've identified at this time using the test suite:
1. If the usage name is the same as the links name, the dev branch spits out: "Failed to copy 'xxx' from proj 'xxx'." This one took a long time to figure out since it only happened in release builds where I did not have a "_d" appended to the library name, I kept thinking it was something to do with my configuration setup or something.
2. The path to a library when in the "usage" block as a "links" entry fails to respect where the project file being generated is located. I.e. in the following structure:
external
-build
--blargo_usage.lua
--vs2008
---bin/x32/debug/blargo.lib
my_project
-premake4.lua
-vs2008
--my_project.sln
--my_project.prj
If "blargo_usage.lua" references via the "links" construct to the blargo_lib (relative or absolute), the linkage to the library will always be: "../external/build/vs2008/bin/x32/debug/blargo.lib", instead of having the "../../" needed for it to be correctly relative to the sln/prj.
Currently the workaround is goofy, if you put the path in a "libdirs" and then just links "blargo", everything works fine and the additional library path is correctly set relative to the sln/prj directory and not where premake4.lua exists. Of course this will not work for MonoDev or SharpDev not that it probably matters.
3. Usages do not seem to respond to configuration correctly. Specifically if you use something like:
configuration { "vs2008", "x32", "Debug" }
-- do stuff.
configuration { "vs2010", "x32", "Debug" }
-- do stuff.
You will get both blocks of "do stuff" in the project. Double links to libraries, multiple include paths etc. This is only the case when you try to use the _ACTION defined configuration portion, the other two items "x32" and "Debug" seem to be correctly dealt with.
Those are the primary items I've identified and can reproduce consistently. With the reproduction steps hopefully the next time I get some free time I can actually poke at premake4 and try to help debug the issues. Of course the week before Christmas work is nuts so probably not going to look at this till next year.
KB
If you don't mind, log this to the bug tracker. You can just link back to this thread if you want. Good information to have, thanks for looking into it.
Will try to get the bug added in a bit, just can't remember my sourceforge login at the moment. :/
As a note, I found another issue:
If you call dofile on a usage lua file twice on accident, premake fails out with:
[string "premake.fields = ..."]:505: attempt to call global 'iff' (a nil value)
Given my method of trying to hierarchically build up the solutions from stand alone usage/project files sometimes multiple inclusion makes sense. Currently I'm having to do this pretty much like a header file with an "if xxx_defined then" wrapper.
@All8Up - Use require instead of dofile.
Bah, never even though about that. Works like a charm.
This is something I've also been able to reproduce. In my case I have a project named "Core", then an usage on that project called "CoreStatic" that has a links {} block with a "Core" library.
Here is a simple test that reproduces it in the latest dev version.
And output:
Just a friendly reminder that usages are very much a work in progress, and likely to change when I get back to them in the next version.