[gil] Ok to merge new gil's extension to release branch?
Hi, is it ok? The merge would include io, toolbox, numerics and some other changes to gil's code itself. Regards, Christian
AMDG On 03/29/2013 09:27 AM, Christian Henning wrote:
is it ok? The merge would include io, toolbox, numerics and some other changes to gil's code itself.
Your test suite for io is not being run. I disabled it because it broke the regression tests. You seem to be using Boost.Build extensions which are not in the trunk. In Christ, Steven Watanabe
Your test suite for io is not being run. I disabled it because it broke the regression tests. You seem to be using Boost.Build extensions which are not in the trunk.
OK, I understand. What would be the preferred course of action? For now I just add another compiler symbol to exclude tests that need external libraries. Regards, Christian
AMDG On 03/29/2013 09:59 AM, Christian Henning wrote:
Your test suite for io is not being run. I disabled it because it broke the regression tests. You seem to be using Boost.Build extensions which are not in the trunk.
OK, I understand. What would be the preferred course of action?
a) add zlib.jam etc. to Boost.Build. I can review and add them if you point me to where they come from. b) in your Jamfile, attempt to auto-configure these libraries if they are not already configured. c) in your Jamfile, test whether the libraries were successfully configured and take any appropriate action.
For now I just add another compiler symbol to exclude tests that need external libraries.
In Christ, Steven Watanabe
Hi Steven,
a) add zlib.jam etc. to Boost.Build. I can review and add them if you point me to where they come from.
You can find all jam files here: http://svn.boost.org/svn/boost/sandbox/tools/build_extensions/ext I use: zlib.jam png.jam jpeg.jam libtiff.jam
b) in your Jamfile, attempt to auto-configure these libraries if they are not already configured.
I'm not sure what that means. A user has to point to the source code somehow. How should we do that? Using environmental variables?
c) in your Jamfile, test whether the libraries were successfully configured and take any appropriate action.
Again, how would you do that? Thanks for your help! Christian
AMDG On 03/29/2013 11:44 AM, Christian Henning wrote:
Hi Steven,
a) add zlib.jam etc. to Boost.Build. I can review and add them if you point me to where they come from.
You can find all jam files here:
http://svn.boost.org/svn/boost/sandbox/tools/build_extensions/ext
I use: zlib.jam png.jam jpeg.jam libtiff.jam
Thanks.
b) in your Jamfile, attempt to auto-configure these libraries if they are not already configured.
I'm not sure what that means. A user has to point to the source code somehow. How should we do that? Using environmental variables?
It would go in user-config.jam (or site-config.jam). If the library has a standard installation location it should be found without any help from the user. There's nothing we can do on Windows, but on other platforms we can use the compiler's default search path.
c) in your Jamfile, test whether the libraries were successfully configured and take any appropriate action.
Again, how would you do that?
What I mean is that your code should look like: using zlib ; if [ zlib.configured ] { ... } I don't know whether the existing zlib.jam supports usage like this, but I'll make sure that something like this works if you need it. In Christ, Steven Watanabe
Steven Watanabe wrote:
AMDG
On 03/29/2013 11:44 AM, Christian Henning wrote:
Hi Steven,
a) add zlib.jam etc. to Boost.Build. I can review and add them if you point me to where they come from.
You can find all jam files here:
http://svn.boost.org/svn/boost/sandbox/tools/build_extensions/ext
I use: zlib.jam png.jam jpeg.jam libtiff.jam
Thanks.
b) in your Jamfile, attempt to auto-configure these libraries if they are not already configured.
I'm not sure what that means. A user has to point to the source code somehow. How should we do that? Using environmental variables?
It would go in user-config.jam (or site-config.jam). If the library has a standard installation location it should be found without any help from the user. There's nothing we can do on Windows, but on other platforms we can use the compiler's default search path.
c) in your Jamfile, test whether the libraries were successfully configured and take any appropriate action.
Again, how would you do that?
What I mean is that your code should look like:
using zlib ;
if [ zlib.configured ] { ... }
I don't know whether the existing zlib.jam supports usage like this, but I'll make sure that something like this works if you need it.
FWIW iostreams uses zlib so that may be a place to start.
FWIW iostreams uses zlib so that may be a place to start.
I have read the tried to understand their way of including zlib. I think they make it themselves a little too easy and not so easy for a potential user. For instance a user who wants to compile four different sets of libraries ( you know the usual: x86, x64, debug, release config ) would have to redefine the ZLIB_BINARY for each configuration. And how can a user set compiler symbols that are relevant for zlib? What I like to achieve with gil::io is that 3rd party libs are compiled before the test cases. Here are a few points that I like to have: * have the user set compiler symbols that are relevant for 3rd party libs * have the user set basic library information depending on current architecture configuration, like DEBUG x64, etc. * some users might want to compile zlib and other libs as c++ code. Inside gil::io users can set some compiler symbols so the 3rd party header are included appropriately. I hope the boost community can help me out setting up my jam files accordingly! Regards, Christian
Hi Steven,
b) in your Jamfile, attempt to auto-configure these libraries if they are not already configured.
I'm not sure what that means. A user has to point to the source code somehow. How should we do that? Using environmental variables?
It would go in user-config.jam (or site-config.jam). If the library has a standard installation location it should be found without any help from the user. There's nothing we can do on Windows, but on other platforms we can use the compiler's default search path.
OK, if you think user-config.jam is the way to go then we do it this way. Of course, I'll reflect the necessary changes in gil::io documentation. Can we just define the source code path like this, inside user-config.jam: using zlib : 1.2.5 : c:/chhenning/zlib/zlib-1.2.5 If so, how would the gil::io jam file pick up the path? As you probably can guess I'm not very familiar with configuring jam files. Any help from your side would be very appreciated.
c) in your Jamfile, test whether the libraries were successfully configured and take any appropriate action.
Again, how would you do that?
What I mean is that your code should look like:
using zlib ;
if [ zlib.configured ] { ... }
I don't know whether the existing zlib.jam supports usage like this, but I'll make sure that something like this works if you need it.
Please let me know what I have to do make it to work. Thanks, Christian
AMDG On 03/31/2013 10:25 AM, Christian Henning wrote:
OK, if you think user-config.jam is the way to go then we do it this way. Of course, I'll reflect the necessary changes in gil::io documentation.
Can we just define the source code path like this, inside user-config.jam:
using zlib : 1.2.5 : c:/chhenning/zlib/zlib-1.2.5
Something along those lines. I haven't worked out all the details of the interface yet.
If so, how would the gil::io jam file pick up the path?
This would work now. project ids are global, so you can use /ext/zlib//z regardless of where zlib is using'ed.
As you probably can guess I'm not very familiar with configuring jam files. Any help from your side would be very appreciated.
<snip> Please let me know what I have to do make it to work.
I've had to completely reimplement the zlib module. the one in the trunk was badly broken and the one that you were using is lacking the ability to use pre-built binaries. I expect to have it ready tomorrow. In Christ, Steven Watanabe
Hi Steven,
using zlib : 1.2.5 : c:/chhenning/zlib/zlib-1.2.5
Something along those lines. I haven't worked out all the details of the interface yet.
Can we add some zlib compiler symbols or should that be defined in gil::io's jam file?
As you probably can guess I'm not very familiar with configuring jam files. Any help from your side would be very appreciated.
<snip> Please let me know what I have to do make it to work.
I've had to completely reimplement the zlib module. the one in the trunk was badly broken and the one that you were using is lacking the ability to use pre-built binaries. I expect to have it ready tomorrow.
That's awesome! Hopefully I can help out with the other 3rd party jam files. Let me know if you need anything. Thanks, Christian
AMDG On 03/31/2013 12:14 PM, Christian Henning wrote:
Hi Steven,
using zlib : 1.2.5 : c:/chhenning/zlib/zlib-1.2.5
Something along those lines. I haven't worked out all the details of the interface yet.
Can we add some zlib compiler symbols or should that be defined in gil::io's jam file?
It should probably be defined in your jamfile. I assume that the defines are specific to gil::io. I was planning to create a rule that is analogous to configure.check-target-builds: # Selects properties based on the status of a pre-built library. # target must be a target reference which refers to # an ac-library-target. # true-properties will be used if the library was found # false-properties will be used if the library was not found rule ac.check-library ( target : true-properties * : false-properties * ) which you could use like this: run test.cpp : ... : # requirements [ ac.check-library /zlib//zlib : <define>BOOST_GIL_IO_HAS_ZLIB <library>/zlib//zlib ] ;
As you probably can guess I'm not very familiar with configuring jam files. Any help from your side would be very appreciated.
<snip> Please let me know what I have to do make it to work.
I've had to completely reimplement the zlib module. the one in the trunk was badly broken and the one that you were using is lacking the ability to use pre-built binaries. I expect to have it ready tomorrow.
That's awesome! Hopefully I can help out with the other 3rd party jam files. Let me know if you need anything.
In Christ, Steven Watanabe
Can we add some zlib compiler symbols or should that be defined in gil::io's jam file?
It should probably be defined in your jamfile. I assume that the defines are specific to gil::io.
Just to be on the same page. Should the gil::io test jam file initiate the compilation of the 3rd party libs? I think this would be preferable so that the user can easily configure the correct target architecture. Instead of having to first compile all binaries target architectures before doing the gil::io tests. Is that what you are planning to do? Christian
AMDG On 03/31/2013 04:18 PM, Christian Henning wrote:
Can we add some zlib compiler symbols or should that be defined in gil::io's jam file?
It should probably be defined in your jamfile. I assume that the defines are specific to gil::io.
Just to be on the same page. Should the gil::io test jam file initiate the compilation of the 3rd party libs? I think this would be preferable so that the user can easily configure the correct target architecture. Instead of having to first compile all binaries target architectures before doing the gil::io tests.
Is that what you are planning to do?
/zlib//zlib will either find an existing library or build zlib from source depending on how it's configured. It's basically a generic version of the way Boost.Iostreams handles it. In Christ, Steven Watanabe
Just to be on the same page. Should the gil::io test jam file initiate the compilation of the 3rd party libs? I think this would be preferable so that the user can easily configure the correct target architecture. Instead of having to first compile all binaries target architectures before doing the gil::io tests.
Is that what you are planning to do?
/zlib//zlib will either find an existing library or build zlib from source depending on how it's configured. It's basically a generic version of the way Boost.Iostreams handles it.
Great! Thanks for the quick answer. Christian
AMDG On 03/31/2013 04:38 PM, Christian Henning wrote:
Just to be on the same page. Should the gil::io test jam file initiate the compilation of the 3rd party libs? I think this would be preferable so that the user can easily configure the correct target architecture. Instead of having to first compile all binaries target architectures before doing the gil::io tests.
Is that what you are planning to do?
/zlib//zlib will either find an existing library or build zlib from source depending on how it's configured. It's basically a generic version of the way Boost.Iostreams handles it.
Great! Thanks for the quick answer.
I've committed this to the trunk and updated Boost.IOStreams to use it. In Christ, Steven Watanabe
Hi Steven, I've committed this to the trunk and updated
Boost.IOStreams to use it.
Thanks! I have taken a quick look and will add the changed to my jam file tonight. I think I still have to apply your changes to the other 3rd party jam file ( png, jpeg, and tiff ). Quick question: I usually compile 32bit and 64bit for both DEBUG and RELEASE configurations. How would I configure the binary name depending on the architecture and configuration? I imagine a naming convention like we do for the general boost libs. Thanks again for your work Christian
AMDG On 04/02/2013 06:17 AM, Christian Henning wrote:
I've committed this to the trunk and updated
Boost.IOStreams to use it.
Thanks! I have taken a quick look and will add the changed to my jam file tonight. I think I still have to apply your changes to the other 3rd party jam file ( png, jpeg, and tiff ).
Quick question:
I usually compile 32bit and 64bit for both DEBUG and RELEASE configurations. How would I configure the binary name depending on the architecture and configuration? I imagine a naming convention like we do for the general boost libs.
Just copy what I did for Boost.IOStreams: <build-name>boost_zlib <tag>@tag (the tag rule is inherited from Jamroot) Everything inside Boost needs to be consistent about this. In Christ, Steven Watanabe
Hi Steven, I have been toying around with your zlib changes but I'm stuck when compiling boost trunk. I did add a rule in my user-config.jam saying: #------------------------------- # 3rd Party Libs #------------------------------- using zlib : 1.2.5 : <source>C:\chhenning\zlib\zlib-1.2.5 : <toolset>msvc ; and now when I run bjam with the following command line: bjam -j8 --toolset=msvc --without-mpi variant=debug link=static runtime-link=shared define=_CRT_NONSTDC_NO_DEPRECATE define=_CRT_SECURE_NO_DEPRECATE define=_SCL_SECURE_NO_DEPRECATE stage I get this error: Performing configuration checks - 32-bit : yes - arm : no - mips1 : no - power : no - sparc : no - x86 : yes - has_icu builds : no warning: Graph library does not contain MPI-based parallel components. note: to enable them, add "using mpi ;" to your user-config.jam C:/boost/tools/build/v2/build\targets.jam:1203: in object(ac-library)@42.match ERROR: rule "<toolset>msvc.base" unknown in module "object(ac-library)@42". C:/boost/tools/build/v2/build\targets.jam:662: in select-alternatives C:/boost/tools/build/v2/build\targets.jam:747: in generate-really C:/boost/tools/build/v2/build\targets.jam:729: in object(main-target)@1746.generate C:/boost/tools/build/v2/build\targets.jam:874: in targets.generate-from-reference C:/boost/tools/build/v2/build\ac.jam:240: in object(check-library-worker)@562.check C:/boost/tools/build/v2/kernel\modules.jam:107: in modules.call-in C:/boost/tools/build/v2/util\indirect.jam:98: in indirect.call C:/boost/tools/build/v2/build\targets.jam:1033: in evaluate-requirements C:/boost/tools/build/v2/build\targets.jam:1091: in common-properties2 C:/boost/tools/build/v2/build\targets.jam:956: in targets.common-properties C:/boost/tools/build/v2/build\targets.jam:1282: in object(typed-target)@567.generate C:/boost/tools/build/v2/build\targets.jam:757: in generate-really C:/boost/tools/build/v2/build\targets.jam:729: in object(main-target)@1735.generate C:/boost/tools/build/v2/build\targets.jam:272: in object(project-target)@560.generate C:/boost/tools/build/v2/build\targets.jam:874: in targets.generate-from-reference C:/boost/tools/build/v2/build\targets.jam:1245: in generate-dependencies C:/boost/tools/build/v2/build\targets.jam:1302: in object(alias-target-class)@108.generate C:/boost/tools/build/v2/build\targets.jam:757: in generate-really C:/boost/tools/build/v2/build\targets.jam:729: in object(main-target)@1093.generate C:/boost/tools/build/v2/build\targets.jam:874: in targets.generate-from-reference C:/boost/tools/build/v2/build\targets.jam:1245: in generate-dependencies C:/boost/tools/build/v2/build\targets.jam:1302: in object(install-target-class)@153.generate C:/boost/tools/build/v2/build\targets.jam:757: in generate-really C:/boost/tools/build/v2/build\targets.jam:729: in object(main-target)@1118.generate C:/boost/tools/build/v2/build\targets.jam:874: in targets.generate-from-reference C:/boost/tools/build/v2/build\targets.jam:1245: in generate-dependencies C:/boost/tools/build/v2/build\targets.jam:1302: in alias-target-class.generate C:/boost\boostcpp.jam:431: in build-multiple C:/boost\boostcpp.jam:393: in object(top-level-target)@160.generate C:/boost/tools/build/v2/build\targets.jam:757: in generate-really C:/boost/tools/build/v2/build\targets.jam:729: in object(main-target)@1122.generate C:/boost/tools/build/v2\build-system.jam:705: in load C:\boost\tools\build\v2/kernel\modules.jam:289: in import C:\boost\tools\build\v2/kernel/bootstrap.jam:139: in boost-build C:\boost\boost-build.jam:17: in module scope I did update the complete trunk and therefore I'm trying to rebuild the boost libs. Regards, Christian
AMDG On 04/02/2013 05:36 PM, Christian Henning wrote:
Hi Steven,
I have been toying around with your zlib changes but I'm stuck when compiling boost trunk. I did add a rule in my user-config.jam saying:
#------------------------------- # 3rd Party Libs #------------------------------- using zlib : 1.2.5 : <source>C:\chhenning\zlib\zlib-1.2.5 : <toolset>msvc ;
and now when I run bjam with the following command line:
<snip> ERROR: rule "<toolset>msvc.base" unknown in module "object(ac-library)@42".
I apparently didn't test passing a condition. For now, leave off the <toolset>msvc. It shouldn't be needed. I'll fix it first thing tomorrow. (The condition needs to be passed through targets.main-target-requirements to create a property-set. I left them in raw list form) In Christ, Steven Watanabe
<snip>
ERROR: rule "<toolset>msvc.base" unknown in module "object(ac-library)@42".
I apparently didn't test passing a condition. For now, leave off the <toolset>msvc. It shouldn't be needed. I'll fix it first thing tomorrow. (The condition needs to be passed through targets.main-target-requirements to create a property-set. I left them in raw list form)
Ok, I'll try this tonight at home. BTW, how would I pass compiler symbol to control the zlib compilation? Thanks, Christian
Hi Steven,
I apparently didn't test passing a condition. For now, leave off the <toolset>msvc. It shouldn't be needed. I'll fix it first thing tomorrow. (The condition needs to be passed through targets.main-target-requirements to create a property-set. I left them in raw list form)
I did as you told me. My zlib entry for user-config.jam now looks like this: #------------------------------- # 3rd Party Libs #------------------------------- using zlib : 1.2.5 : <source>C:\chhenning\zlib\zlib-1.2.5 : ; And the output now is: Performing configuration checks - 32-bit : yes - arm : no - mips1 : no - power : no - sparc : no - x86 : yes - has_icu builds : no warning: Graph library does not contain MPI-based parallel components. note: to enable them, add "using mpi ;" to your user-config.jam error: No best alternative for /zlib next alternative: required properties: (empty) matched next alternative: required properties: (empty) matched error: No best alternative for /zlib next alternative: required properties: (empty) matched next alternative: required properties: (empty) matched - iconv (libc) : no - iconv (separate) : no - icu : no - icu (lib64) : no - gcc visibility : no - long double support : yes
Ok, I'll try this tonight at home. BTW, how would I pass compiler symbol to control the zlib compilation?
Would you mind telling me how to pass compiler symbols? Thanks, Christian
AMDG On 04/03/2013 04:53 PM, Christian Henning wrote:
<snip> #------------------------------- # 3rd Party Libs #------------------------------- using zlib : 1.2.5 : <source>C:\chhenning\zlib\zlib-1.2.5 : ;
The backslashes will be a problem, since '\' is the escape character. You need to use either '/' or '\\'.
<snip> error: No best alternative for /zlib next alternative: required properties: (empty) matched next alternative: required properties: (empty) matched error: No best alternative for /zlib next alternative: required properties: (empty) matched next alternative: required properties: (empty) matched
This ought to be impossible. What do you get with --debug-configuration? In any event, it indicates that you reinitialized zlib in your Jamfile, after it was already initialized in user-config.jam.
<snip>
Ok, I'll try this tonight at home. BTW, how would I pass compiler symbol to control the zlib compilation?
Would you mind telling me how to pass compiler symbols?
Use properties: e.g. /zlib//zlib/<variant>release In Christ, Steven Watanabe
<snip> #------------------------------- # 3rd Party Libs #------------------------------- using zlib : 1.2.5 : <source>C:\chhenning\zlib\zlib-1.2.5 : ;
The backslashes will be a problem, since '\' is the escape character. You need to use either '/' or '\\'.
OK, I fixed that.
<snip> error: No best alternative for /zlib next alternative: required properties: (empty) matched next alternative: required properties: (empty) matched error: No best alternative for /zlib next alternative: required properties: (empty) matched next alternative: required properties: (empty) matched
This ought to be impossible. What do you get with --debug-configuration? In any event, it indicates that you reinitialized zlib in your Jamfile, after it was already initialized in user-config.jam.
I rerun again and you can see the output here: http://pastebin.com/BWgWdtRz I'm trying to build boost libs not the gil:io tests. So the only lib that would use zlib is boost::iostreams but I haven't configured it to use it.
<snip>
Ok, I'll try this tonight at home. BTW, how would I pass compiler symbol to control the zlib compilation?
Would you mind telling me how to pass compiler symbols?
Use properties: e.g. /zlib//zlib/<variant>release
What I mean is to set compiler flags like: CFLAGS= -DMAX_WBITS=14 -DMAX_MEM_LEVEL=7 Those flags are zlib specific. Christian
AMDG On 04/03/2013 07:27 PM, Christian Henning wrote:
<snip> I rerun again and you can see the output here:
I'm trying to build boost libs not the gil:io tests. So the only lib that would use zlib is boost::iostreams but I haven't configured it to use it.
Oh. I see what the problem is. Should be fixed now.
<snip>
Use properties: e.g. /zlib//zlib/<variant>release
What I mean is to set compiler flags like: CFLAGS= -DMAX_WBITS=14 -DMAX_MEM_LEVEL=7
Those flags are zlib specific.
It depends on where you want to specify them. If you want to specify it in your Jamfile, then: feature.feature zlib-variant : myzlib : optional propagated composite ; feature.compose <zlib-variant>myzlib : <define>MAX_WBITS=14 <define>MAX_MEM_LEVEL=7 ; Then use <zlib-variant>myzlib as above. If you want to specify it in user-config.jam, then use: uzing zlib : 1.2.5 : <source>... : <define>... ; In Christ, Steven Watanabe
What I mean is to set compiler flags like: CFLAGS= -DMAX_WBITS=14 -DMAX_MEM_LEVEL=7
Those flags are zlib specific.
It depends on where you want to specify them.
If you want to specify it in your Jamfile, then:
feature.feature zlib-variant : myzlib : optional propagated composite ; feature.compose <zlib-variant>myzlib : <define>MAX_WBITS=14 <define>MAX_MEM_LEVEL=7 ;
Then use <zlib-variant>myzlib as above.
If you want to specify it in user-config.jam, then use:
uzing zlib : 1.2.5 : <source>... : <define>... ;
My hope is I can define all 3rd party lib stuff in my user-config.jam. At least then I don't have to worry about it anymore. I'll try again tonight. Thanks!
Hi Steven, On Wednesday, 3. April 2013 21:10:08 Steven Watanabe wrote:
AMDG
On 04/03/2013 07:27 PM, Christian Henning wrote:
<snip> I rerun again and you can see the output here:
I'm trying to build boost libs not the gil:io tests. So the only lib that would use zlib is boost::iostreams but I haven't configured it to use it.
Oh. I see what the problem is. Should be fixed now.
No, I still have problems compiling IOstreams. First, zlib.jam has one line "condition = [ $(condition).base ] ;" too much (see zlib.diff). Then ac.jam appends the contents of the test files again and again. See ac_zlib.diff for a patch and zlib_with_requirements.log for "error C2084: function 'int main(void)' already has a body". and zlib.jam seems to be called twice. I only have one setup for a prebuilt library (zlib_setup.txt from user-config.jam) and I get two invocations, one with my setup and one with some empty properties. details in "zlib_with_requirements.log". If I remove the requirement <toolset>msvc, I get "zlib_without_requirements.log" which ends with " notice: [zlib] Using pre-installed library notice: [zlib] Condition error: at E:\dev\devel\boost\libs\iostreams\build\Jamfile.v2:35 error: zlib is already configured " which might shed some light on things... Or I am completely off-track again. Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! * voice: ++49 4257 300 ! Fährstraße 1 * fax : ++49 4257 300 ! 31609 Balge/Sebbenhausen * jhunold@gmx.eu ! Germany
AMDG On 04/04/2013 11:22 AM, Jürgen Hunold wrote:
First, zlib.jam has one line "condition = [ $(condition).base ] ;" too much (see zlib.diff).
Ugh. I really dislike property-set.base. I've fixed this correctly.
Then ac.jam appends the contents of the test files again and again. See ac_zlib.diff for a patch and zlib_with_requirements.log for "error C2084: function 'int main(void)' already has a body".
Fixed.
and zlib.jam seems to be called twice. I only have one setup for a prebuilt library (zlib_setup.txt from user-config.jam) and I get two invocations, one with my setup and one with some empty properties.
That's intentional. The empty properties come from Boost.IOStreams creating a default setup.
details in "zlib_with_requirements.log". If I remove the requirement <toolset>msvc, I get "zlib_without_requirements.log" which ends with
" notice: [zlib] Using pre-installed library notice: [zlib] Condition error: at E:\dev\devel\boost\libs\iostreams\build\Jamfile.v2:35 error: zlib is already configured "
The flag to prevent that mysteriously vanished from the iostreams Jamfile. Fixed now. In Christ, Steven Watanabe
Hi Steven, thanks a lot, it slowly starts working On Thursday, 4. April 2013 12:31:50 Steven Watanabe wrote:
AMDG
[ two fixes]
and zlib.jam seems to be called twice. I only have one setup for a prebuilt library (zlib_setup.txt from user-config.jam) and I get two invocations, one with my setup and one with some empty properties.
That's intentional. The empty properties come from Boost.IOStreams creating a default setup.
Ah, understood.
The flag to prevent that mysteriously vanished from the iostreams Jamfile. Fixed now.
Thanks. Right now, it seems as if the compile and link tests are broken for prebuilt libraries. See zlib_detect.log for details. Running with "-d+2" and additional debug logic I don't see my paths to the prebuilt includes appearing in the command line for the compile test. The same for the link test, which should contains more code, btw. Or is the test picking up the default setup again? Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! * voice: ++49 4257 300 ! Fährstraße 1 * fax : ++49 4257 300 ! 31609 Balge/Sebbenhausen * jhunold@gmx.eu ! Germany
AMDG On 04/04/2013 01:19 PM, Jürgen Hunold wrote:
Right now, it seems as if the compile and link tests are broken for prebuilt libraries. See zlib_detect.log for details. Running with "-d+2" and additional debug logic I don't see my paths to the prebuilt includes appearing in the command line for the compile test.
The include path got lost in ac-library.construct. I think I fixed this.
The same for the link test, which should contains more code, btw.
What should it contain? I'm only trying to test for the existence of the library. The link test seems to be working correctly.
Or is the test picking up the default setup again?
In Christ, Steven Watanabe
Hi Steven, On Thursday, 4. April 2013 13:45:36 Steven Watanabe wrote:
AMDG
On 04/04/2013 01:19 PM, Jürgen Hunold wrote:
Right now, it seems as if the compile and link tests are broken for prebuilt libraries. See zlib_detect.log for details. Running with "-d+2" and additional debug logic I don't see my paths to the prebuilt includes appearing in the command line for the compile test.
The include path got lost in ac-library.construct. I think I fixed this.
Yes, everything is working again. Thanks.
The same for the link test, which should contains more code, btw.
What should it contain? I'm only trying to test for the existence of the library. The link test seems to be working correctly.
Well, there is only a simple "main" in the cpp. That means one can easily link against *any* other library. The config test for Qt5 contain z_streamp stream; and querying "zlibVersion();" for example. This ensures that the symbols from the library are really needed. But I guess this gets complicated. Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! * voice: ++49 4257 300 ! Fährstraße 1 * fax : ++49 4257 300 ! 31609 Balge/Sebbenhausen * jhunold@gmx.eu ! Germany
Hi Steven,
If you want to specify it in user-config.jam, then use:
uzing zlib : 1.2.5 : <source>... : <define>... ;
I think that's the best way for now. I have just updated my boost trunk and rebuild bjam and the boost libs in Debug configuration. I can see there is static library called libz.lib in my stage folder. Is there any way we could name it something like zlib-vc100-mt-gd-1_2_5.lib? This way I can understand which one is Debug and Release, etc. I'll now will try to recreate a jam file for jpeg, png, and tiff based on what you created with zlib.jam. Do you foresee any complications? Thanks again for your work! Christian
AMDG On 04/05/2013 05:12 PM, Christian Henning wrote:
Hi Steven,
If you want to specify it in user-config.jam, then use:
uzing zlib : 1.2.5 : <source>... : <define>... ;
I think that's the best way for now.
I have just updated my boost trunk and rebuild bjam and the boost libs in Debug configuration. I can see there is static library called libz.lib in my stage folder. Is there any way we could name it something like zlib-vc100-mt-gd-1_2_5.lib? This way I can understand which one is Debug and Release, etc.
Use <tag> (Documented here: http://www.boost.org/boost-build2/doc/html/bbv2/overview/builtins/features.h...). You can look at $BOOST/boostcpp.jam for an example. I suppose that I could add a default tag, but I'll have to think about it.
I'll now will try to recreate a jam file for jpeg, png, and tiff based on what you created with zlib.jam. Do you foresee any complications?
You'll need tests. I've just committed some basic tests for zlib. In Christ, Steven Watanabe
I have just updated my boost trunk and rebuild bjam and the boost libs in Debug configuration. I can see there is static library called libz.lib in my stage folder. Is there any way we could name it something like zlib-vc100-mt-gd-1_2_5.lib? This way I can understand which one is Debug and Release, etc.
Use <tag> (Documented here:
http://www.boost.org/boost-build2/doc/html/bbv2/overview/builtins/features.h... ). You can look at $BOOST/boostcpp.jam for an example. I suppose that I could add a default tag, but I'll have to think about it.
I'll tackle this later then. First I'll create the other jam files.
I'll now will try to recreate a jam file for jpeg, png, and tiff based on what you created with zlib.jam. Do you foresee any complications?
You'll need tests. I've just committed some
basic tests for zlib.
I found zlib.py and I suppose those are the tests you mentioned above. How do you run those tests?
AMDG On 04/07/2013 11:39 AM, Christian Henning wrote:
I found zlib.py and I suppose those are the tests you mentioned above. How do you run those tests?
python zlib.py msvc (or whatever toolset you're using) There should be documentation in an html file in the test directory. In Christ, Steven Watanabe
On Sun, Apr 7, 2013 at 2:59 PM, Steven Watanabe <watanabesj@gmail.com>wrote:
AMDG
On 04/07/2013 11:39 AM, Christian Henning wrote:
I found zlib.py and I suppose those are the tests you mentioned above.
How
do you run those tests?
python zlib.py msvc (or whatever toolset you're using) There should be documentation in an html file in the test directory.
When I do that I get: failure {{{ "['c:\\boost\\tools\\build\\v2\\test\\../engine\\bin.ntx86\\bjam', '-sBOOST_BUILD_PATH="c:\\boost\\tools\\build\\v2\\test/.."', '-d0', '--quiet', 'toolset=mock', '--test-config="c:\\boost\\tools\\build\\v2\\test\\test-config.jam"', '--ignore-toolset-requirements']" returned 1 }}} reason {{{ unexpected status returned by bjam }}} changes caused by the last build command {{{ Added files : [] Removed files : [] Modified files: [] Touched files : [] }}} STDOUT {{{ error: at Jamroot.jam:3 error: zlib is already configured }}} STDERR {{{ }}} stacktrace {{{ at line 590 of c:\boost\tools\build\v2\test\BoostBuild.py (fail_test) from line 485 of c:\boost\tools\build\v2\test\BoostBuild.py (run_build_system) from line 32 of zlib.py (<module>) }}} Before running the test I deleted my bin.v2 folder. I have created 3 new jam files and committed them to boost trunk, in the same folder as zlib.jam. There are some remaining issues which I'll describe in new email thread. Christian
AMDG On 04/07/2013 01:21 PM, Christian Henning wrote:
On Sun, Apr 7, 2013 at 2:59 PM, Steven Watanabe <watanabesj@gmail.com>wrote:
On 04/07/2013 11:39 AM, Christian Henning wrote:
I found zlib.py and I suppose those are the tests you mentioned above.
How
do you run those tests?
python zlib.py msvc (or whatever toolset you're using) There should be documentation in an html file in the test directory.
When I do that I get:
failure {{{ "['c:\\boost\\tools\\build\\v2\\test\\../engine\\bin.ntx86\\bjam', '-sBOOST_BUILD_PATH="c:\\boost\\tools\\build\\v2\\test/.."', '-d0', '--quiet', 'toolset=mock', '--test-config="c:\\boost\\tools\\build\\v2\\test\\test-config.jam"', '--ignore-toolset-requirements']" returned 1 }}} reason {{{ unexpected status returned by bjam }}} <snip>
}}} STDOUT {{{ error: at Jamroot.jam:3 error: zlib is already configured
<snip>
What do you get with --verbose? It almost sounds like it's picking up your user-config.jam, but --test-config should override the default configuration files. In Christ, Steven Watanabe
What do you get with --verbose? It almost sounds like it's picking up your user-config.jam, but --test-config should override the default configuration files.
When I run: python zlib.py --verbose msvc > out.txt I get this: error: at Jamroot.jam:3 error: zlib is already configured failure {{{ "['c:\\boost\\tools\\build\\v2\\test\\../engine\\bin.ntx86\\bjam', '-sBOOST_BUILD_PATH="c:\\boost\\tools\\build\\v2\\test/.."', '-d+2', 'toolset=mock', '--test-config="c:\\boost\\tools\\build\\v2\\test\\test-config.jam"', '--ignore-toolset-requirements']" returned 1 }}} reason {{{ unexpected status returned by bjam }}} changes caused by the last build command {{{ Added files : [] Removed files : [] Modified files: [] Touched files : [] }}} STDOUT {{{ error: at Jamroot.jam:3 error: zlib is already configured }}} STDERR {{{ }}} stacktrace {{{ at line 590 of c:\boost\tools\build\v2\test\BoostBuild.py (fail_test) from line 485 of c:\boost\tools\build\v2\test\BoostBuild.py (run_build_system) from line 32 of zlib.py (<module>) }}} Christian
<snip> error: at Jamroot.jam:3 error: zlib is already configured
I misunderstood how the test system works. Should be fixed now.
Ok, I updated trunk and rerun. This is the output now: common.mkdir bin if not exist "bin\\" mkdir "bin" common.mkdir bin\standalone if not exist "bin\standalone\\" mkdir "bin\standalone" common.mkdir bin\standalone\zlib if not exist "bin\standalone\zlib\\" mkdir "bin\standalone\zlib" common.mkdir bin\standalone\zlib\mock if not exist "bin\standalone\zlib\mock\\" mkdir "bin\standalone\zlib\mock" common.mkdir bin\standalone\zlib\mock\debug if not exist "bin\standalone\zlib\mock\debug\\" mkdir "bin\standalone\zlib\mock\debug" mock.compile.c bin\standalone\zlib\mock\debug\deflate.obj C:\Python27\python.exe mock.py -c -x c -IC:\Users\chhenning\AppData\Local\Temp\tmpyit5yg\zlib C:\Users\chhenning\AppData\Local\Temp\tmpyit5yg\zlib\deflate.c -o bin\standalone\zlib\mock\debug\deflate.obj Unrecognized command: mock.py -c -x c -IC:\Users\chhenning\AppData\Local\Temp\tmpyit5yg\zlib C:\Users\chhenning\AppData\Local\Temp\tmpyit5yg\zlib\deflate.c -o bin\standalone\zlib\mock\debug\deflate.obj ...skipped <pbin\standalone\zlib\mock\debug>z.dll for lack of <pbin\standalone\zlib\mock\debug>deflate.obj... common.mkdir bin\standalone\zlib\mock\debug\link-static if not exist "bin\standalone\zlib\mock\debug\link-static\\" mkdir "bin\standalone\zlib\mock\debug\link-static" mock.compile.c bin\standalone\zlib\mock\debug\link-static\deflate.obj C:\Python27\python.exe mock.py -c -x c -IC:\Users\chhenning\AppData\Local\Temp\tmpyit5yg\zlib C:\Users\chhenning\AppData\Local\Temp\tmpyit5yg\zlib\deflate.c -o bin\standalone\zlib\mock\debug\link-static\deflate.obj Unrecognized command: mock.py -c -x c -IC:\Users\chhenning\AppData\Local\Temp\tmpyit5yg\zlib C:\Users\chhenning\AppData\Local\Temp\tmpyit5yg\zlib\deflate.c -o bin\standalone\zlib\mock\debug\link-static\deflate.obj ...skipped <pbin\standalone\zlib\mock\debug\link-static>libz.lib for lack of <pbin\standalone\zlib\mock\debug\link-static>deflate.obj... ...failed updating 2 targets... failure {{{ "['c:\\boost\\tools\\build\\v2\\test\\../engine\\bin.ntx86\\bjam', '-sBOOST_BUILD_PATH="c:\\boost\\tools\\build\\v2\\test/.."', '-d+2', 'toolset=mock', '--ignore-site-config', '--user-config=', '--test-config="c:\\boost\\tools\\build\\v2\\test\\test-config.jam"', '--ignore-toolset-requirements']" returned 1 }}} reason {{{ unexpected status returned by bjam }}} changes caused by the last build command {{{ Added files : ['markup.pyc', 'mockinfo.pyc', 'bin/config.log', 'bin/project-cache.jam'] Removed files : [] Modified files: [] Touched files : [] }}} STDOUT {{{ common.mkdir bin if not exist "bin\\" mkdir "bin" common.mkdir bin\standalone if not exist "bin\standalone\\" mkdir "bin\standalone" common.mkdir bin\standalone\zlib if not exist "bin\standalone\zlib\\" mkdir "bin\standalone\zlib" common.mkdir bin\standalone\zlib\mock if not exist "bin\standalone\zlib\mock\\" mkdir "bin\standalone\zlib\mock" common.mkdir bin\standalone\zlib\mock\debug if not exist "bin\standalone\zlib\mock\debug\\" mkdir "bin\standalone\zlib\mock\debug" mock.compile.c bin\standalone\zlib\mock\debug\deflate.obj C:\Python27\python.exe mock.py -c -x c -IC:\Users\chhenning\AppData\Local\Temp\tmpyit5yg\zlib C:\Users\chhenning\AppData\Local\Temp\tmpyit5yg\zlib\deflate.c -o bin\standalone\zlib\mock\debug\deflate.obj Unrecognized command: mock.py -c -x c -IC:\Users\chhenning\AppData\Local\Temp\tmpyit5yg\zlib C:\Users\chhenning\AppData\Local\Temp\tmpyit5yg\zlib\deflate.c -o bin\standalone\zlib\mock\debug\deflate.obj ...skipped <pbin\standalone\zlib\mock\debug>z.dll for lack of <pbin\standalone\zlib\mock\debug>deflate.obj... common.mkdir bin\standalone\zlib\mock\debug\link-static if not exist "bin\standalone\zlib\mock\debug\link-static\\" mkdir "bin\standalone\zlib\mock\debug\link-static" mock.compile.c bin\standalone\zlib\mock\debug\link-static\deflate.obj C:\Python27\python.exe mock.py -c -x c -IC:\Users\chhenning\AppData\Local\Temp\tmpyit5yg\zlib C:\Users\chhenning\AppData\Local\Temp\tmpyit5yg\zlib\deflate.c -o bin\standalone\zlib\mock\debug\link-static\deflate.obj Unrecognized command: mock.py -c -x c -IC:\Users\chhenning\AppData\Local\Temp\tmpyit5yg\zlib C:\Users\chhenning\AppData\Local\Temp\tmpyit5yg\zlib\deflate.c -o bin\standalone\zlib\mock\debug\link-static\deflate.obj ...skipped <pbin\standalone\zlib\mock\debug\link-static>libz.lib for lack of <pbin\standalone\zlib\mock\debug\link-static>deflate.obj... ...failed updating 2 targets... }}} STDERR {{{ }}} stacktrace {{{ at line 590 of c:\boost\tools\build\v2\test\BoostBuild.py (fail_test) from line 485 of c:\boost\tools\build\v2\test\BoostBuild.py (run_build_system) from line 32 of zlib.py (<module>) }}} I think there is still something off. Christian
AMDG On 04/07/2013 03:31 PM, Christian Henning wrote:
Ok, I updated trunk and rerun. This is the output now:
<snip>
mock.compile.c bin\standalone\zlib\mock\debug\deflate.obj
C:\Python27\python.exe mock.py -c -x c -IC:\Users\chhenning\AppData\Local\Temp\tmpyit5yg\zlib C:\Users\chhenning\AppData\Local\Temp\tmpyit5yg\zlib\deflate.c -o bin\standalone\zlib\mock\debug\deflate.obj
The path normalization I used must not work on Windows. I'll get to this tomorrow unless you feel like looking into it earlier. search for abspath in MockToolset.py In Christ, Steven Watanabe
On Sun, Apr 7, 2013 at 6:52 PM, Steven Watanabe <watanabesj@gmail.com>wrote:
AMDG
On 04/07/2013 03:31 PM, Christian Henning wrote:
Ok, I updated trunk and rerun. This is the output now:
<snip>
mock.compile.c bin\standalone\zlib\mock\debug\deflate.obj
C:\Python27\python.exe mock.py -c -x c -IC:\Users\chhenning\AppData\Local\Temp\tmpyit5yg\zlib C:\Users\chhenning\AppData\Local\Temp\tmpyit5yg\zlib\deflate.c -o bin\standalone\zlib\mock\debug\deflate.obj
The path normalization I used must not work on Windows. I'll get to this tomorrow unless you feel like looking into it earlier. search for abspath in MockToolset.py
It can wait until tomorrow. Thanks for your help! Christian
AMDG On 04/07/2013 03:57 PM, Christian Henning wrote:
On Sun, Apr 7, 2013 at 6:52 PM, Steven Watanabe <watanabesj@gmail.com>wrote:
The path normalization I used must not work on Windows. I'll get to this tomorrow unless you feel like looking into it earlier. search for abspath in MockToolset.py
It can wait until tomorrow.
I think I've fixed it now. In Christ, Steven Watanabe
The path normalization I used must not work on Windows.
I'll get to this tomorrow unless you feel like looking into it earlier. search for abspath in MockToolset.py
It can wait until tomorrow.
I think I've fixed it now.
I think we are making process. The output now is:
c:\boost\tools\build\v2\test>python zlib.py --verbose msvc > out.txt c:\boost\tools\build\v2\test\../engine\bin.ntx86\bjam -sBOOST_BUILD_PATH="c:\boo st\tools\build\v2\test/.." -d+2 toolset=mock --ignore-site-config --user-config= --test-config="c:\boost\tools\build\v2\test\test-config.jam" --ignore-toolset-r equirements Traceback (most recent call last): File "zlib.py", line 32, in <module> t.run_build_system() File "c:\boost\tools\build\v2\test\BoostBuild.py", line 457, in run_build_syst em apply(TestCmd.TestCmd.run, [self], kw) File "c:\boost\tools\build\v2\test\TestCmd.py", line 409, in run universal_newlines=universal_newlines) File "C:\Python27\lib\subprocess.py", line 679, in __init__ errread, errwrite) File "C:\Python27\lib\subprocess.py", line 896, in _execute_child startupinfo) WindowsError: [Error 2] The system cannot find the file specified I have double checked and subprocess.py does exist. Not sure what file is missing? Christian
AMDG On 04/08/2013 11:40 AM, Christian Henning wrote:
I think we are making process. The output now is:
c:\boost\tools\build\v2\test>python zlib.py --verbose msvc > out.txt c:\boost\tools\build\v2\test\../engine\bin.ntx86\bjam -sBOOST_BUILD_PATH="c:\boo st\tools\build\v2\test/.." -d+2 toolset=mock --ignore-site-config --user-config= --test-config="c:\boost\tools\build\v2\test\test-config.jam" --ignore-toolset-r equirements <snip> WindowsError: [Error 2] The system cannot find the file specified
I have double checked and subprocess.py does exist. Not sure what file is missing?
It's complaining about bjam. Can you run other tests? In Christ, Steven Watanabe
On Tue, Apr 9, 2013 at 10:17 AM, Steven Watanabe <watanabesj@gmail.com>wrote:
AMDG
On 04/08/2013 11:40 AM, Christian Henning wrote:
I think we are making process. The output now is:
c:\boost\tools\build\v2\test>python zlib.py --verbose msvc > out.txt c:\boost\tools\build\v2\test\../engine\bin.ntx86\bjam -sBOOST_BUILD_PATH="c:\boo st\tools\build\v2\test/.." -d+2 toolset=mock --ignore-site-config --user-config= --test-config="c:\boost\tools\build\v2\test\test-config.jam" --ignore-toolset-r equirements <snip> WindowsError: [Error 2] The system cannot find the file specified
I have double checked and subprocess.py does exist. Not sure what file is missing?
It's complaining about bjam. Can you run other tests?
What other tests? You mean of the boost build process? Located here: C:\boost\tools\build\v2\test I'll try later at home. Christian
It's complaining about bjam. Can you run other tests?
Here are some output I get when running some other tests: c:\boost\tools\build\v2\test>python test1.py --verbose msvc Traceback (most recent call last): File "test1.py", line 17, in <module> t.run_build_system("-ftest.jam", stdout="Hi\n") File "c:\boost\tools\build\v2\test\BoostBuild.py", line 419, in run_build_syst em assert extra_args.__class__ is not str AssertionError ---------------------------- c:\boost\tools\build\v2\test>python message.py --verbose msvc c:\boost\tools\build\v2\test\../engine\bin.ntx86\bjam -sBOOST_BUILD_PATH="c:\boo st\tools\build\v2\test/.." -d+2 test toolset=msvc --ignore-toolset-requirements STDOUT {{{ }}} STDERR {{{ }}} Traceback (most recent call last): File "message.py", line 33, in <module> """) File "c:\boost\tools\build\v2\test\BoostBuild.py", line 457, in run_build_syst em apply(TestCmd.TestCmd.run, [self], kw) File "c:\boost\tools\build\v2\test\TestCmd.py", line 409, in run universal_newlines=universal_newlines) File "C:\Python27\lib\subprocess.py", line 679, in __init__ errread, errwrite) File "C:\Python27\lib\subprocess.py", line 896, in _execute_child startupinfo) WindowsError: [Error 2] The system cannot find the file specified So, I'm not sure. Has this test facility ever been used on Windows? Any idea what could be missing? Thanks, Christian
AMDG On 04/09/2013 05:25 PM, Christian Henning wrote:
Here are some output I get when running some other tests:
c:\boost\tools\build\v2\test>python test1.py --verbose msvc Traceback (most recent call last): File "test1.py", line 17, in <module> t.run_build_system("-ftest.jam", stdout="Hi\n") File "c:\boost\tools\build\v2\test\BoostBuild.py", line 419, in run_build_syst em assert extra_args.__class__ is not str AssertionError
<snip>
So, I'm not sure. Has this test facility ever been used on Windows? Any idea what could be missing?
I've run the tests on Windows, though not recently. This is actually failing earlier than before for you, so it looks like a new problem. Wild guess: are you using a different version of python than you were before? In Christ, Steven Watanabe
On Tue, Apr 9, 2013 at 11:34 PM, Steven Watanabe <watanabesj@gmail.com>wrote:
AMDG
On 04/09/2013 05:25 PM, Christian Henning wrote:
Here are some output I get when running some other tests:
c:\boost\tools\build\v2\test>python test1.py --verbose msvc Traceback (most recent call last): File "test1.py", line 17, in <module> t.run_build_system("-ftest.jam", stdout="Hi\n") File "c:\boost\tools\build\v2\test\BoostBuild.py", line 419, in run_build_syst em assert extra_args.__class__ is not str AssertionError
<snip>
So, I'm not sure. Has this test facility ever been used on Windows? Any idea what could be missing?
I've run the tests on Windows, though not recently. This is actually failing earlier than before for you, so it looks like a new problem. Wild guess: are you using a different version of python than you were before?
No, I haven't changed python in a long time. Anything else I could try? Christian
AMDG On 04/10/2013 01:11 PM, Christian Henning wrote:
On Tue, Apr 9, 2013 at 11:34 PM, Steven Watanabe <watanabesj@gmail.com>wrote:
On 04/09/2013 05:25 PM, Christian Henning wrote:
Here are some output I get when running some other tests:
c:\boost\tools\build\v2\test>python test1.py --verbose msvc Traceback (most recent call last): File "test1.py", line 17, in <module> t.run_build_system("-ftest.jam", stdout="Hi\n") File "c:\boost\tools\build\v2\test\BoostBuild.py", line 419, in run_build_syst em assert extra_args.__class__ is not str AssertionError
Apparently test1 is broken. Don't use it.
<snip>
So, I'm not sure. Has this test facility ever been used on Windows? Any idea what could be missing?
I've run the tests on Windows, though not recently. This is actually failing earlier than before for you, so it looks like a new problem. Wild guess: are you using a different version of python than you were before?
No, I haven't changed python in a long time. Anything else I could try?
I have no idea, why you're getting this behavior now. The code that's causing the problem hasn't changed for a long time. Anyway, I've just committed a fix. In Christ, Steven Watanabe
Hi Steven,
Apparently test1 is broken. Don't use it.
Which test should I try?
<snip>
So, I'm not sure. Has this test facility ever been used on Windows? Any idea what could be missing?
I've run the tests on Windows, though not recently. This is actually failing earlier than before for you, so it looks like a new problem. Wild guess: are you using a different version of python than you were before?
No, I haven't changed python in a long time. Anything else I could try?
I have no idea, why you're getting this behavior now. The code that's causing the problem hasn't changed for a long time. Anyway, I've just committed a fix.
Ok, I have updated my boost trunk and rebuild bjam. BTW, do I have to build the libs to run the boost build tests? Christian
AMDG On 04/11/2013 04:31 PM, Christian Henning wrote:
Hi Steven,
Apparently test1 is broken. Don't use it.
Which test should I try?
Anything listed in test_all.py should work.
Ok, I have updated my boost trunk and rebuild bjam. BTW, do I have to build the libs to run the boost build tests?
No. Boost.Build doesn't depend on anything else. In Christ, Steven Watanabe
On Thu, Apr 11, 2013 at 10:16 PM, Steven Watanabe <watanabesj@gmail.com>wrote:
AMDG
On 04/11/2013 04:31 PM, Christian Henning wrote:
Hi Steven,
Apparently test1 is broken. Don't use it.
Which test should I try?
Anything listed in test_all.py should work.
I'll try again tonight. But do you have any idea for what I should look for when something isn't working? I know I can run normal python programs. So it has to do something with the test cases..
Christian
Anything listed in test_all.py should work.
I'll try again tonight. But do you have any idea for what I should look
for when something isn't working? I know I can run normal python programs. So it has to do something with the test cases..
So I run test_all.py. Here is the stdout: http://pastebin.com/PtjKvdgb and here is the stderr: http://pastebin.com/V6CF0uFK It's somewhat funny that zlib.py is the only test passing. Does that maybe ring a bell? Regards, Christian
AMDG On 04/13/2013 07:23 AM, Christian Henning wrote:
Anything listed in test_all.py should work.
I'll try again tonight. But do you have any idea for what I should look
for when something isn't working? I know I can run normal python programs. So it has to do something with the test cases..
So I run test_all.py. Here is the stdout:
and here is the stderr:
It's somewhat funny that zlib.py is the only test passing. Does that maybe ring a bell?
Unfortunately, test_all.py doesn't show the actual errors. The tests appear to be passing for the Windows test runners: http://www.boost.org/development/tests/trunk/developer/build.html Can you try core_language.py? It's the most basic test. If it fails, I wouldn't expect anything to work. In Christ, Steven Watanabe
On Sat, Apr 13, 2013 at 10:44 AM, Steven Watanabe <watanabesj@gmail.com>wrote:
AMDG
Anything listed in test_all.py should work.
I'll try again tonight. But do you have any idea for what I should look
for when something isn't working? I know I can run normal python
On 04/13/2013 07:23 AM, Christian Henning wrote: programs.
So it has to do something with the test cases..
So I run test_all.py. Here is the stdout:
and here is the stderr:
It's somewhat funny that zlib.py is the only test passing. Does that maybe ring a bell?
Unfortunately, test_all.py doesn't show the actual errors. The tests appear to be passing for the Windows test runners: http://www.boost.org/development/tests/trunk/developer/build.html Can you try core_language.py? It's the most basic test. If it fails, I wouldn't expect anything to work.
According to the output the error happens testcmd.py at line 409. I added some debug code: sys.stdout.write( "CHH: " + str( cmd ) + "\n") sys.stdout.write( "CHH: " + chdir + "\n") sys.stdout.write( "CHH: " + str( universal_newlines ) + "\n") and the output is: c:\boost\tools\build\v2\test>python core_language.py CHH: ['c:\\boost\\tools\\build\\v2\\test\\..\\engine\\bin.ntx86\\bjam', '-sBOOST _BUILD_PATH="c:\\boost\\tools\\build\\v2\\test/.."', '-d0', '--quiet', '-ftest.j am', '--test-config="c:\\boost\\tools\\build\\v2\\test\\test-config.jam"', '--ig nore-toolset-requirements'] CHH: c:\users\chhenn~1\appdata\local\temp\tmpnz6dv4 CHH: True Does that look reasonable?
AMDG On 04/13/2013 08:16 AM, Christian Henning wrote:
On Sat, Apr 13, 2013 at 10:44 AM, Steven Watanabe <watanabesj@gmail.com>wrote:
According to the output the error happens testcmd.py at line 409. I added some debug code:
sys.stdout.write( "CHH: " + str( cmd ) + "\n") sys.stdout.write( "CHH: " + chdir + "\n") sys.stdout.write( "CHH: " + str( universal_newlines ) + "\n")
and the output is: c:\boost\tools\build\v2\test>python core_language.py CHH: ['c:\\boost\\tools\\build\\v2\\test\\..\\engine\\bin.ntx86\\bjam', '-sBOOST _BUILD_PATH="c:\\boost\\tools\\build\\v2\\test/.."', '-d0', '--quiet', '-ftest.j am', '--test-config="c:\\boost\\tools\\build\\v2\\test\\test-config.jam"', '--ig nore-toolset-requirements'] CHH: c:\users\chhenn~1\appdata\local\temp\tmpnz6dv4 CHH: True
Does that look reasonable?
The command looks okay. The only thing I can think of is that Python doesn't like the short path for chdir. What happens if you change the argument of Popen to cwd=os.path.realpath(chdir)? In Christ, Steven Watanabe
On Sat, Apr 13, 2013 at 11:36 AM, Steven Watanabe <watanabesj@gmail.com>wrote:
AMDG
On 04/13/2013 08:16 AM, Christian Henning wrote:
On Sat, Apr 13, 2013 at 10:44 AM, Steven Watanabe <watanabesj@gmail.com wrote:
According to the output the error happens testcmd.py at line 409. I added some debug code:
sys.stdout.write( "CHH: " + str( cmd ) + "\n") sys.stdout.write( "CHH: " + chdir + "\n") sys.stdout.write( "CHH: " + str( universal_newlines ) + "\n")
and the output is: c:\boost\tools\build\v2\test>python core_language.py CHH: ['c:\\boost\\tools\\build\\v2\\test\\..\\engine\\bin.ntx86\\bjam', '-sBOOST _BUILD_PATH="c:\\boost\\tools\\build\\v2\\test/.."', '-d0', '--quiet', '-ftest.j am', '--test-config="c:\\boost\\tools\\build\\v2\\test\\test-config.jam"', '--ig nore-toolset-requirements'] CHH: c:\users\chhenn~1\appdata\local\temp\tmpnz6dv4 CHH: True
Does that look reasonable?
The command looks okay. The only thing I can think of is that Python doesn't like the short path for chdir. What happens if you change the argument of Popen to cwd=os.path.realpath(chdir)?
chdir is a short path? It looks like a full path to me. Anyway, I tried the realpath thing and it's the same result.
AMDG On 04/13/2013 08:16 AM, Christian Henning wrote:
On Sat, Apr 13, 2013 at 10:44 AM, Steven Watanabe <watanabesj@gmail.com>wrote:
<snip>
and the output is: c:\boost\tools\build\v2\test>python core_language.py CHH: ['c:\\boost\\tools\\build\\v2\\test\\..\\engine\\bin.ntx86\\bjam', <snip>
Does that look reasonable?
Wait. Maybe python is wants it to be bjam*.exe* In Christ, Steven Watanabe
On Sat, Apr 13, 2013 at 11:42 AM, Steven Watanabe <watanabesj@gmail.com>wrote:
AMDG
On 04/13/2013 08:16 AM, Christian Henning wrote:
On Sat, Apr 13, 2013 at 10:44 AM, Steven Watanabe <watanabesj@gmail.com wrote:
<snip>
and the output is: c:\boost\tools\build\v2\test>python core_language.py CHH: ['c:\\boost\\tools\\build\\v2\\test\\..\\engine\\bin.ntx86\\bjam', <snip>
Does that look reasonable?
Wait. Maybe python is wants it to be bjam*.exe*
So instead of: c:\\boost\\tools\\build\\v2\\test\\..\\engine\\bin.ntx86\\bjam it should be c:\\boost\\tools\\build\\v2\\test\\..\\engine\\bin.ntx86\\bjam*.exe* What line would need to be changed?
Wait. Maybe python is wants it to be bjam*.exe*
So instead of:
c:\\boost\\tools\\build\\v2\\test\\..\\engine\\bin.ntx86\\bjam
it should be
c:\\boost\\tools\\build\\v2\\test\\..\\engine\\bin.ntx86\\bjam*.exe*
What line would need to be changed?
Ok, in boostbuild.py I changed: executable="bjam" to executable="bjam*.exe*" with the same result.
Ok, I just made one step further. In TestCmd.py when calling Popen I added 'shell = True': p = subprocess.Popen(cmd, stdin=subprocess.PIPE, stdout=subprocess.PIPE, stderr=subprocess.PIPE, cwd=chdir, universal_newlines=universal_newlines, shell = True) Now my output looks like: stdout: failure {{{ "['c:\\boost\\tools\\build\\v2\\test\\..\\engine\\bin.ntx86\\bjam.exe', '-sBOOST_BUILD_PATH="c:\\boost\\tools\\build\\v2\\test/.."', '-d0', '--quiet', '-ftest.jam', '--test-config="c:\\boost\\tools\\build\\v2\\test\\test-config.jam"', '--ignore-toolset-requirements']" returned 1 }}} reason {{{ unexpected status returned by bjam }}} changes caused by the last build command {{{ Added files : [] Removed files : [] Modified files: [] Touched files : [] }}} STDOUT {{{ }}} STDERR {{{ 'c:\boost\tools\build\v2\test\..\engine\bin.ntx86\bjam.exe' is not recognized as an internal or external command, operable program or batch file. }}} stacktrace {{{ at line 590 of c:\boost\tools\build\v2\test\BoostBuild.py (fail_test) from line 485 of c:\boost\tools\build\v2\test\BoostBuild.py (run_build_system) from line 11 of core_language.py (<module>) }}}
Now my output looks like:
stdout:
failure {{{ "['c:\\boost\\tools\\build\\v2\\test\\..\\engine\\bin.ntx86\\bjam.exe', '-sBOOST_BUILD_PATH="c:\\boost\\tools\\build\\v2\\test/.."', '-d0', '--quiet', '-ftest.jam', '--test-config="c:\\boost\\tools\\build\\v2\\test\\test-config.jam"', '--ignore-toolset-requirements']" returned 1 }}} reason {{{ unexpected status returned by bjam }}} changes caused by the last build command {{{ Added files : [] Removed files : [] Modified files: [] Touched files : []
}}} STDOUT {{{
}}} STDERR {{{ 'c:\boost\tools\build\v2\test\..\engine\bin.ntx86\bjam.exe' is not recognized as an internal or external command, operable program or batch file.
}}} stacktrace {{{ at line 590 of c:\boost\tools\build\v2\test\BoostBuild.py (fail_test) from line 485 of c:\boost\tools\build\v2\test\BoostBuild.py (run_build_system) from line 11 of core_language.py (<module>)
}}}
Turns out I built x64 bjam which lies in
C:\boost\tools\build\v2\engine\bin.ntx86_64 but the test script wanted C:\boost\tools\build\v2\engine\bin.ntx86 Now that is fixed. The output is: failure {{{ "['c:\\boost\\tools\\build\\v2\\test\\..\\engine\\bin.ntx86\\bjam.exe', '-sBOOST_BUILD_PATH="c:\\boost\\tools\\build\\v2\\test/.."', '-d0', '--quiet', '-ftest.jam', '--test-config="c:\\boost\\tools\\build\\v2\\test\\test-config.jam"', '--ignore-toolset-requirements']" returned 1 }}} reason {{{ unexpected status returned by bjam }}} changes caused by the last build command {{{ Added files : [] Removed files : [] Modified files: [] Touched files : [] }}} STDOUT {{{ error: [ control enum hardware profiles services ] != [ control enum hardware profiles services deleted device ids ] error: [ control enum hardware profiles services ] != [ control enum hardware profiles services deleted device ids ] 414 passed 2 failed }}} STDERR {{{ }}} stacktrace {{{ at line 590 of c:\boost\tools\build\v2\test\BoostBuild.py (fail_test) from line 485 of c:\boost\tools\build\v2\test\BoostBuild.py (run_build_system) from line 11 of core_language.py (<module>) }}} I think we are closing in... :-) Christian
AMDG On 04/13/2013 09:44 AM, Christian Henning wrote:
Turns out I built x64 bjam which lies in
C:\boost\tools\build\v2\engine\bin.ntx86_64
but the test script wanted
C:\boost\tools\build\v2\engine\bin.ntx86
Now that is fixed.
Aha. The test script only checks that the directory bin.ntx86 exists. I'll try to improve the error handling.
The output is:
failure {{{ "['c:\\boost\\tools\\build\\v2\\test\\..\\engine\\bin.ntx86\\bjam.exe', '-sBOOST_BUILD_PATH="c:\\boost\\tools\\build\\v2\\test/.."', '-d0', '--quiet', '-ftest.jam', '--test-config="c:\\boost\\tools\\build\\v2\\test\\test-config.jam"', '--ignore-toolset-requirements']" returned 1 }}} reason {{{ unexpected status returned by bjam }}} changes caused by the last build command {{{ Added files : [] Removed files : [] Modified files: [] Touched files : []
}}} STDOUT {{{ error: [ control enum hardware profiles services ] != [ control enum hardware profiles services deleted device ids ] error: [ control enum hardware profiles services ] != [ control enum hardware profiles services deleted device ids ] 414 passed 2 failed
Fixed. In Christ, Steven Watanabe
error: [ control enum hardware profiles services ] != [ control enum
hardware profiles services deleted device ids ] error: [ control enum hardware profiles services ] != [ control enum hardware profiles services deleted device ids ] 414 passed 2 failed
Fixed.
So I updated the trunk and rebuild bjam ( the correct one! ) and rerun core_language.py. I don't think anything changed. The output is:
failure {{{ "['c:\\boost\\tools\\build\\v2\\test\\..\\engine\\bin.ntx86\\bjam', '-sBOOST_BUILD_PATH="c:\\boost\\tools\\build\\v2\\test/.."', '-d0', '--quiet', '-ftest.jam', '--test-config="c:\\boost\\tools\\build\\v2\\test\\test-config.jam"', '--ignore-toolset-requirements']" returned 1 }}} reason {{{ unexpected status returned by bjam }}} changes caused by the last build command {{{ Added files : [] Removed files : [] Modified files: [] Touched files : [] }}} STDOUT {{{ error: [ control enum hardware profiles services ] != [ control enum hardware profiles services deleted device ids ] error: [ control enum hardware profiles services ] != [ control enum hardware profiles services deleted device ids ] 414 passed 2 failed }}} STDERR {{{ }}} stacktrace {{{ at line 590 of c:\boost\tools\build\v2\test\BoostBuild.py (fail_test) from line 485 of c:\boost\tools\build\v2\test\BoostBuild.py (run_build_system) from line 11 of core_language.py (<module>) }}} BTW, I reverted back all changes I did, regarding "bjam.exe" and "shell=True". Christian
AMDG On 04/13/2013 10:21 AM, Christian Henning wrote:
error: [ control enum hardware profiles services ] != [ control enum
hardware profiles services deleted device ids ] error: [ control enum hardware profiles services ] != [ control enum hardware profiles services deleted device ids ] 414 passed 2 failed
Fixed.
So I updated the trunk and rebuild bjam ( the correct one! ) and rerun core_language.py. I don't think anything changed. The output is:
The fix was to the test case. Are you sure that you the test case was updated? I explicitly deleted the extra values from the set.
<snip> STDOUT {{{ error: [ control enum hardware profiles services ] != [ control enum hardware profiles services deleted device ids ] error: [ control enum hardware profiles services ] != [ control enum hardware profiles services deleted device ids ] 414 passed 2 failed
In Christ, Steven Watanabe
So I updated the trunk and rebuild bjam ( the correct one! ) and rerun
core_language.py. I don't think anything changed. The output is:
The fix was to the test case. Are you sure that you the test case was updated? I explicitly deleted the extra values from the set.
I just deleted the whole c:/boost/tools/build/v2/test folder and retrieved it back from the repository and rerun with the same result. What file did you change?
AMDG On 04/13/2013 10:46 AM, Christian Henning wrote:
So I updated the trunk and rebuild bjam ( the correct one! ) and rerun
core_language.py. I don't think anything changed. The output is:
The fix was to the test case. Are you sure that you the test case was updated? I explicitly deleted the extra values from the set.
I just deleted the whole c:/boost/tools/build/v2/test folder and retrieved it back from the repository and rerun with the same result. What file did you change?
core-language/test.jam boost\trunk\tools\build\v2>svn log test/core-language/test.jam --limit 1 ------------------------------------------------------------------------ r83875 | steven_watanabe | 2013-04-13 09:55:17 -0700 (Sat, 13 Apr 2013) | 1 line Add a few more cases. ------------------------------------------------------------------------ If this still doesn't work, just forget about it. I don't want to waste your time too much. You can use builtin_echo.py to validate the test harness setup, instead. In Christ, Steven Watanabe
AMDG On 04/13/2013 10:46 AM, Christian Henning wrote:
So I updated the trunk and rebuild bjam ( the correct one! ) and rerun
core_language.py. I don't think anything changed. The output is:
The fix was to the test case. Are you sure that you the test case was updated? I explicitly deleted the extra values from the set.
I just deleted the whole c:/boost/tools/build/v2/test folder and retrieved it back from the repository and rerun with the same result. What file did you change?
Doh! Try it now. In Christ, Steven Watanabe
Now we can go back to zlib.py.
There seems to be a problem with zlib.py. I'm looking at that file at you seem to hardcode the zlib source code to: using zlib: : <source>$(here)/zlib ; In my user-config.jam my zlib is configured as: using zlib : 1.2.5 : <source>C:/chhenning/zlib/zlib-1.2.5 : ; So, a file like deflate.c would is located here: C:/chhenning/zlib/zlib-1.2.5/deflate.c Here is the output when I run the test using the --verbose parameter: common.mkdir bin if not exist "bin\\" mkdir "bin" common.mkdir bin\standalone if not exist "bin\standalone\\" mkdir "bin\standalone" common.mkdir bin\standalone\zlib if not exist "bin\standalone\zlib\\" mkdir "bin\standalone\zlib" common.mkdir bin\standalone\zlib\mock if not exist "bin\standalone\zlib\mock\\" mkdir "bin\standalone\zlib\mock" common.mkdir bin\standalone\zlib\mock\debug if not exist "bin\standalone\zlib\mock\debug\\" mkdir "bin\standalone\zlib\mock\debug" mock.compile.c bin\standalone\zlib\mock\debug\deflate.obj C:\Python27\python.exe mock.py -c -x c -IC:\Users\chhenning\AppData\Local\Temp\tmpsiqfhe\zlib C:\Users\chhenning\AppData\Local\Temp\tmpsiqfhe\zlib\deflate.c -o bin\standalone\zlib\mock\debug\deflate.obj Unrecognized command: mock.py -c -x c -IC:\Users\chhenning\AppData\Local\Temp\tmpsiqfhe\zlib C:\Users\chhenning\AppData\Local\Temp\tmpsiqfhe\zlib\deflate.c -o bin\standalone\zlib\mock\debug\deflate.obj ...skipped <pbin\standalone\zlib\mock\debug>z.dll for lack of <pbin\standalone\zlib\mock\debug>deflate.obj... common.mkdir bin\standalone\zlib\mock\debug\link-static if not exist "bin\standalone\zlib\mock\debug\link-static\\" mkdir "bin\standalone\zlib\mock\debug\link-static" mock.compile.c bin\standalone\zlib\mock\debug\link-static\deflate.obj C:\Python27\python.exe mock.py -c -x c -IC:\Users\chhenning\AppData\Local\Temp\tmpsiqfhe\zlib C:\Users\chhenning\AppData\Local\Temp\tmpsiqfhe\zlib\deflate.c -o bin\standalone\zlib\mock\debug\link-static\deflate.obj Unrecognized command: mock.py -c -x c -IC:\Users\chhenning\AppData\Local\Temp\tmpsiqfhe\zlib C:\Users\chhenning\AppData\Local\Temp\tmpsiqfhe\zlib\deflate.c -o bin\standalone\zlib\mock\debug\link-static\deflate.obj ...skipped <pbin\standalone\zlib\mock\debug\link-static>libz.lib for lack of <pbin\standalone\zlib\mock\debug\link-static>deflate.obj... ...failed updating 2 targets... failure {{{ "['c:\\boost\\tools\\build\\v2\\test\\..\\engine\\bin.ntx86\\bjam', '-sBOOST_BUILD_PATH="c:\\boost\\tools\\build\\v2\\test/.."', '-d+2', 'toolset=mock', '--ignore-site-config', '--user-config=', '--test-config="c:\\boost\\tools\\build\\v2\\test\\test-config.jam"', '--ignore-toolset-requirements']" returned 1 }}} reason {{{ unexpected status returned by bjam }}} changes caused by the last build command {{{ Added files : ['markup.pyc', 'mockinfo.pyc', 'bin/config.log', 'bin/project-cache.jam'] Removed files : [] Modified files: [] Touched files : [] }}} STDOUT {{{ common.mkdir bin if not exist "bin\\" mkdir "bin" common.mkdir bin\standalone if not exist "bin\standalone\\" mkdir "bin\standalone" common.mkdir bin\standalone\zlib if not exist "bin\standalone\zlib\\" mkdir "bin\standalone\zlib" common.mkdir bin\standalone\zlib\mock if not exist "bin\standalone\zlib\mock\\" mkdir "bin\standalone\zlib\mock" common.mkdir bin\standalone\zlib\mock\debug if not exist "bin\standalone\zlib\mock\debug\\" mkdir "bin\standalone\zlib\mock\debug" mock.compile.c bin\standalone\zlib\mock\debug\deflate.obj C:\Python27\python.exe mock.py -c -x c -IC:\Users\chhenning\AppData\Local\Temp\tmpsiqfhe\zlib C:\Users\chhenning\AppData\Local\Temp\tmpsiqfhe\zlib\deflate.c -o bin\standalone\zlib\mock\debug\deflate.obj Unrecognized command: mock.py -c -x c -IC:\Users\chhenning\AppData\Local\Temp\tmpsiqfhe\zlib C:\Users\chhenning\AppData\Local\Temp\tmpsiqfhe\zlib\deflate.c -o bin\standalone\zlib\mock\debug\deflate.obj ...skipped <pbin\standalone\zlib\mock\debug>z.dll for lack of <pbin\standalone\zlib\mock\debug>deflate.obj... common.mkdir bin\standalone\zlib\mock\debug\link-static if not exist "bin\standalone\zlib\mock\debug\link-static\\" mkdir "bin\standalone\zlib\mock\debug\link-static" mock.compile.c bin\standalone\zlib\mock\debug\link-static\deflate.obj C:\Python27\python.exe mock.py -c -x c -IC:\Users\chhenning\AppData\Local\Temp\tmpsiqfhe\zlib C:\Users\chhenning\AppData\Local\Temp\tmpsiqfhe\zlib\deflate.c -o bin\standalone\zlib\mock\debug\link-static\deflate.obj Unrecognized command: mock.py -c -x c -IC:\Users\chhenning\AppData\Local\Temp\tmpsiqfhe\zlib C:\Users\chhenning\AppData\Local\Temp\tmpsiqfhe\zlib\deflate.c -o bin\standalone\zlib\mock\debug\link-static\deflate.obj ...skipped <pbin\standalone\zlib\mock\debug\link-static>libz.lib for lack of <pbin\standalone\zlib\mock\debug\link-static>deflate.obj... ...failed updating 2 targets... }}} STDERR {{{ }}} stacktrace {{{ at line 590 of c:\boost\tools\build\v2\test\BoostBuild.py (fail_test) from line 485 of c:\boost\tools\build\v2\test\BoostBuild.py (run_build_system) from line 32 of zlib.py (<module>) }}} When I look in the temp folder ( C:\Users\chhenning\AppData\Local\Temp\tmpsiqfhe\ ) there is no zlib subfolder nor any other file/folder. Anything you can spot what is going wrong? BTW, I think I used you too much of your time today and I can understand when you got better things to do. We can continue any time that's convenient for you. Regards, Christian
AMDG On 04/13/2013 01:30 PM, Christian Henning wrote:
Now we can go back to zlib.py.
There seems to be a problem with zlib.py. I'm looking at that file at you seem to hardcode the zlib source code to:
That's intentional. The test case creates something that resembles a zlib installation, to avoid depending on anything system specific.
<snip> mock.compile.c bin\standalone\zlib\mock\debug\deflate.obj
C:\Python27\python.exe mock.py -c -x c -IC:\Users\chhenning\AppData\Local\Temp\tmpsiqfhe\zlib C:\Users\chhenning\AppData\Local\Temp\tmpsiqfhe\zlib\deflate.c -o bin\standalone\zlib\mock\debug\deflate.obj
Unrecognized command: mock.py -c -x c -IC:\Users\chhenning\AppData\Local\Temp\tmpsiqfhe\zlib C:\Users\chhenning\AppData\Local\Temp\tmpsiqfhe\zlib\deflate.c -o bin\standalone\zlib\mock\debug\deflate.obj ...skipped <pbin\standalone\zlib\mock\debug>z.dll for lack of <pbin\standalone\zlib\mock\debug>deflate.obj... common.mkdir bin\standalone\zlib\mock\debug\link-static
This means that I still don't have the path comparison right. I've just set up an XP virtual machine and tracked down the problem. os.path.abspath is using short paths, but the argument is a long path, so they don't compare equal.
<snip>
When I look in the temp folder ( C:\Users\chhenning\AppData\Local\Temp\tmpsiqfhe\ ) there is no zlib subfolder nor any other file/folder.
The temp directory gets deleted. If you want to see what's going on use --preserve.
Anything you can spot what is going wrong?
BTW, I think I used you too much of your time today and I can understand when you got better things to do. We can continue any time that's convenient for you.
It's not a problem. In Christ, Steven Watanabe
This means that I still don't have the path comparison right. I've just set up an XP virtual machine and tracked down the problem. os.path.abspath is using short paths, but the argument is a long path, so they don't compare equal.
I see. I'll run again when you found the error.
<snip>
When I look in the temp folder ( C:\Users\chhenning\AppData\Local\Temp\tmpsiqfhe\ ) there is no zlib subfolder nor any other file/folder.
The temp directory gets deleted. If you want to see what's going on use --preserve.
I run
python zlib.py --verbose --preserve msvc and still there are no files in the tmp folder.
Anything you can spot what is going wrong?
BTW, I think I used you too much of your time today and I can understand when you got better things to do. We can continue any time that's convenient for you.
It's not a problem.
Thanks! Very much appreciated! Christian
AMDG On 04/13/2013 02:45 PM, Christian Henning wrote:
This means that I still don't have the path comparison right. I've just set up an XP virtual machine and tracked down the problem. os.path.abspath is using short paths, but the argument is a long path, so they don't compare equal.
I see. I'll run again when you found the error.
Should be fixed now--at least it works for me. In Christ, Steven Watanabe
I see. I'll run again when you found the error.
Should be fixed now--at least it works for me.
Ok, I updated the trunk and rebuild bjam. So when I run: python zlib.py msvc I get this: failure {{{ "['c:\\boost\\tools\\build\\v2\\test\\..\\engine\\bin.ntx86\\bjam', '-sBOOST_BUILD_PATH="c:\\boost\\tools\\build\\v2\\test/.."', '-d0', '--quiet', 'toolset=mock', '--ignore-site-config', '--user-config=', '--test-config="c:\\boost\\tools\\build\\v2\\test\\test-config.jam"', '--ignore-toolset-requirements']" returned 1 }}} reason {{{ unexpected status returned by bjam }}} changes caused by the last build command {{{ Added files : ['bin/config.log', 'bin/project-cache.jam', 'bin/standalone/ac/main.cpp', 'bin/standalone/ac/zlib.h.cpp'] Removed files : [] Modified files: [] Touched files : [] }}} STDOUT {{{ Performing configuration checks - zlib : no - zlib : no ...skipped <pbin\mock\debug>test.exe for lack of <pbin\mock\debug>test.obj... ...skipped <pbin\mock\debug\link-static>test.exe for lack of <pbin\mock\debug\link-static>test.obj... ...failed updating 2 targets... }}} STDERR {{{ }}} stacktrace {{{ at line 590 of c:\boost\tools\build\v2\test\BoostBuild.py (fail_test) from line 485 of c:\boost\tools\build\v2\test\BoostBuild.py (run_build_system) from line 61 of zlib.py (<module>) }}} I cannot find the test-config.jam in my boost folder but there is test-config-example.jam. Did you miss to commit that file? When I run in the verbose mode the output is: common.mkdir bin if not exist "bin\\" mkdir "bin" common.mkdir bin\standalone if not exist "bin\standalone\\" mkdir "bin\standalone" common.mkdir bin\standalone\zlib if not exist "bin\standalone\zlib\\" mkdir "bin\standalone\zlib" common.mkdir bin\standalone\zlib\mock if not exist "bin\standalone\zlib\mock\\" mkdir "bin\standalone\zlib\mock" common.mkdir bin\standalone\zlib\mock\debug if not exist "bin\standalone\zlib\mock\debug\\" mkdir "bin\standalone\zlib\mock\debug" mock.compile.c bin\standalone\zlib\mock\debug\deflate.obj set JAM_CWD=C:\Users\chhenning\AppData\Local\Temp\tmpvcr27d C:\Python27\python.exe mock.py -c -x c -I"C:\Users\chhenning\AppData\Local\Temp\tmpvcr27d\zlib" "C:\Users\chhenning\AppData\Local\Temp\tmpvcr27d\zlib\deflate.c" -o "bin\standalone\zlib\mock\debug\deflate.obj" mock.link.dll bin\standalone\zlib\mock\debug\libz.dll set JAM_CWD=C:\Users\chhenning\AppData\Local\Temp\tmpvcr27d C:\Python27\python.exe mock.py --dll "bin\standalone\zlib\mock\debug\deflate.obj" -o "bin\standalone\zlib\mock\debug\libz.dll" common.mkdir bin\standalone\zlib\mock\debug\link-static if not exist "bin\standalone\zlib\mock\debug\link-static\\" mkdir "bin\standalone\zlib\mock\debug\link-static" mock.compile.c bin\standalone\zlib\mock\debug\link-static\deflate.obj set JAM_CWD=C:\Users\chhenning\AppData\Local\Temp\tmpvcr27d C:\Python27\python.exe mock.py -c -x c -I"C:\Users\chhenning\AppData\Local\Temp\tmpvcr27d\zlib" "C:\Users\chhenning\AppData\Local\Temp\tmpvcr27d\zlib\deflate.c" -o "bin\standalone\zlib\mock\debug\link-static\deflate.obj" mock.archive bin\standalone\zlib\mock\debug\link-static\libz.a set JAM_CWD=C:\Users\chhenning\AppData\Local\Temp\tmpvcr27d C:\Python27\python.exe mock.py --archive "bin\standalone\zlib\mock\debug\link-static\deflate.obj" -o "bin\standalone\zlib\mock\debug\link-static\libz.a" Performing configuration checks - zlib : yes - zlib : yes common.mkdir bin\mock if not exist "bin\mock\\" mkdir "bin\mock" common.mkdir bin\mock\debug if not exist "bin\mock\debug\\" mkdir "bin\mock\debug" mock.compile.c++ bin\mock\debug\test.obj set JAM_CWD=C:\Users\chhenning\AppData\Local\Temp\tmpvcr27d C:\Python27\python.exe mock.py -c -x c++ "test.cpp" -o "bin\mock\debug\test.obj" mock.link bin\mock\debug\test.exe set JAM_CWD=C:\Users\chhenning\AppData\Local\Temp\tmpvcr27d C:\Python27\python.exe mock.py "bin\mock\debug\test.obj" -o "bin\mock\debug\test.exe" --static-lib=z common.mkdir bin\mock\debug\link-static if not exist "bin\mock\debug\link-static\\" mkdir "bin\mock\debug\link-static" mock.compile.c++ bin\mock\debug\link-static\test.obj set JAM_CWD=C:\Users\chhenning\AppData\Local\Temp\tmpvcr27d C:\Python27\python.exe mock.py -c -x c++ "test.cpp" -o "bin\mock\debug\link-static\test.obj" mock.link bin\mock\debug\link-static\test.exe set JAM_CWD=C:\Users\chhenning\AppData\Local\Temp\tmpvcr27d C:\Python27\python.exe mock.py "bin\mock\debug\link-static\test.obj" -o "bin\mock\debug\link-static\test.exe" --static-lib=z Performing configuration checks - zlib : yes - zlib : yes common.mkdir bin\mock if not exist "bin\mock\\" mkdir "bin\mock" common.mkdir bin\mock\debug if not exist "bin\mock\debug\\" mkdir "bin\mock\debug" mock.compile.c++ bin\mock\debug\test.obj set JAM_CWD=C:\Users\chhenning\AppData\Local\Temp\tmpvcr27d C:\Python27\python.exe mock.py -c -x c++ "test.cpp" -o "bin\mock\debug\test.obj" mock.link bin\mock\debug\test.exe set JAM_CWD=C:\Users\chhenning\AppData\Local\Temp\tmpvcr27d C:\Python27\python.exe mock.py "bin\mock\debug\test.obj" -o "bin\mock\debug\test.exe" --shared-lib=z common.mkdir bin\mock\debug\link-static if not exist "bin\mock\debug\link-static\\" mkdir "bin\mock\debug\link-static" mock.compile.c++ bin\mock\debug\link-static\test.obj set JAM_CWD=C:\Users\chhenning\AppData\Local\Temp\tmpvcr27d C:\Python27\python.exe mock.py -c -x c++ "test.cpp" -o "bin\mock\debug\link-static\test.obj" mock.link bin\mock\debug\link-static\test.exe set JAM_CWD=C:\Users\chhenning\AppData\Local\Temp\tmpvcr27d C:\Python27\python.exe mock.py "bin\mock\debug\link-static\test.obj" -o "bin\mock\debug\link-static\test.exe" --shared-lib=z Performing configuration checks - zlib : yes - zlib : yes common.mkdir bin\mock if not exist "bin\mock\\" mkdir "bin\mock" common.mkdir bin\mock\debug if not exist "bin\mock\debug\\" mkdir "bin\mock\debug" mock.compile.c++ bin\mock\debug\test.obj set JAM_CWD=C:\Users\chhenning\AppData\Local\Temp\tmpvcr27d C:\Python27\python.exe mock.py -c -x c++ -I"C:\Users\chhenning\AppData\Local\Temp\tmpvcr27d\zlib" "test.cpp" -o "bin\mock\debug\test.obj" mock.link bin\mock\debug\test.exe set JAM_CWD=C:\Users\chhenning\AppData\Local\Temp\tmpvcr27d C:\Python27\python.exe mock.py "bin\mock\debug\test.obj" -o "bin\mock\debug\test.exe" -L"C:\Users\chhenning\AppData\Local\Temp\tmpvcr27d\zlib" --static-lib=myzlib common.mkdir bin\mock\debug\link-static if not exist "bin\mock\debug\link-static\\" mkdir "bin\mock\debug\link-static" mock.compile.c++ bin\mock\debug\link-static\test.obj set JAM_CWD=C:\Users\chhenning\AppData\Local\Temp\tmpvcr27d C:\Python27\python.exe mock.py -c -x c++ -I"C:\Users\chhenning\AppData\Local\Temp\tmpvcr27d\zlib" "test.cpp" -o "bin\mock\debug\link-static\test.obj" mock.link bin\mock\debug\link-static\test.exe set JAM_CWD=C:\Users\chhenning\AppData\Local\Temp\tmpvcr27d C:\Python27\python.exe mock.py "bin\mock\debug\link-static\test.obj" -o "bin\mock\debug\link-static\test.exe" -L"C:\Users\chhenning\AppData\Local\Temp\tmpvcr27d\zlib" --static-lib=myzlib Performing configuration checks - zlib : yes - zlib : yes common.mkdir bin\mock if not exist "bin\mock\\" mkdir "bin\mock" common.mkdir bin\mock\debug if not exist "bin\mock\debug\\" mkdir "bin\mock\debug" mock.compile.c++ bin\mock\debug\test.obj set JAM_CWD=C:\Users\chhenning\AppData\Local\Temp\tmpvcr27d C:\Python27\python.exe mock.py -c -x c++ -I"C:\Users\chhenning\AppData\Local\Temp\tmpvcr27d\zlib" "test.cpp" -o "bin\mock\debug\test.obj" mock.link bin\mock\debug\test.exe set JAM_CWD=C:\Users\chhenning\AppData\Local\Temp\tmpvcr27d C:\Python27\python.exe mock.py "bin\mock\debug\test.obj" -o "bin\mock\debug\test.exe" -L"C:\Users\chhenning\AppData\Local\Temp\tmpvcr27d\zlib" --shared-lib=myzlib common.mkdir bin\mock\debug\link-static if not exist "bin\mock\debug\link-static\\" mkdir "bin\mock\debug\link-static" mock.compile.c++ bin\mock\debug\link-static\test.obj set JAM_CWD=C:\Users\chhenning\AppData\Local\Temp\tmpvcr27d C:\Python27\python.exe mock.py -c -x c++ -I"C:\Users\chhenning\AppData\Local\Temp\tmpvcr27d\zlib" "test.cpp" -o "bin\mock\debug\link-static\test.obj" mock.link bin\mock\debug\link-static\test.exe set JAM_CWD=C:\Users\chhenning\AppData\Local\Temp\tmpvcr27d C:\Python27\python.exe mock.py "bin\mock\debug\link-static\test.obj" -o "bin\mock\debug\link-static\test.exe" -L"C:\Users\chhenning\AppData\Local\Temp\tmpvcr27d\zlib" --shared-lib=myzlib Christian
AMDG On 04/14/2013 02:36 PM, Christian Henning wrote:
I see. I'll run again when you found the error.
Should be fixed now--at least it works for me.
Ok, I updated the trunk and rebuild bjam. So when I run:
You shouldn't actually need to rebuild bjam. This is just a matter of getting the test harness working.
<snip> STDOUT {{{ Performing configuration checks
- zlib : no - zlib : no ...skipped <pbin\mock\debug>test.exe for lack of <pbin\mock\debug>test.obj... ...skipped <pbin\mock\debug\link-static>test.exe for lack of <pbin\mock\debug\link-static>test.obj... ...failed updating 2 targets...
}}} <snip>
I cannot find the test-config.jam in my boost folder but there is test-config-example.jam. Did you miss to commit that file?
test-config.jam doesn't need to exist. If it exists, it overrides user-config.jam.
When I run in the verbose mode the output is:
What's odd is that the errors don't appear with --verbose. Did you get all the output? Does it fail consistently without --verbose?
common.mkdir bin <snip>
In Christ, Steven Watanabe
When I run in the verbose mode the output is:
What's odd is that the errors don't appear with --verbose. Did you get all the output? Does it fail consistently without --verbose?
The complete stdout is here: http://pastebin.com/SLdDgkZf The complete stderr is here: http://pastebin.com/dFJLGRq8 I run python zlib.py msvc 10 times and it seems to work occasionally. Meaning no console output was produced. Here is the order: 1) fail 2) success 3) success 4) fail 5) success 6) fail 7) fail 8) success 9) fail 10) fail It seems random to me. Christian
AMDG On 04/14/2013 04:13 PM, Christian Henning wrote:
When I run in the verbose mode the output is:
What's odd is that the errors don't appear with --verbose. Did you get all the output? Does it fail consistently without --verbose?
The complete stdout is here:
Ugh. Not very helpful. I can't reproduce this here, either. I've just added a lot more debugging output with --verbose. Can you get the new output?
The complete stderr is here:
I run
python zlib.py msvc
10 times and it seems to work occasionally. Meaning no console output was produced. Here is the order:
1) fail 2) success 3) success 4) fail 5) success 6) fail 7) fail 8) success 9) fail 10) fail
It seems random to me.
In Christ, Steven Watanabe
The complete stdout is here:
Ugh. Not very helpful. I can't reproduce this here, either. I've just added a lot more debugging output with --verbose. Can you get the new output?
Ok, after work today I'll rerun the test.
Christian
On Mon, Apr 15, 2013 at 12:42 PM, Christian Henning <chhenning@gmail.com>wrote:
The complete stdout is here:
Ugh. Not very helpful. I can't reproduce this here, either. I've just added a lot more debugging output with --verbose. Can you get the new output?
the stdout is here: http://pastebin.com/uuQdckT1 and stderr is here: http://pastebin.com/65sjjyb6
AMDG On 04/15/2013 05:28 PM, Christian Henning wrote:
the stdout is here:
and stderr is here:
It would help a little more to see the output from a /failed/ run. In Christ, Steven Watanabe
On Mon, Apr 15, 2013 at 8:38 PM, Steven Watanabe <watanabesj@gmail.com>wrote:
AMDG
On 04/15/2013 05:28 PM, Christian Henning wrote:
the stdout is here:
and stderr is here:
It would help a little more to see the output from a /failed/ run.
Sorry I thought it failed due to: Failed to match input file contents: $test.cpp etc. I think this one failed: http://pastebin.com/kgQkBxKz
AMDG On 04/15/2013 05:45 PM, Christian Henning wrote:
Sorry I thought it failed due to:
Failed to match input file contents: $test.cpp etc.
I think this one failed:
Aha. I think I know what the problem is. The .pyc file isn't getting updated after the new .py file is written. The resolution must be too low on the timestamps that Python is using. See if my last commit fixes this. In Christ, Steven Watanabe
On Mon, Apr 15, 2013 at 9:33 PM, Steven Watanabe <watanabesj@gmail.com>wrote:
AMDG
On 04/15/2013 05:45 PM, Christian Henning wrote:
Sorry I thought it failed due to:
Failed to match input file contents: $test.cpp etc.
I think this one failed:
Aha. I think I know what the problem is. The .pyc file isn't getting updated after the new .py file is written. The resolution must be too low on the timestamps that Python is using. See if my last commit fixes this.
I think it looks good now! stdout seems to be consisted to: http://pastebin.com/BtKReYJR Looks like we got out the kinks. The next step is to create tests for the remaining 3rd party libs. Thank you very much! Christian
On Sat, Apr 13, 2013 at 12:00 PM, Christian Henning <chhenning@gmail.com>wrote:
Wait. Maybe python is wants it to be bjam*.exe*
So, I changed subprocess.py to print out all parameters for _execute_child(...)
sys.stdout.write( "CHH - executable: " + str( executable ) + "\n") sys.stdout.write( "CHH - preexec_fn: " + str( preexec_fn ) + "\n") sys.stdout.write( "CHH - close_fds: " + str( close_fds ) + "\n") sys.stdout.write( "CHH - cwd: " + str( cwd ) + "\n") sys.stdout.write( "CHH - env: " + str( env ) + "\n") sys.stdout.write( "CHH - universal_newlines: " + str( universal_newlines ) + "\n") sys.stdout.write( "CHH - startupinfo: " + str( startupinfo ) + "\n") sys.stdout.write( "CHH - creationflags: " + str( creationflags ) + "\n") sys.stdout.write( "CHH - shell: " + str( shell ) + "\n") sys.stdout.write( "CHH - p2cread: " + str( p2cread ) + "\n") sys.stdout.write( "CHH - p2cwrite: " + str( p2cwrite ) + "\n") sys.stdout.write( "CHH - c2pread: " + str( c2pread ) + "\n") sys.stdout.write( "CHH - c2pwrite: " + str( c2pwrite ) + "\n") sys.stdout.write( "CHH - errread: " + str( errread ) + "\n") sys.stdout.write( "CHH - errwrite: " + str( errwrite ) + "\n") and the output is: CHH - executable: None CHH - preexec_fn: None CHH - close_fds: False CHH - cwd: c:\users\chhenn~1\appdata\local\temp\tmpvcfvdv CHH - env: None CHH - universal_newlines: True CHH - startupinfo: None CHH - creationflags: 0 CHH - shell: False CHH - p2cread: <_subprocess_handle object at 0x0041B360> CHH - p2cwrite: <_subprocess_handle object at 0x0041B310> CHH - c2pread: <_subprocess_handle object at 0x0041B350> CHH - c2pwrite: <_subprocess_handle object at 0x0041B380> CHH - errread: <_subprocess_handle object at 0x0041B320> CHH - errwrite: <_subprocess_handle object at 0x0041B3A0> I'm not sure what that all means but don't you think the shell parameter should be True? Christian
Have you considered including the pixel division operation? Best. On 29 Mar 2013 17:45, "Steven Watanabe" <watanabesj@gmail.com> wrote:
AMDG
On 03/29/2013 09:27 AM, Christian Henning wrote:
is it ok? The merge would include io, toolbox, numerics and some other changes to gil's code itself.
Your test suite for io is not being run. I disabled it because it broke the regression tests. You seem to be using Boost.Build extensions which are not in the trunk.
In Christ, Steven Watanabe
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Hello! Do you plan to add the library gil.io into boost 1.54? 2013/3/29 Christian Henning <chhenning@gmail.com>
Hi,
is it ok? The merge would include io, toolbox, numerics and some other changes to gil's code itself.
Regards, Christian
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- С уважением, Владислав Щапов ICQ: 223-695-654
participants (6)
-
Christian Henning -
Harg Tholan -
Jürgen Hunold -
Michael Marcin -
Steven Watanabe -
Владислав Щапов