From: Vladimir Prus (ghost_at_[hidden])
Date: 2005-08-16 01:01:12
On Friday 12 August 2005 22:43, Andrey Melnikov wrote:
> > project
> > : requirements
> > : <library>/some_library_that_takes_long_time_to_build ;
> > lib runtime1 : main1.cpp common ;
> > lib runtime2 : main2.cpp common ;
> > lib common : common.cpp : <link>static ;
> > So, I have some library "common" that I made static to avoid the trouble
> > of installing yet another library. However, that library gets project
> > requirements too, and so tries to build
> > some_library_that_takes_long_time_to_build with <link>static. Now, I
> > don't want that at all, not to mention that static library can't be
> > linked with another static library.
> Do you mean that you want to combine static common.lib with dynamic
> /some_library_that_takes_long_time_to_build ?
No, I don't want to combine common.lib
with /some_library_that_takes_long_time_build_build at all.
> > However, there's no easy way to avoid this behaviour. I was thinking
> > about this:
> > lib common : common.cpp : local:<link>static ;
> > to make requirement non-propagated, or about
> I think a better idea is to make <link> always non-propagated. What are
> the use cases for which you'd like <link> to propagate?
Typically, you use <link>static to avoid problems with DLL installation. In
that case, it makes perfect sense to build dependencies with <link>static,
In my current case, I want to avoid installing just one lib, so I don't want
to propagate <link>static, but it's my specific case that I did not encounter
> > lib common : common.cpp : <no-project-requirements> ;
> > to avoid inheriting project requirements or about
> > lib common : common.cpp
> > : -<library>/some_library_that_takes_long_time_to_build
> > ;
> > to selectively disable some of the project requirements.
> This is too complicated. I think it would be better to split a project
> into several subprojects to selectively disable the requirements.
> For small projects this can be complicated, so I'd like an ability to
> have multiple projects in a jamfile.
That can be quite complicated. Some parts of V2 assume that Jamfile
corresponds to a single project, and uses Jamfile module to identify the
> > The latter two can be useful for another use case:
> > project : requirements <library>util ;
> > exe a1 .....
> > exe a2 .....
> > lib util : util.cpp ;
> > Now, this does not work, because util tries to build itself recursively.
> It would be better to write something like this:
> project ;
> exe a1 ..... util ... ;
> exe a2 ..... util ... ;
> lib util : util.cpp ;
> If you have 100 executables (which is typical if you have each test
> isolated in its own binary) it's not a good idea to specify util
> dependency 100 times.
> So in this case create a separate project for util:
> project : <requirement>util-proj/util ;
> exe a1 ..... ;
> exe a2 ..... ;
> project util-proj ;
> lib util : util.cpp ;
Generally, I like the idea. Except for techical difficulty I mention above,
there's another question -- if this Jamfile has a child, which project's
requirements are inherited? The first one? Or user should explicitly specify
-- Vladimir Prus http://vladimir_prus.blogspot.com Boost.Build V2: http://boost.org/boost-build2
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk