Strategy to link/include library

[Jacob Carlborg]

On 2013-01-16 16:08, o3o wrote:

> Let me play with some scenario: I've a library 'acme' release 1.0 and
> two client C1 and C2.
>
> * scenario 1: acme in common directory
> + acme
>    ...
> + C1
>    ...
> + C2
>    ...
>
> So, in C1
> $dms -I../acme *.d
>
> and in C2
> $dms -I../acme *.d
>
> suppose that C2 need a new feature from acme library, so I modify and
> recompile acme sources and I get the new acme rel. 2.0.
> But C1 still uses the old release 1.0, and if I recompile C1 it is
> linked to new new acme rel. 2.0...
>
> * scenario 2: acme in subdirectory
> If I include acme as subdirectory like this:
>
> + C1
>    ...
>    + acme
> + C2
>    ...
>    + acme
>
> I resolve the problem on scenario 1. (C1 uses rel. 1.0 and C2 rel. 2.0)
> but if I fix a bug in acme, I should update C1, C2 and all other clients
> that use acme.
>
> What do you think? what is your way of working?

For my projects I mostly use git submodules. A submodule will be its own 
repository but included in another repository. They have separate commit 
histories. A submodule is locked at a given commit from the repository 
of the submodule.

> which package manager do you suggest? (of course orbit :) ),

Yes :) But currently there is now package manager available specific for D.

> and which build tool (I use rake)?

For executables I use a shell script with rdmd. rdmd will track and 
compile all dependencies. I usually don't compile libraries, just 
include them together with the application and compiler everything at 
once with rdmd.

In the end I'm not really happy with any solution available, that's why 
I'm working on a package manager.

-- 
/Jacob Carlborg