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
