Re: [boost] Link dependencies (was: [mpl] [build] [testing] Mergepullrequests)

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