Calderon Hector wrote:

I've noticed something similar. I got basically two sets of the same lib files. For example,

libboost_wserialization-vc80-mt-s.lib

is exactly the same file (not only size but also contents) as

libboost_wserialization-vc80-mt-s-1_33_1.lib

That is as intended, and has nothing to do with Michaels problem in this case :-\ Sorry if the stuff below doesn't come out right as I'm pasting in from your original as Hectors posting program stripped some info...

-- Hector C.

"Drumheller, Michael" <michael.drumheller@boeing.com> wrote: Dear Bjam Experts:

Dear Bjam Experts:

For some reason all my source files are getting compiled twice. Below is my Jamfile (stripped to its essentials, and names changed to protect the innocent), and below that is the output (also stripped way down). Sorry for the clutter--I have tried to strip it down to the minimum.

Notice how every .obj gets constructed twice. Yet the destination path (vc-7_1\release\threading-multi\ is the same in each case; also, I'm also invoking bjam with precisely that target specified on the command line.

Is there anything really obvious to bjam-adjusted eyes going on here?

Thank you very much.

Michael Drumheller

----------------------------------------------------------cut here: Jamfile--------------------------------------- project-root ; import python ; include python.jam ; FOOCORE_SOURCES = File1 File2 ; FOOCORE_SOURCES = ..\\..\\src\\$(FOOCORE_SOURCES).cpp ; lib Foo : $(FOOCORE_SOURCES) : <include>C:\\Boost\\include\\boost-1_32 <vc-7_1><*><define>WIN32 <include>..\\..\\src <include>C:\\Python24\\include <include>"C:\\Program Files\\Microsoft Visual Studio .NET 2003\\Vc7\\include" ; ----------------------------------------------------------cut here:

That looks OK. By the way you could use "/" instead of "\\" to same yourself some typing. They both work with bjam.

resulting output --------------------------- 06-02-26:12:22:26:boost/FooBar=> bjam -sTOOLS=vc-7_1 "-sBUILD=release <threading>multi" ...found 3088 targets... ...updating 142 targets... vc-C++ ./build\bin\FooBar\libFoo.lib\vc-7_1\release\threading-multi\File1.obj File1.cpp vc-C++ ./build\bin\FooBar\libFoo.lib\vc-7_1\release\threading-multi\File2.obj File2.cpp ...<snip>... vc-Archive ./build\bin\FooBar\libFoo.lib\vc-7_1\release\threading-multi\libFoo.lib Microsoft (R) Library Manager Version 7.10.3077 Copyright (C) Microsoft Corporation. All rights reserved.

"./build\bin\FooBar\libFoo.lib\vc-7_1\release\threading-multi\File1.obj"

"./build\bin\FooBar\libFoo.lib\vc-7_1\release\threading-multi\File2.obj"

...<snip>... vc-C++ ./build\bin\FooBar\libFoo.lib\vc-7_1\release\threading-multi\File1.obj File1.cpp vc-C++ ./build\bin\FooBar\libFoo.lib\vc-7_1\release\threading-multi\File2.obj File2.cpp ...<snip>... vc-Archive ./build\bin\FooBar\libFoo.lib\vc-7_1\release\threading-multi\libFoo.lib Microsoft (R) Library Manager Version 7.10.3077 Copyright (C) Microsoft Corporation. All rights reserved.

"./build\bin\FooBar\libFoo.lib\vc-7_1\release\threading-multi\File1.obj"

"./build\bin\FooBar\libFoo.lib\vc-7_1\release\threading-multi\File2.obj"

...<snip>...

Very strange, and I'm not sure what could be wrong. Are you using the 1.32 version of Boost.Build? It might be worth it replacing it with the latest from 1.33.1 as perhaps it's something I fixed since then. All it should take is to delete the tools/build/v1 directory and replace it with the one from 1.33.1. Sorry I don't have any other suggestions :-( -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo