On Monday, 29 February 2016 at 20:00:48 UTC, Sebastien Alaiwan
wrote:
On Monday, 29 February 2016 at 19:23:08 UTC, Jonathan M Davis
wrote:
My solution would be to never have the same file be part of
multiple projects. Share code using libraries rather than just
sharing the files. Then modules won't be changing where they
are in a project or anything like that. The shared code goes
into a library, and whichever projects need it link against
that library. You get better modularization and encapsulation
that way and completely avoid the problem that you're having.
Thanks for your answer ; from what I understand, you're
basically telling me to only import binary/precompiled
libraries, right?
Although I had to admit I had never considered this solution,
never have the same file be part of multiple projects seems
extremely restrictive to me.
How is it going to work if I want to share heavily templated
code, like a container library?
Phobos is a library, and templates work with it just fine. You're
still importing the .d files. They're just compiled in as part of
the library that you link against rather than compiled as part of
your project - e.g. pretty much every D program is linked against
libphobos, and none of them compile in modules like std.stdio.
They just import them. They were compiled as part of libphobos
are aside from templates are not compiled as part of your
program, just linked.
As for templated code, the templates are generated when your code
is built, so they're not really linked in in the normal sense,
but those modules are still part of the library and not part of
your code, so you'd never do something like add
std/algorithm/searching.d to the list of files that you're
compiling. You'd just import it.
If someone wants to hide code, then they'd use .di files and give
you those to link against, in which case non-templated code could
be hidden, but templated code would still be in those files,
because the compiler has to see their source when they're used.
And most folks will likely just use .d files, since it's simpler
and allows stuff like CTFE and inlining to work.
Most of the projects on code.dlang.org are libraries, and you're
using dub, they're easy to pull in and link against. You can do
the same with your code.
- Jonathan M Davis