Problem with PCH

  A recent introduction of SORT in sequence.unique rule is
causing PCH
generation to fail sometimes by attempting to compile the
header file
instead of the source file. This happens in one of my
projects, but I
have been unable to create a reproducible test case.

  The problem actually exists and manifests itself when the
source
file object identifier is 'less' than the header's
identifier:

  lib a : [ pch apch : [ cast _ pcheader : a.h ] a.cpp ] ;

  In my case, after the targets have been created,
a.h=object(file-target)2238, a.cpp=object(file-target)400.  The
sequence expected by pch-generator is a.h a.cpp. When
sequence.unique
rule is invoked from targets.jam:1187, it sorts the original
sequence
[ object(file-target)2238 object(file-target)400 ]
into [
object(file-target)400 object(file-target)2238 ],
thus switching
places of a.h and a.cpp. pch-generator then incorrectly
creates
<pch-source>a.h and <pch-header>a.cpp features,
which causes the
system to attempt to compile the header file.

  Attached is patch to pch.jam that checks the types of
arguments to
make sure that the correct ones are used for source and
header.
-- 
Bojan Resnik
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

On Friday 22 September 2006 16:52, Bojan Resnik wrote:
>   A recent introduction of SORT in sequence.unique rule
is causing PCH
> generation to fail sometimes by attempting to compile
the header file
> instead of the source file. This happens in one of my
projects, but I
> have been unable to create a reproducible test case.

I'm a bit unsure about sequence.unique changing the order
of list elements, as 
there are cases where order matters. 

>   The problem actually exists and manifests itself when
the source
> file object identifier is 'less' than the header's
identifier:
>
>   lib a : [ pch apch : [ cast _ pcheader : a.h ] a.cpp
] ;
>
>   In my case, after the targets have been created,
> a.h=object(file-target)2238,
a.cpp=object(file-target)400.  The
> sequence expected by pch-generator is a.h a.cpp. When
sequence.unique
> rule is invoked from targets.jam:1187, it sorts the
original sequence
> [ object(file-target)2238
object(file-target)400 ] into [
> object(file-target)400 object(file-target)2238 ],
thus switching
> places of a.h and a.cpp. pch-generator then incorrectly
creates
> <pch-source>a.h and <pch-header>a.cpp
features, which causes the
> system to attempt to compile the header file.
>
>   Attached is patch to pch.jam that checks the types of
arguments to
> make sure that the correct ones are used for source and
header.

And what if not? 
+        if [ $(sources[2]).type ] = PCHEADER
+        {
+            cpp = $(sources[1]) ;
+            h   = $(sources[2]) ;
+        }

won't assign anything to 'cpp' and 'h' is the order is
wrong, right? So PCH 
won't work?

- Volodya

-- 
Vladimir Prus
http://vladimir_pru
s.blogspot.com
Boost.Build V2: http://boost.org/boost-
build2
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

My apologies to Vladimir, I accidentally sent this mail to
his private address:

> >   A recent introduction of SORT in sequence.unique
rule is causing PCH
> > generation to fail sometimes by attempting to
compile the header file
> > instead of the source file. This happens in one of
my projects, but I
> > have been unable to create a reproducible test
case.
>
> I'm a bit unsure about sequence.unique changing the
order of list elements, as
> there are cases where order matters.

 Me too, but this problem with pch could happen even if the
order was
preserved in sequence.unique. The user could simply use
    lib a : [ pch apch : a.cpp [ cast _ pcheader : a.h ] ] ;
and make the source file first.

> And what if not?
> + if [ $(sources[2]).type ] = PCHEADER
> + {
> + cpp = $(sources[1]) ;
> + h = $(sources[2]) ;
> + }
>
> won't assign anything to 'cpp' and 'h' is the
order is wrong, right? So PCH
> won't work?

 It would, because the two lines before the if are:
+        local cpp = $(sources[2]) ;
+        local h   = $(sources[1]) ;

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

On Sunday 24 September 2006 11:41, Bojan Resnik wrote:

> > I'm a bit unsure about sequence.unique changing
the order of list
> > elements, as there are cases where order matters.
>
>  Me too, but this problem with pch could happen even if
the order was
> preserved in sequence.unique. The user could simply use
>     lib a : [ pch apch : a.cpp [ cast _ pcheader : a.h
] ] ;
> and make the source file first.

True.

> > And what if not?
> > + if [ $(sources[2]).type ] = PCHEADER
> > + {
> > + cpp = $(sources[1]) ;
> > + h = $(sources[2]) ;
> > + }
> >
> > won't assign anything to 'cpp' and 'h' is the
order is wrong, right? So
> > PCH won't work?
>
>  It would, because the two lines before the if are:
> +        local cpp = $(sources[2]) ;
> +        local h   = $(sources[1]) ;

Oops, apparently I can't read patches. Committed, thanks!

I've also committed the attached follow-up patch to clarify
the logic a bit.

Thanks,
Volodya


-- 
Vladimir Prus
http://vladimir_pru
s.blogspot.com
Boost.Build V2: http://boost.org/boost-
build2
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build