|
Boost : |
Subject: Re: [boost] Link dependencies (was: [mpl] [build] [testing] Mergepullrequests)
From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2014-12-03 15:30:40
On Wed, Dec 3, 2014 at 2:07 PM, Andrey Semashev <andrey.semashev_at_[hidden]>
wrote:
> On Wed, Dec 3, 2014 at 2:36 PM, Peter Dimov <lists_at_[hidden]> wrote:
> > Andrey Semashev wrote:
> >>
> >> On Wednesday 03 December 2014 12:55:35 Peter Dimov wrote:
> >>
> > #if 0
> > // inform boost.build of hidden dependencies
> > # include "boost/mpl/aux_/preprocessed/bcc/_all_.hpp"
> > # include "boost/mpl/aux_/preprocessed/bcc_pre90/_all_.hpp"
> > ...
> > #endif
> >
> > and 11 copies of the same _all_.hpp header that consists of 47 includes
> and
> > will never change.
>
> I still don't like the idea that we have to mangle the code to guide
> the build system. And I don't want to set a precedent in MPL as I know
> there are many more places where preprocessor is used to include
> headers.
> Ugly and error prone? No more than what's already there, I'd say.
>
> IMHO, either Boost.Build has to parse the code properly,
Is there a build system out there that correctly handles the extent of MPLs
preprocessor driven header inclusion? I'm asking so that we can ascertain
how it could be done.
> or it should
> be guided by its own config files, i.e. Jamfiles.
Don't know what you mean by that. Can you elaborate?
> Or it could just
> always link all headers.
>
It's possible and easy to change the MPL build files to enumerate header
dependencies (it can even be done automatically with globs) with the
"dependency" feature. Sorry if I haven't followed this discussion.. But can
you elaborate what the use cases are?
-- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk