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