Hi William,

Regarding header locations, I like your proposed approach as we move to
refactor and rename the libs, especially since the lib naming convention is
boost-based.

FWIW I don't consider the use of the master header a chage in direction. The
projects have for some time defined a master header for use by dependant
projects. This is good practive as it prevents unnecesary churn in dependant
projects and makes the library easier to work with. Of course the master
header should not be used within the project that exports it. However our
own dependent projects have not been making use of the master headers of
their dependencies (e.g. libwallet->libbitcoin). I think this happened in
libwallet inadvertently as the code was factored out of libbitcoin. So my
changes have been to just make proper use of our master headers.

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.

e

-----Original Message-----
From: Libbitcoin [mailto:libbitcoin-bounces@lists.dyne.org] On Behalf Of
Amir Taaki
Sent: Friday, May 16, 2014 1:30 AM
To: libbitcoin@???
Subject: Re: [Libbitcoin] Coding style - libbitcoin-*

agree agree agree

only thing is maybe we should have bc::wallet bc::client

On 16/05/14 00:47, William Swanson wrote:
> Hello,
> When we were in Toronto, we talked about renaming all our libraries to
> use the libbitcoin-* scheme, like libbitcoin-wallet,
> libbitcoin-client, etc.. Well, I have started working on a
> libbitcoin-client library, and have run into a few questions.
>
> First, where should the headers go? Right now, we have
> /usr/include/bitcoin/*, /usr/include/wallet/*, etc., but this doesn't
> seem right for the new system. Eric has been moving things towards a
> single master header per library, so it's somewhat redundant having
> the library name in the path as well. Perhaps the layout should go
> like this:
>
> /usr/include/bitcoin/client.hpp (master library include)
> /usr/include/bitcoin/wallet.hpp (master library include)
> /usr/include/bitcoin/client/*.hpp (internal headers)
> /usr/include/bitcoin/wallet/*.hpp (internal headers)
>
> The second question is, what should we do with the namespaces? Right
> now, we have libbitcoin::, bc:: (which maps to libbitcoin::),
> libwallet::, and so forth. Maybe we should do what boost does, and
> have bitcoin::wallet, bitcoin::client, and such for the various child
> libraries? Otherwise, we could do the stl thing and just put them all
> in one big namespace.
>
> Finally, what should we do with the dllexport macros? They aren't
> contained in any namespace, and yet we want them to stay short. Right
> now we have BC_API, BCW_API, and so forth, one for each library. Would
> it make sense to have a single BC_API macro, defined in a central
> place, that we use for all libs? Or is the one-macro-per-library thing
> accomplishing something I am not aware of?
>
> Thanks.
>
> -William
> _______________________________________________
> Libbitcoin mailing list
> Libbitcoin@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/libbitcoin
>