Re: [jamboost] Re: Extended lib rule

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 
something. 

> 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
http://vladimir_prus.blogspot.com
Boost.Build V2: http://boost.org/boost-build2