Boost logo

Boost-Build :

From: Vladimir Prus (ghost_at_[hidden])
Date: 2005-06-28 01:03:33

On Tuesday 28 June 2005 00:01, hf_pabst wrote:
> > Yes, and it's pretty easy for a DLL author to set up. I am not
> > convinced that the build system should be doing this automatically.
> > There are, after all, plugin DLLs that hardly export anything (like
> > Python extension modules).
> Thats right. It's nice to have an out-of-the-box working code -- with
> any build system. On the other side each build system can support
> some defines.
> I know the common solution with a top-level header, but this seems a
> nice place to discuss this.

What do you mean by 'top-level header'. I believe that each dynamic library
should have its own symbol controlling import/export, and you can't have a
single header for several dynamic libraries, no?

> Boost.Build V2 is a nice build system and
> it's not only for use in a single direction -- it can also influence
> coding standards. Each boost library has this ability (for me).
> Many windows users doesn't understand dynamic link libraries (i'm
> teaching something linke this for many beginner). We can simply
> establish (and document) a standard.

I would say that even if the number of regular dynamic libraries and plugins
relate at 50/50, then it would still be nice to automatically define

> Unique project names make sense
> for unique defines -- the code will then reflect the name of the
> project...
> class LIBMYPROJECT anything {
> ...
> };

Did you miss my argument? With this design, this definition can't be used in a
project that's not built with Boost.Build, which I find a serious problem.
With autodefined MYPROJECT_SOURCE, this problem is gone, at the code of
additional (not very complex) macro logic. OTOH, is some macro logic should
be manually added, maybe adding explicit MYPROJECT_SOURCE defines is not
hard, either.

- Volodya

Vladimir Prus
Boost.Build V2:

Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at