question regarding building with bjam v2

I've checked out the latest version of Boost 1.34 - tagged 
Version_1_34_1_RC3

I've carefully read the Boost Build documentation (very much
improved) and 
attempted to build the serialization library with the
command line executed 
in the directory ../libs/serialization/build:

bjam --toolset=msvc-7.1

I get compilation errors - which I've never seen before. 
The command line 
from file binary_iarchive.obj.rsp for compilation is:

"......libsserializationsrcbinary_iarchive.cpp&qu
ot;
-Fo"......bin.v2libsserializationbuildmsvc-7.1d
ebugthreading-multibinary_iarchive.obj" 
 -TP /Z7 /Od /Ob0 /W3 /GR /MDd /Zc:forScope /Zc:wchar_t /GB
/Op /wd4675 /EHs 
/Gy -c
-DBOOST_ALL_NO_LIB=1
-DBOOST_SERIALIZATION_DYN_LINK=1
"-I......"

Which seems almost OK.  It looks like my compilation errors
are related in 
someway to  the switch

-DBOOST_ALL_NO_LIB=1

I've looked at the Jamfile.v2 for boost serialization build
and it includes 
only -DBOOST_SERIALIZATION_DYN_LINK=1

Searching around, I find in the boost root directory
Jamfile.v2 which 
contains the following:

# disable auto-linking for all targets here,
# primarily because it caused troubles with V2
<define>BOOST_ALL_NO_LIB=1

Which seems that it might be relevant to my case - it begs
for a better 
explanation.

Soooooooo - what do I do now?  The following facts are also
interesting:

a) the official boost test results are all passing for this
combination of 
compiler and library.  They don't show any compilation
errors.  The result 
matrix doesn't let me see the compilation command line for
the build - I 
would be curious to see it.

b) I've made VC IDE project which compiles the code with no
problem.  It 
doesn't pass the above switches though.

This kind of thing is very frustrating.

Robert Ramey



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

Robert Ramey wrote:

> I've checked out the latest version of Boost 1.34 -
tagged
> Version_1_34_1_RC3
> 
> I've carefully read the Boost Build documentation (very
much improved) and
> attempted to build the serialization library with the
command line
> executed in the directory ../libs/serialization/build:
> 
> bjam --toolset=msvc-7.1
> 
> I get compilation errors - which I've never seen
before.  

I never seen those error, either -- in particular because
you did not post them.

> /Gy -c
> -DBOOST_ALL_NO_LIB=1
> -DBOOST_SERIALIZATION_DYN_LINK=1
> "-I......"
> 
> Which seems almost OK.  It looks like my compilation
errors are related in
> someway to  the switch
> 
> -DBOOST_ALL_NO_LIB=1

Related in what what?

> I've looked at the Jamfile.v2 for boost serialization
build and it
> includes only -DBOOST_SERIALIZATION_DYN_LINK=1
> 
> Searching around, I find in the boost root directory
Jamfile.v2 which
> contains the following:
> 
> # disable auto-linking for all targets here,
> # primarily because it caused troubles with V2
> <define>BOOST_ALL_NO_LIB=1
> 
> Which seems that it might be relevant to my case - it
begs for a better
> explanation.

Ehm, long time ago the library names produced by V2 had no
relation
to the library names autolinking expected. It was fixed
since
then.

However, it does not seem to be any point in enabling
autolinking
for testing, so it's disabled.

> Soooooooo - what do I do now?  The following facts are
also interesting:
> 
> a) the official boost test results are all passing for
this combination of
> compiler and library.  They don't show any compilation
errors.  The result
> matrix doesn't let me see the compilation command line
for the build - I
> would be curious to see it.

I'm sure BOOST_ALL_NO_LIB is present.

- Volodya


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

Thanks for getting back to me so quickly.

I'm still looking into this.

It turns out that my Jamfile.v2 contains:

<link>shared:<define>BOOST_SERIALIZATION_DYN_LIN
K=1

Which turns out to the the "magic" which is
provoking the behavior.
I would guess then that I'm building libraries for DLL while
boost/test
is perhaps building/testing a static library so this issue
doesn't appear.

I don't remember why that line was included in the original
Jamfile.  I
did have a lot off difficulty with auto-link because I had
one library
wserialization which exports and API but at the same time
imports
and API from another library - serialization.  Perhaps
that's why
I included that.

So I'll just plug away a while longer.

But I do have a question:If the Jamfile.v2 in the boost root
contains
<define>BOOST_ALL_NO_LIB=1 does this mean that for
users
the default is auto-linking turned off?  Is that correct?

Robert Ramey



"Vladimir Prus" <ghostcs.msu.su> wrote in
message 
news:f7is6d$gnl$1sea.gmane.org...
> Robert Ramey wrote:
>
>> I've checked out the latest version of Boost 1.34 -
tagged
>> Version_1_34_1_RC3
>>
>> I've carefully read the Boost Build documentation
(very much improved) 
>> and
>> attempted to build the serialization library with
the command line
>> executed in the directory
../libs/serialization/build:
>>
>> bjam --toolset=msvc-7.1
>>
>> I get compilation errors - which I've never seen
before.
>
> I never seen those error, either -- in particular
because
> you did not post them.
>
>> /Gy -c
>> -DBOOST_ALL_NO_LIB=1
>> -DBOOST_SERIALIZATION_DYN_LINK=1
>> "-I......"
>>
>> Which seems almost OK.  It looks like my
compilation errors are related 
>> in
>> someway to  the switch
>>
>> -DBOOST_ALL_NO_LIB=1
>
> Related in what what?
>
>> I've looked at the Jamfile.v2 for boost
serialization build and it
>> includes only -DBOOST_SERIALIZATION_DYN_LINK=1
>>
>> Searching around, I find in the boost root
directory Jamfile.v2 which
>> contains the following:
>>
>> # disable auto-linking for all targets here,
>> # primarily because it caused troubles with V2
>> <define>BOOST_ALL_NO_LIB=1
>>
>> Which seems that it might be relevant to my case -
it begs for a better
>> explanation.
>
> Ehm, long time ago the library names produced by V2 had
no relation
> to the library names autolinking expected. It was fixed
since
> then.
>
> However, it does not seem to be any point in enabling
autolinking
> for testing, so it's disabled.
>
>> Soooooooo - what do I do now?  The following facts
are also interesting:
>>
>> a) the official boost test results are all passing
for this combination 
>> of
>> compiler and library.  They don't show any
compilation errors.  The 
>> result
>> matrix doesn't let me see the compilation command
line for the build - I
>> would be curious to see it.
>
> I'm sure BOOST_ALL_NO_LIB is present.
>
> - Volodya
>
>
> _______________________________________________
> Unsubscribe & other changes: 
> http://lists.boost.org/mailman/listinfo.cgi/boost-build
> 



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

Robert Ramey wrote:

> Thanks for getting back to me so quickly.
> 
> I'm still looking into this.
> 
> It turns out that my Jamfile.v2 contains:
> 
>
<link>shared:<define>BOOST_SERIALIZATION_DYN_LIN
K=1
> 
> Which turns out to the the "magic" which is
provoking the behavior.
> I would guess then that I'm building libraries for DLL
while boost/test
> is perhaps building/testing a static library so this
issue doesn't appear.

I would expect the testing process to be building shared
libraries, too,
as it's the default in Boost.Build V2. You might try to run
bjam in
libs/serialization/test directory to see if that works.

> I don't remember why that line was included in the
original Jamfile.  
> I did have a lot off difficulty with auto-link because
I had one library
> wserialization which exports and API but at the same
time imports
> and API from another library - serialization.  Perhaps
that's why
> I included that.

I'm not sure I understand what problems will arise from that
arrangement.
It seems there are separate defines:

        BOOST_SERIALIZATION_DYN_LINK=1
        BOOST_WSERIALIZATION_DYN_LINK=1

so everything should be OK.

> So I'll just plug away a while longer.
> 
> But I do have a question:If the Jamfile.v2 in the boost
root contains
> <define>BOOST_ALL_NO_LIB=1 does this mean that
for users
> the default is auto-linking turned off?  Is that
correct?

No, it only means that 'exe' projects under Jamfile.v2 won't
use autolinking.
That define does not affect libraries.

- Volodya


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

I've found the following line in the output of bjam.

...skipped 
<p......bin.v2libsserializationbuildmsvc-7.1debug
threading-multi>boost_serialization-vc71-mt-gd-1_34_1.li
b 
for lack of 
<p......bin.v2libsserializationbuildmsvc-7.1debug
threading-multi>basic_iarchive.obj...

It seems that the "<p..> is confusing
process_jam_log.  So
either

a) bjam is outputing something it shouldn't
b) process_jam_log isn't handling something it should
c) I'm just missing something.

I could tweak process_jam_log to work around this but if
its a bjam fix, I'd rather the experts look at it.

Thanks for you help.

Robert Ramey

Vladimir Prus wrote:

> I'm not sure I understand what problems will arise from
that
> arrangement.
> It seems there are separate defines:
>
>        BOOST_SERIALIZATION_DYN_LINK=1
>        BOOST_WSERIALIZATION_DYN_LINK=1
>
> so everything should be OK.

Well, I made a couple of adjustments and this seems OK now.
Of course I did have some declarations in there for a
reason
but maybe some combination was never tests - I'll keep and
eye on it.

> No, it only means that 'exe' projects under Jamfile.v2
won't use
> autolinking. That define does not affect libraries.

That's what I meant to say.  Just to be sure, this means
that user programs built with bjam won't use auto-linking
by default.  I would expect this is OK since most users
which would benefit from autolinking are probably building
their executables with an IDE anyway.

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



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

Robert Ramey wrote:

> I've found the following line in the output of bjam.
> 
> ...skipped
>
<p......bin.v2libsserializationbuildmsvc-7.1debug
threading-multi>boost_serialization-vc71-mt-gd-1_34_1.li
b
> for lack of
>
<p......bin.v2libsserializationbuildmsvc-7.1debug
threading-multi>basic_iarchive.obj...

This line says that serialization lib is not built, because

'basic_iarchive.obj' failed to build. The error messages
from
basic_iarchive.obj compilation is somewhere above,
presumably.

> 
> It seems that the "<p..> is confusing
process_jam_log.  

What made you think so?

> So 
> either
> 
> a) bjam is outputing something it shouldn't

It was outputting things like above for a long time.

> b) process_jam_log isn't handling something it should

If you passing --v2 to process_jam_log, it should handle
it.

> c) I'm just missing something.

Maybe you can start by explaining why do you
think process_jam_log has any problem. What you've posted
indicates a compilation issue.

- Volodya


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

Vladimir Prus wrote:
> Robert Ramey wrote:
>
>> I've found the following line in the output of
bjam.
>>
>> ...skipped
>>
<p......bin.v2libsserializationbuildmsvc-7.1debug
threading-multi>boost_serialization-vc71-mt-gd-1_34_1.li
b
>> for lack of
>>
<p......bin.v2libsserializationbuildmsvc-7.1debug
threading-multi>basic_iarchive.obj...
>
> This line says that serialization lib is not built,
because
> 'basic_iarchive.obj' failed to build. The error
messages from
> basic_iarchive.obj compilation is somewhere above,
presumably.

correct

>
>>
>> It seems that the "<p..> is confusing
process_jam_log.
>
> What made you think so?

When I process file with the above message in it,
process_jam_log produces
the following warning:

*****Warning - can't open output file: 
c:/boost134/../../bin.v2/libs/serializat
on/test/test_demo_fast_archive_dll.test/msvc-7.1/debug/threa
ding-multi/test_log
xml

which refers to and pathname that cannot be valid. (note the

c:/boost14/../../bin.v2 ...)

Tracing the code with the debugger to line 242 (approx) of 
process_jam_log.cpp
reveals code that would work as I would expect were it not
for the "p" in
the pathname <p../../../bin.v2 ...

So that's what leads me to the conclusion the one of the a),
b), or c) below
must hold true.  Which is it?

Robert Ramey


>
>> So
>> either
>>
>> a) bjam is outputing something it shouldn't
>
> It was outputting things like above for a long time.
>
>> b) process_jam_log isn't handling something it
should
>
> If you passing --v2 to process_jam_log, it should
handle
> it.
>
>> c) I'm just missing something.
>
> Maybe you can start by explaining why do you
> think process_jam_log has any problem. What you've
posted
> indicates a compilation issue.
>
> - Volodya
>
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost-build 



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

Robert Ramey wrote:
> Vladimir Prus wrote:
>> Robert Ramey wrote:
>>> It seems that the "<p..> is
confusing process_jam_log.
>>
>> What made you think so?
>
> When I process file with the above message in it,
process_jam_log
> produces the following warning:
>
> *****Warning - can't open output file:
> c:/boost134/../../bin.v2/libs/serializat
>
on/test/test_demo_fast_archive_dll.test/msvc-7.1/debug/threa
ding-multi/test_log
> xml
>
> which refers to and pathname that cannot be valid.
(note the
> c:/boost14/../../bin.v2 ...)
>
> Tracing the code with the debugger to line 242 (approx)
of
> process_jam_log.cpp
> reveals code that would work as I would expect were it
not for the
> "p" in the pathname <p../../../bin.v2 ...

OK - I was wrong about the "p".  But stll, the
above pathname can't be
correct - can it?

Robert Ramey




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