From: Andrey Melnikov (melnikov_at_[hidden])
Date: 2005-07-07 09:25:38
David Abrahams wrote:
> Andrey Melnikov <melnikov_at_[hidden]> writes:
>>>This PCH thing becomes a common request. Recall that msvc has both "automatic"
>>>pch mode, that requires, IIRC, a single switch, and "manual" mode, that
>>>requires creating PCH once, and then using it from other targets.
>>I named "automatic" mode "hdrstop", because it requires #pragma hdrstop.
>> Borland compilers support #pragma hdrstop too, and Jamfile with
>><pch>hdrstop would be portable at least between intel-win, msvc and borland.
> I don't like it; one of the things we're trying to do with Boost.Build
> is to abstract away niggling little compiler dependencies like the
> syntax used to implement automatic precompiled headers. I betcha
> there are some linux compilers that have a similar functionality with
> a different syntax.
I didn't mean that Boost.Build's support for portable precompiled
headers must be portable across all compilers supporting precompilation.
I understand that there are compilers with completely incompatible
precompiled headers syntax. Trying to support precompiled headers in
portable projects like Boost is almost impossible.
But Boost.Build isn't just for Boost. It has a lot of advantages over
other build systems. People may use it for projects targeting single OS,
single compiler and single CPU platform. I think that Boost.Build
shouldn't limit users in any way, and bb toolset should support any
option corresponding compiler supports.
I understand that allowing people to specify non-portable features may
lead to big number of non-portable Jamfiles and losing the reputation of
cross-platform build system.
BB already has a lot of compiler-specific features, and I don't see any
other arguments against adding compiler-specific precompiled headers. If
precompiled headers aren't portable - don't use them in portable
projects. But if portability isn't a requirement - why not?
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