Date: 2001-08-01 09:25:19
From an off line discussion between myself and Dave Abrahams.
----- Original Message -----
From: "William Kempf" <williamkempf_at_[hidden]>
> > > 1) I'm not sure how to build a DLL for Win32 but a static
> > > other platforms.
> >if $(NT)
> > dll boost_threads : ... ;
> > lib boost_threads : .... ;
> Is it $(NT) for all Win32 platforms?
I think so. David T, do you have this info?
> This will work, though it's a little inconvenient to have to
> "...." stuff twice. Any way, thanks for this.
No biggie, just put the .... stuff in variables:
boost_threads_sources = a.cpp b.cpp c.cpp ;
dll boost_threads : $(boost_threads_sources) ;
> >The PATH is set up automatically when you run a dependent project
> >the build system, but yes, I need to document it.
> Run through the build system? Didn't realize you could do that, and
> really see why you'd want to.
Because much of the information about what dynamic libs you depend on
already available there. If I'm building an executable (or regression
which depends on Boost.Regex, Boost.Python, or Boost.Threads I can
specify <lib>path-to-dll-target and when the exe needs to run, the
environment is all set up for me. It also works recursively, so if an
depends on a DLL which depends on another DLL, the exe gets
needs to run.
> It'd work nice for regression testing, but
> it's not the answer that users are going to need.
It's also what developers need. I don't know what users need, and
primarily trying to serve them with the build system. I'm trying to
Beman with some of that, but I am not an expert on some of the
> >As far as installation is
> >concerned, every platform has its own idea(s) of what installation
> >I haven't tried to address it. I don't know where DLLs should be
> I don't think you can hard code such information. For Windows
> simply having an environment/script variable that specifies a target
> location would work nicely. Other platforms may have more
> requirements, though, so I realize this isn't a simple concept.
> I hoped Jam/Boost.Build had addressed it for me ;).
> > > 3) Related to 2, but a bigger issue, how can we install DLLs
> > > variant (debug, release, etc.)? I'd expect an executable built
> > > link with a debug DLL and an executable built in release to
> > > release DLL.
> >That part just works.
> I don't mean static link to the import lib, I mean dynamically link
> time. This doesn't "just happen", unless you're referring to
> through the build system, which isn't going to be what users want
> > > Generally this is handled on the Win32 platform by giving each
> > > variant DLL a different name, but Boost.Build gives each DLL
> > > relying on directory locations to differentiate them.
> >Yeah, that needs to be worked on. Python has some similar issues,
> >debug versions of extension modules need a "_d" extension.
> > > Any thoughts or help on any of these issues?
> >If we can decide what /should/ happen, I can help make it happen.
> >universal is the different naming convention for different build
> It's very universal if you mean "does everyone use this
> not at all universal if you mean how the variants are named. In
> words, each library vendor uses a different naming scheme based on
> variants they provide. Often the DLLs are linked via #pragmas in
> files to hide the details about which DLL to link to from the
> only need to supply the proper macro definitions at compile time to
> which variants they are using. As far as I'm concerned the Win32
> variants can just pick a naming convention and enforce it for all
> libraries. What others do does not have to have an effect on what
> Now whether this applies to other platforms or not...
I would appreciate it if you'd raise this discussion on the list so
get feedback about other platforms and peoples' preferences. If you
collect the requirements, I'm sure I can implement them.
--- End Original Message ---
So, what would be needed to enable Boost.Build to install shared
libraries on a system? Or should we even do this?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk