On Fri, May 23, 2014 at 1:03 AM, Eric Voskuil <eric@???> wrote:
> There is a reason for the export macros to be uniquely-named per project.
> Each project needs to define a symbol to differentiate between dll export
> and static. Each dependent project needs to define a symbol to differentiate
> between dll import and static. So there are three contexts since import and
> export static are the same. If two projects utilize the same symbols for
> declaring exports it becomes hard for dependent projects to treat them
> independently. While it may be common for a project to link all dependent
> projects in the same manner it's certainly not a requirement and therefore
> would be bad practive to couple these symbols across projects.

Ah, that makes perfect sense. Since these are, in fact, separate
libraries, using the same symbol across library boundaries could lead
to problems if the libraries are compiled with different flags. The
only way to make the defines match the compilation mode on a
project-by-project basis is to use a separate define per project.

Under that constraint, I suppose "BCW" really is the shortest
reasonable abbreviation of "libbitcoin-wallet".

Either that, or we unite the different projects in a single source
repo with a single build system, and just have separate --enable-foo
options to turn each individual library on and off. In Visual Studio
land, that would be done as a single solution file with a project file
per lib. A single "make" invocation would produce
libbitcoin.{so,a,pc}, libbitcoin-wallet.{so,a,pc},
libbitcoin-server.{so,a,pc}, and so forth.

Actually, this would be kinda nice. It's already hard enough to keep
the various repos in sync, and we haven't even divided them down the
granularity we are hoping for.

-William