gcc woes

Hi,

after attempting to use precompiled headers toghether with
gcc 4.1.2, I 
figured I might as well post my "findings" here.

Pre-4.2.0 gcc can't handle pch and anonymous namespaces in
headers, ref: 
htt
p://gcc.gnu.org/bugzilla/show_bug.cgi?id=29085

This makes it virtually impossible to use pch toghether with
e.g. 
Boost.Lambda, Boost.Parameter to build programs with
multiple translation 
units.

Perhaps a note of this could be added to the BBv2 pch docs?

Also - is it possible to disable pch using conditional
requirements, making 
the pch rule effectively returning a "null"
target?

/ Johan


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

On Friday 05 October 2007 10:25:03 Johan Nilsson wrote:
> Hi,
> 
> after attempting to use precompiled headers toghether
with gcc 4.1.2, I 
> figured I might as well post my "findings"
here.
> 
> Pre-4.2.0 gcc can't handle pch and anonymous namespaces
in headers, ref: 
> htt
p://gcc.gnu.org/bugzilla/show_bug.cgi?id=29085
> 
> This makes it virtually impossible to use pch toghether
with e.g. 
> Boost.Lambda, Boost.Parameter to build programs with
multiple translation 
> units.
> 
> Perhaps a note of this could be added to the BBv2 pch
docs?

Possibly, thanks for letting know.

> 
> Also - is it possible to disable pch using conditional
requirements, making 
> the pch rule effectively returning a "null"
target?

The <pch>off feature will have that effect.

- Volodya
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

Vladimir Prus wrote:
> On Friday 05 October 2007 10:25:03 Johan Nilsson
wrote:
>> Hi,
>>
>> after attempting to use precompiled headers
toghether with gcc
>> 4.1.2, I figured I might as well post my
"findings" here.
>>
>> Pre-4.2.0 gcc can't handle pch and anonymous
namespaces in headers,
>> ref: htt
p://gcc.gnu.org/bugzilla/show_bug.cgi?id=29085
>>
>> This makes it virtually impossible to use pch
toghether with e.g.
>> Boost.Lambda, Boost.Parameter to build programs
with multiple
>> translation units.
>>
>> Perhaps a note of this could be added to the BBv2
pch docs?
>
> Possibly, thanks for letting know.

Also, it seems like the base name of the pch header needs to
be exactly the 
same as the pch target name. Does the provided example (in
the docs) really 
work?

>
>>
>> Also - is it possible to disable pch using
conditional requirements,
>> making the pch rule effectively returning a
"null" target?
>
> The <pch>off feature will have that effect.

Thanks. However, adding <toolset>gcc:<pch>off to
my root project properties 
caused everything to rebuild as /pch-off/ was added to the
target paths. Not 
much to do about it I guess, but annoying nevertheless.

Is there possibly a way to obtain the effect of the imagined
conditional 
requirement
"<toolset>gcc,<toolset-version-below>4.2.0:
<pch>off" without 
resorting to indirect conditional requirements?

One final point: Inside the pch target definition, I also
setup the path to 
the pch header as an <include> requirement as I have
multiple levels of 
source directories within the project. As a result of this,
when turning off 
pch, the source files fails to compile (they no longer find
the actual pch 
header file).

Do you have any suggestions for how to handle the above in a
generic, clean 
way?

/ Johan


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

Ping?

Johan Nilsson wrote:
> Vladimir Prus wrote:
>> On Friday 05 October 2007 10:25:03 Johan Nilsson
wrote:
>>> Hi,
>>> 
>>> after attempting to use precompiled headers
toghether with gcc
>>> 4.1.2, I figured I might as well post my
"findings" here.
>>> 
>>> Pre-4.2.0 gcc can't handle pch and anonymous
namespaces in headers,
>>> ref: htt
p://gcc.gnu.org/bugzilla/show_bug.cgi?id=29085
>>> 
>>> This makes it virtually impossible to use pch
toghether with e.g.
>>> Boost.Lambda, Boost.Parameter to build programs
with multiple
>>> translation units.
>>> 
>>> Perhaps a note of this could be added to the
BBv2 pch docs?
>> 
>> Possibly, thanks for letting know.
> 
> Also, it seems like the base name of the pch header
needs to be
> exactly the 
> same as the pch target name. Does the provided example
(in the docs)
> really 
> work?
> 
>> 
>>> 
>>> Also - is it possible to disable pch using
conditional requirements,
>>> making the pch rule effectively returning a
"null" target?
>> 
>> The <pch>off feature will have that effect.
> 
> Thanks. However, adding
<toolset>gcc:<pch>off to my root project
> properties 
> caused everything to rebuild as /pch-off/ was added to
the target
> paths. Not 
> much to do about it I guess, but annoying
nevertheless.
> 
> Is there possibly a way to obtain the effect of the
imagined
> conditional requirement
>
"<toolset>gcc,<toolset-version-below>4.2.0:
<pch>off" without 
> resorting to indirect conditional requirements?
> 
> One final point: Inside the pch target definition, I
also setup the
> path to 
> the pch header as an <include> requirement as I
have multiple levels
> of 
> source directories within the project. As a result of
this, when
> turning off 
> pch, the source files fails to compile (they no longer
find the
> actual pch 
> header file).
> 
> Do you have any suggestions for how to handle the above
in a generic,
> clean 
> way?
> 
> / Johan
> 
> 
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost-build 

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

Johan Nilsson wrote:

> Vladimir Prus wrote:
>> On Friday 05 October 2007 10:25:03 Johan Nilsson
wrote:
>>> Hi,
>>>
>>> after attempting to use precompiled headers
toghether with gcc
>>> 4.1.2, I figured I might as well post my
"findings" here.
>>>
>>> Pre-4.2.0 gcc can't handle pch and anonymous
namespaces in headers,
>>> ref: htt
p://gcc.gnu.org/bugzilla/show_bug.cgi?id=29085
>>>
>>> This makes it virtually impossible to use pch
toghether with e.g.
>>> Boost.Lambda, Boost.Parameter to build programs
with multiple
>>> translation units.
>>>
>>> Perhaps a note of this could be added to the
BBv2 pch docs?
>>
>> Possibly, thanks for letting know.
> 
> Also, it seems like the base name of the pch header
needs to be exactly
> the same as the pch target name. Does the provided
example (in the docs)
> really work?

I believe it was tested on msvc when added; I should be able
to test
myself today or tomorrow.
 
>>> Also - is it possible to disable pch using
conditional requirements,
>>> making the pch rule effectively returning a
"null" target?
>>
>> The <pch>off feature will have that effect.
> 
> Thanks. However, adding
<toolset>gcc:<pch>off to my root project
> properties caused everything to rebuild as /pch-off/
was added to the
> target paths. Not much to do about it I guess, but
annoying nevertheless.

Well, I guess that, assuming compiler has no bugs, PCH
should not change
the generated code, and therefore need not be represented in
path.
Does changing 

# control precompiled header (PCH) generation
feature.feature pch :
    on
    off
  : propagated    
  ;

to

# control precompiled header (PCH) generation
feature.feature pch :
    on
    off
  : propagated incidental
  ;

in pch.jam fixes this annoyance?
 
> Is there possibly a way to obtain the effect of the
imagined conditional
> requirement
"<toolset>gcc,<toolset-version-below>4.2.0:
<pch>off" without
> resorting to indirect conditional requirements?

No.

> One final point: Inside the pch target definition, I
also setup the path
> to the pch header as an <include> requirement as
I have multiple levels of
> source directories within the project. As a result of
this, when turning
> off pch, the source files fails to compile (they no
longer find the actual
> pch header file).
> 
> Do you have any suggestions for how to handle the above
in a generic,
> clean way?

Add the same include as usage requirement on the target?

- Volodya


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

Vladimir Prus wrote:
> Johan Nilsson wrote:
>
>> Vladimir Prus wrote:
>>> On Friday 05 October 2007 10:25:03 Johan
Nilsson wrote:

[snip]

>>
>> Also, it seems like the base name of the pch header
needs to be
>> exactly the same as the pch target name. Does the
provided example
>> (in the docs) really work?
>
> I believe it was tested on msvc when added; I should be
able to test
> myself today or tomorrow.

Thanks. Let us know how it goes.

>
>>>> Also - is it possible to disable pch using
conditional
>>>> requirements, making the pch rule
effectively returning a "null"
>>>> target?
>>>
>>> The <pch>off feature will have that
effect.
>>
>> Thanks. However, adding
<toolset>gcc:<pch>off to my root project
>> properties caused everything to rebuild as
/pch-off/ was added to the
>> target paths. Not much to do about it I guess, but
annoying
>> nevertheless.
>
> Well, I guess that, assuming compiler has no bugs, PCH
should not
> change
> the generated code, and therefore need not be
represented in path.
> Does changing
>
> # control precompiled header (PCH) generation
> feature.feature pch :
>    on
>    off
>  : propagated
>  ;
>
> to
>
> # control precompiled header (PCH) generation
> feature.feature pch :
>    on
>    off
>  : propagated incidental
>  ;
>
> in pch.jam fixes this annoyance?

I guess it fixes the immediate problem, but I can't tell how
safe it is. 
Need to think about it.

What is the general path generation policy; does it add
default options to 
path when they are explicitly requested - perhaps the order
of "off" and 
"on" could simply be reversed?

>
>> Is there possibly a way to obtain the effect of the
imagined
>> conditional requirement
>>
"<toolset>gcc,<toolset-version-below>4.2.0:
<pch>off" without
>> resorting to indirect conditional requirements?
>
> No.

Thought so (leading question). This could be a generally
useful addition to 
Boost.Build.

>
>> One final point: Inside the pch target definition,
I also setup the
>> path to the pch header as an <include>
requirement as I have
>> multiple levels of source directories within the
project. As a
>> result of this, when turning off pch, the source
files fails to
>> compile (they no longer find the actual pch header
file).
>>
>> Do you have any suggestions for how to handle the
above in a generic,
>> clean way?
>
> Add the same include as usage requirement on the
target?

If pch is off the usage requirement will not be propagated,
but the first 
line in the source file(s) will still include the statement
(e.g.):

#include "mypch.h"

This leads to compilation errors.

/ Johan


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

Johan Nilsson wrote:

> Vladimir Prus wrote:
>> Johan Nilsson wrote:
>>
>>> Vladimir Prus wrote:
>>>> On Friday 05 October 2007 10:25:03 Johan
Nilsson wrote:
> 
> [snip]
> 
>>>
>>> Also, it seems like the base name of the pch
header needs to be
>>> exactly the same as the pch target name. Does
the provided example
>>> (in the docs) really work?
>>
>> I believe it was tested on msvc when added; I
should be able to test
>> myself today or tomorrow.
> 
> Thanks. Let us know how it goes.

The example/pch builds fine for me, on msvc. Do you have a
specific
error with that?

>>>>> Also - is it possible to disable pch
using conditional
>>>>> requirements, making the pch rule
effectively returning a "null"
>>>>> target?
>>>>
>>>> The <pch>off feature will have that
effect.
>>>
>>> Thanks. However, adding
<toolset>gcc:<pch>off to my root project
>>> properties caused everything to rebuild as
/pch-off/ was added to the
>>> target paths. Not much to do about it I guess,
but annoying
>>> nevertheless.
>>
>> Well, I guess that, assuming compiler has no bugs,
PCH should not
>> change
>> the generated code, and therefore need not be
represented in path.
>> Does changing
>>
>> # control precompiled header (PCH) generation
>> feature.feature pch :
>>    on
>>    off
>>  : propagated
>>  ;
>>
>> to
>>
>> # control precompiled header (PCH) generation
>> feature.feature pch :
>>    on
>>    off
>>  : propagated incidental
>>  ;
>>
>> in pch.jam fixes this annoyance?
> 
> I guess it fixes the immediate problem, but I can't
tell how safe it is.
> Need to think about it.
> 
> What is the general path generation policy; does it add
default options to
> path when they are explicitly requested - perhaps the
order of "off" and
> "on" could simply be reversed?

The default value of a feature is never shown in path, no
matter how requested,
unless the feature is marked 'symmetric'. Switching the
order won't quite help
-- you'll either get pch-off or pch-on in path, depending on
how you compile.

>>> Is there possibly a way to obtain the effect of
the imagined
>>> conditional requirement
>>>
"<toolset>gcc,<toolset-version-below>4.2.0:
<pch>off" without
>>> resorting to indirect conditional
requirements?
>>
>> No.
> 
> Thought so (leading question). This could be a
generally useful addition
> to Boost.Build.

Probably; I don't know what a good syntax would be,
however.

>>> One final point: Inside the pch target
definition, I also setup the
>>> path to the pch header as an <include>
requirement as I have
>>> multiple levels of source directories within
the project. As a
>>> result of this, when turning off pch, the
source files fails to
>>> compile (they no longer find the actual pch
header file).
>>>
>>> Do you have any suggestions for how to handle
the above in a generic,
>>> clean way?
>>
>> Add the same include as usage requirement on the
target?
> 
> If pch is off the usage requirement will not be
propagated, but the first
> line in the source file(s) will still include the
statement (e.g.):
> 
> #include "mypch.h"
> 
> This leads to compilation errors.

Strange. When I modify the example/pch project as follows:

ghostwind:~/Work/Boost/boost-svn/tools/build/v2/example/pc
h$ svn diff
Index: Jamroot
============================================================
=======
--- Jamroot     (revision 39621)
+++ Jamroot     (working copy)
 -13,6
+13,9 
     include/pch.hpp
   : # requirements
     <include>include
+  : # default-build
+  : # usage requirements
+    <include>foobar
   ;
 explicit pch ;


And run "bjam -n pch=off" (on gcc/linux), I do see
-Ifoobar on the
command line. Do you have a small example where this is not
working?

- Volodya


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

Vladimir Prus wrote:
> Johan Nilsson wrote:
>
>> Vladimir Prus wrote:
>>> Johan Nilsson wrote:
>>>
>>>> Vladimir Prus wrote:
>>>>> On Friday 05 October 2007 10:25:03
Johan Nilsson wrote:
>>
>> [snip]
>>
>>>>
>>>> Also, it seems like the base name of the
pch header needs to be
>>>> exactly the same as the pch target name.
Does the provided example
>>>> (in the docs) really work?
>>>
>>> I believe it was tested on msvc when added; I
should be able to test
>>> myself today or tomorrow.
>>
>> Thanks. Let us know how it goes.
>
> The example/pch builds fine for me, on msvc. Do you
have a specific
> error with that?

The example/pch builds fine for me too, on msvc and gcc.

What I referred to was the example in the docs, which will
not work with gcc 
because of the constraints on the target / pch header file
naming. Try 
modifying example/pch to specify a different name for the
pch target:

---
import pch ;

cpp-pch pch2
  : # sources
    include/pch.hpp
  : # requirements
    <include>include
  ;
explicit pch2 ;

# exe 
############################################################
##############

exe hello_world
  : # sources
    pch2
    source/hello_world.cpp
  : # requirements
    <include>include
  : # default build
  : # usage requirements
  ;
---

Running bjam under gcc now outputs:

---
error: in Jamfile</path/to/bbv2/example/pch>: pch
target name `pch2' should 
be the same as the base name of header file
`include/pch.hpp'
---

I don't know if this is an issue with the gcc compiler
itself, or with the 
gcc toolset pch support implementation.

[snip]

>
> The default value of a feature is never shown in path,
no matter how
> requested, unless the feature is marked 'symmetric'.
Switching the
> order won't quite help -- you'll either get pch-off or
pch-on in
> path, depending on how you compile.

Yes. I just figured that the better part of the users are
not using pch, 
therefore building with pch off (even explicitly) should not
add "pch-off" 
to the build path.

>>
>> If pch is off the usage requirement will not be
propagated, but the
>> first line in the source file(s) will still include
the statement
>> (e.g.):
>>
>> #include "mypch.h"
>>
>> This leads to compilation errors.
>

[snip some code adding <include> to
usage-requirements]

>
> And run "bjam -n pch=off" (on gcc/linux), I
do see -Ifoobar on the
> command line. Do you have a small example where this is
not
> working?

I'll have to get back to that. IIRC I only saw the problem
when the target 
using pch was a subproject, and I invoked the build from the
project root 
directory.

/ Johan


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

Johan Nilsson wrote:

[snip]

> Running bjam under gcc now outputs:
> 
> ---
> error: in Jamfile</path/to/bbv2/example/pch>: pch
target name `pch2' should 
> be the same as the base name of header file
`include/pch.hpp'
> ---
> 
> I don't know if this is an issue with the gcc compiler
itself, or with the 
> gcc toolset pch support implementation.

The former

HTH

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

Ilya Sokolov wrote:
> Johan Nilsson wrote:
>
> [snip]
>
>> Running bjam under gcc now outputs:
>>
>> ---
>> error: in Jamfile</path/to/bbv2/example/pch>:
pch target name `pch2'
>> should be the same as the base name of header file
`include/pch.hpp'
>> ---
>>
>> I don't know if this is an issue with the gcc
compiler itself, or
>> with the gcc toolset pch support implementation.
>
> The former

Ok. Whatever the reason is, a note in the pch description in
the docs would 
be helpful (and an example that works under gcc as well).

/ Johan


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build