Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

#37 Add usage() to copy settings from dependent projects

5.0
open-accepted
starkos
None
7
2013-02-06
2009-05-21
Korval
No

Cut-and-paste from the mailing list:

As mentioned much earlier, there will be "usage projects". This is a kind of project defined with the word "usage" instead of "project". The values that the usage defines will be copied into any project that lists that usage under its "uses" list. However, a usage alone is not enough to generate an output project, so you can define usages like this:

usage "boost"
kind "StaticLib"
include "boost-1.37"

If you include that code fragment in your solution, you will not get a project called "boost". However, if you have a project that includes "boost" under its uses field, then it will have the "include" fields copied into that project. So, if you have:

project "A"
kind "StaticLib"
uses "boost"
includedirs {"apiDir", "internalDir"}
targetdir "lib"

Then project A will have both boost's include path (the directory will be properly re-rooted to be relative to project A automatically), "apiDir" and "internalDir". The "apiDir" is the directory to the headers that users of A need, and "internalDir" is for internal header files.

Now, let's say we want to use project A in another project. Then what we need is for project A to have a usage project properly defined:

usage "A"
kind "StaticLib"
uses "boost"
includedirs "apiDir"
links "lib/A"

This says that anyone using project A should:

1: have "apiDir" added to their includeDirs.

2: have "lib/A" added to their links.

3: take whatever the usage project called "boost" provides.

The last part is saying something about "A". It *specifically* says that anyone using this library needs "boost" to compile & link.

Therefore, if I have a project that uses it, it is defined simply:

project "B"
kind "SharedLib"
uses "A"

It will automatically get "A"s stuff and "boost"s stuff.

Now, since project "B" is a shared library, it ought to have a usage project so that someone can use it:

usage "B"
kind "SharedLib"

Note that it does *not* list "A" in a usage field. That means that users of "B" don't get "A" or "boost", unless they include them from some other mechanism. Now, if we defined "B" as this:

usage "B"
kind "SharedLib"
uses "A"

Then users of "B" would get all of the compile-time information from "A" and from "boost". It would *not* get the linking information. This is because the usage "B" is defined as a shared-library. If it were a static library, then it would need that information.

There is one situation where we need a second field. Project "A" is a static library. Therefore, if it "uses" other libraries, any project that is a non-static library project that uses "A" will need the linking information from all of the direct and indirect projects. This is separate from "uses". Therefore, we will use "links".

If the links field on a *usage* project refers to a project name, then anyone using this usage project will need the linking information from that project. "uses" brings in both compiling and linking information (where relevant), so "uses" has precedence. And while "links" is recursive, it will not recurse through a SharedLib.

So, we could define A's usage as:

usage "A"
kind "StaticLib"
includedirs "apiDir"
links "lib/A"
links "boost"

And there we are. That should cover all of the corner cases. I don't entirely fancy overloading "links" like that, but since it's a usage project (doesn't get used by the action), it should be fine.

Discussion

  • Korval
    Korval
    2009-05-21

     
    Attachments
  • Korval
    Korval
    2009-05-21

    The patch is made against Premake 4.0

     
  • starkos
    starkos
    2009-05-22

    Pushing the remaining big patches to 4.2

     
  • starkos
    starkos
    2009-05-22

    • milestone: --> 899249
    • assigned_to: nobody --> starkos
     
  • starkos
    starkos
    2010-05-29

    With help from Conrad Mercer, now applied to the development repository. Still needs unit tests and testing in general. Planning to release as part of 4.2.2.

    Thanks for submitting this, much appreciated!

     
  • starkos
    starkos
    2010-05-29

    • summary: Adds the ability to copy information from dependent projects --> Add usage() to copy settings from dependent projects
    • priority: 5 --> 7
    • milestone: 899249 --> 4.3
    • status: open --> open-accepted
     
  • starkos
    starkos
    2011-08-22

    Completing this feature will be my focus for Premake's 4.5 release.

     
  • Is it possible to use existing subset of usages syntax for copying "links", "includedirs", and "defines" without risk of incompatibility with 4.5?

     
  • starkos
    starkos
    2011-10-25

    I'm afraid I can't promise that.

     
  • starkos
    starkos
    2013-02-06

    • milestone: 4.3 --> 5.0