Re: [Premake-users] Advice on linking and dependencies

[Jason M. <ko...@gm...>]

Ash Berlin wrote:
> You do write long messages don't you.
>
> how about an API config block? Something like this:
>
> project "A"
>   kind "SharedLib"
>   links { "boostfoo" }
>   include {"private/include" }
>   api()
>     includedir { "boost-1_37" }
>     defines { "XP_UNIX" }
>     links { "A" } -- Maybe this isn't needed.
>
> I'm not sure if this is actually possible to do like this, but if it  
> is, then anything you pass define in the api block is used by how ever  
> you end up using the project, since its the kind of project that  
> changes how it links, not how you use the project, isn't it. *Me reads  
> your post again to check* Hmmm no, that wouldn't quite work with your  
> distinction between HideLib and ShowLib you had above, unless..
>
>
> project "lowLevel"
>   kind "StaticLib"
>   api()
>     includedir { "..." }
>     links { "lowLevel" }
>
> project "HideLib"
>   kind "StaticLib"
>   -- needs "lowLevel" to compile. Users of HideLib do not need  
> "lowLevel"
>   -- to compile themselves, but those who do linking need  
> "lowLevel.lib" to link themselves.
>   uses "lowLevel"
>
>   -- no api() block
>
> project "ShowLib"
>   kind "StaticLib"
>   -- needs "lowLevel" to compile. Users of ShowLib also need "lowLevel"
>   -- to compile and link themselves.
>   api()
>     uses "lowLevel"
>
>
> project "HideShare"
>   kind "SharedLib"
>   -- needs "lowLevel" to compile and link. Users of HideShare do not  
> need "lowLevel"
>   --  to compile themselves. They don't need to link to "lowLevel",  
> because it's
>   -- already linked to us.
>   uses "lowLevel"
>
>   -- no api()
>
> project "ShowShare"
>   kind "SharedLib"
>   -- needs "lowLevel" to compile and link. Users of ShowShare need  
> "lowLevel"
>   -- to compile and link themselves; they need a duplicate copy of  
> "lowLevel"
>   -- in their address space.
>
>   api()
>     uses "lowLevel"
>
>
> That is to say, if you use a project/lib inside an API block, it is  
> copied recursively into your api block, and also affects the  
> compilation of your own project. If you use it outside of an api  
> block, it just affects compilation/linking of the current project.
>
> Does this make sense, and perhaps more importantly is it implementable?
>
>
> -ash
>
> ------------------------------------------------------------------------------
> The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
> production scanning environment may not be a perfect world - but thanks to
> Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
> Series Scanner you'll get full speed at 300 dpi even with all image 
> processing features enabled. http://p.sf.net/sfu/kodak-com
> _______________________________________________
> Premake-users mailing list
> Pre...@li...
> https://lists.sourceforge.net/lists/listinfo/premake-user
I'm thinking of implementing this as follows.

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.

The reason I prefer "usage" to your "api" functionality (besides the 
fact that I've already implemented that part ;) ) is that it works 
better with configurations. For example, if the debug library is called 
"someLib_d" and the release is "someLib". Users of the project need to 
have access to that difference.