Re: [UI] system libraries

From: Markus Schöpflin (markus.schoepflin_at_[hidden])
Date: 2002-11-26 09:54:36

Vladimir Prus wrote:
> Markus Schöpflin wrote:
> 
>>>2. It differs from using library targets, for no good
>>> reason. Moreover, consider that on Windows, a library
>>> called 'expat' must be built by Boost.Build, so we
>>> have to write
>>>
>>> exe main : main.cpp : <library>expat
>>>
>>> But on Linux this library is already awailable, so we better
>>> use
>>>
>>> exe main : main.cpp : <find-library>expat
>>>
>>> This difference is messy.
>>
>>
>>I don't follow you here. Why do have to build 'expat' with boost build 
>>on windows? Don't they have a Makefile for this that we better use?
> 
> I'd rather not mix two build systems together. But it's
> my opinion only.

As a side not, did you ever consider integrating external builds via 
the traditional configure && make && make install tool chain into 
boost build?

>>>3. I remember that Markus requested that "find-library" had
>>> static and dynamic version (i.e "link this system library
>>> statically"). But
>>>
>>> <find-library-static>zlib
>>
>>
>>That's what I currently have in my local version of V1.
>>
>>
>>
>>> is just too long. An further, if 10 applications use zlib,
>>> do they all have to specify it?
>>
>>
>>I would say yes. They should specify it.
> 
> As I understood you, the linking kind is determined per library basis. I.e
> you either link zlib statically in all places, or link it dynamically. Then
> specifying this information in all places is redundant, isn't it?

Currently I don't have any use for specifying it individually for each 
target, yes. But I can imagine that this could happen.

>>>So, I propose to
>>>
>>>1. Kick "find-library". Introduce new "system-lib" target type.
>>> For example:
>>>
>>> system-lib zlib ;
>>
>>Why would you need this declaration? To tag on build specifiactions?
> 
> So that we know how to interpret
> 
> <library>zlib
> 
> It's hard to distinguish between using of file called "zlib" and
> system library "zlib" otherwise.

Aha, ok.

>>> exe a : a.cpp : <library>zlib ;
>>>
>>> It's possible to specify static linking
>>>
>>> system-lib zlib : <shared>false ;
>>
>>But this implies that all exe targets in a single Jamfile link to the 
>>zlib statically, doesn't it? Not so good, IMO.
> 
> Yes, it implies. On the other hand, you can leave
> 
> system-lib zlib ;
> 
> and then use
> 
> exe a : a.cpp : <library>zlib/<shared>false ;
> 
> (Not sure this will work now, but that's easy to fix).

This would be ok I think. Specify a default and then override it on a 
per target basis.

>>Or would it be possible to say, for example:
>>
>>system-lib zlib-dynamic : <shared>true <real-name>zlib ;
>>system-lib zlib-static : <shared>false <real-name> zlib ;
> 
> Yes, that's an option. Or we could allow "default properties"
> 
> system-lib zlib : : default-properties <shared>false ;
> 
> By default, this will use static linking, but you can override
> it as shown above.

Makes sense.

>>>2. Kick <library-file> as well. Allow to specify file name as value
>>> of <library> features.
>>>
>>> exe a : a.cpp : <library>zlib <library>helper.a ;
>>
>>How do you distinguish between file names and library names? Via 
>>presence of system-lib declaration?
> 
> Yep. In fact, that's how it works for sources
> 
> my_facny_rule a : b ;
> 
> Here, if there's main target "b", it will be used. Otherwise,
> it's assumed that "b" refers to a file. It's documented in
> 
> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/boost/boost/tools/build/boost_build_v2.html?rev=HEAD&content-type=text/html#target_id
> 
> 
>>Hmm, as long as you don't loose the flexibility to specify things 
>>individually for each target, I would agree.
> 
> 
> Yes, I have another (personal) request for the same ("flexibility to specify
> things individually"), so I'll do my best to keep it.
> 

That would be great.

Markus