Boost.Build - DLLs and Installation

From: williamkempf_at_[hidden]
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 
library for
> >all
> > > other platforms.
> >
> >if $(NT)
> >{
> >     dll boost_threads : ... ;
> >}
> >else
> >{
> >     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 
duplicate the
> "...." 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) ;

etc.

> >The PATH is set up automatically when you run a dependent project 
through
> >the build system, but yes, I need to document it.
>
> Run through the build system? Didn't realize you could do that, and 
don't
> really see why you'd want to.

Because much of the information about what dynamic libs you depend on 
is
already available there. If I'm building an executable (or regression 
test)
which depends on Boost.Regex, Boost.Python, or Boost.Threads I can 
just
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 
exe
depends on a DLL which depends on another DLL, the exe gets 
everything it
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 
wasn't
primarily trying to serve them with the build system. I'm trying to 
help
Beman with some of that, but I am not an expert on some of the 
details.

> >As far as installation is
> >concerned, every platform has its own idea(s) of what installation 
means,
> >so
> >I haven't tried to address it. I don't know where DLLs should be 
put by
> >default.
>
> I don't think you can hard code such information.  For Windows 
platforms
> simply having an environment/script variable that specifies a target
> location would work nicely.  Other platforms may have more 
complicated
> requirements, though, so I realize this isn't a simple concept.  
That's
why
> I hoped Jam/Boost.Build had addressed it for me ;).

Sorry.

> > > 3) Related to 2, but a bigger issue, how can we install DLLs 
for each
> > > variant (debug, release, etc.)?  I'd expect an executable built 
in
debug
> >to
> > > link with a debug DLL and an executable built in release to 
link with
a
> > > release DLL.
> >
> >That part just works.
>
> I don't mean static link to the import lib, I mean dynamically link 
at run
> time.  This doesn't "just happen", unless you're referring to 
running an
app
> through the build system, which isn't going to be what users want 
to do.
>
> > > Generally this is handled on the Win32 platform by giving each
> > > variant DLL a different name, but Boost.Build gives each DLL 
the same
> >name
> > > relying on directory locations to differentiate them.
> >
> >Yeah, that needs to be worked on. Python has some similar issues, 
since
> >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. 
How
> >universal is the different naming convention for different build
variants?
>
> It's very universal if you mean "does everyone use this 
technique".  It's
> not at all universal if you mean how the variants are named.  In 
other
> words, each library vendor uses a different naming scheme based on 
what
> variants they provide.  Often the DLLs are linked via #pragmas in 
the
header
> files to hide the details about which DLL to link to from the 
users.  They
> only need to supply the proper macro definitions at compile time to
indicate
> which variants they are using.  As far as I'm concerned the Win32 
Boost
> variants can just pick a naming convention and enforce it for all 
Boost
> libraries.  What others do does not have to have an effect on what 
we do.
> Now whether this applies to other platforms or not...

I would appreciate it if you'd raise this discussion on the list so 
we can
get feedback about other platforms and peoples' preferences. If you 
can
collect the requirements, I'm sure I can implement them.

-Dave
--- 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?

Bill Kempf