From: ajp_m (a.maclean_at_[hidden])
Date: 2002-02-19 17:49:05
I am inclined to agree with Bill in that, given that this is really
a library build issue for most compilers, the best solution at
present would be to note the requirements in the documentation.
However this only partially addresses Brian's comments regarding
early error detection. His idea of a predefined macro is
interesting. Has anyone tried this?
At present the code works well and it is so good to have a robust
(NATIVE!!!)C++ implementation of threads! No more wrappers!
As a side issue, it is interesting to note that the IDE (MSVC++6SP5)
will actually warn you if a DLL is not needed when you compile a
--- In boost_at_y..., "bill_kempf" <williamkempf_at_h...> wrote:
> --- In boost_at_y..., Beman Dawes <bdawes_at_a...> wrote:
> > At 11:29 AM 2/19/2002, bill_kempf wrote:
> > >> Might be worth a new predefined macro. _DLL_TARGET or
> > >>
> > >> Anything a compiler implementor can do that allows better
> > >detection
> > >> is a win for users, and cuts support costs too.
> > >
> > >The only problem is that, as someone else pointed out, this is
> > >linker concept not a compiler concept. I'm not sure the
> > >can determine that the target will be a DLL.
> > At least when using the IDE, the distinction seems somewhat
> artificial. The
> > IDE knows, so can pass the information on to whichever component
> needs it.
> True, though not everyone uses an IDE, so even if we got all the
> Win32 IDEs to do this it would be only a partial solution.
> > Likewise, building with Jam there is knowledge at a higher level
> > the target is, so information could be passed to a compiler.
> If they use Jam I'd expect they'd use the provided Jamfile(s) so
> there'd be no need for detection. The problem comes up frequently
> because people, for what ever reason, build the libraries with
> own build system instead of employing the Jam build system that's
> At this point I think the only "solution" is to complete the build
> specification documentation that's on my todo list.
> Bill Kempf
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk