bjam bug? iostreams + zlib won't build for VC8 or MinGW with small hack to Jamfile.v2

[brian.pratt@…]

In boost_1_35_0\libs\iostreams\build\Jamfile.v2 I find I have to change

if $(NO_COMPRESSION)

$(NO_$(LIB))

to

if $(NO_COMPRESSION) = 1

$(NO_$(LIB)) = 1

to get VC8 or MinGW building with zlib. This is with bjam -v Boost.Jam Version 3.1.16. OS=NT.

[brian.pratt@…]

hacked iostreams Jamfile.v2 that allows zlib use in VC8 and MinGW

[Vladimir Prus]

Can you provide a little bit more explanations? On NT, we already set NO_$(LIB) to 1 a few lines earlier, unless you provide the path to the zlib source. So, what exactly are you doing, how it works, and how you want it to work.

Also, please provide changes as unified diff against SVN HEAD, if possible.

[brian.pratt@…]

I notice a typo in the bug description, I meant to say "without small hack", of course. Oops.

Near as I can tell the problem is that when NO_ZLIB is defined to 0 it still triggers the logic, as if it's an ifdef instead of an if, if you see what I mean.

Here's my change as a unified diff against trunk as requested:

--- Jamfile.orig Tue Jun 3 11:52:46 2008 +++ Jamfile.v2 Thu May 29 07:58:30 2008 @@ -55,7 +55,8 @@

modules.poke : NO_$(LIB) : 1 ;

}

if $(NO_COMPRESSION)

$(NO_$(LIB))

+ # bpratt added the = 1 tests here to get zlib working in MinGW and VC8

+ if $(NO_COMPRESSION) = 1

$(NO_$(LIB)) = 1

{

if $(debug) {

@@ -141,7 +142,6 @@

[René Rivera]

Replying to brian.pratt@insilicos.com:

Near as I can tell the problem is that when NO_ZLIB is defined to 0 it still triggers the logic, as if it's an ifdef instead of an if, if you see what I mean.

AFAICT, this is intentional in the iostreams Jamfile. And it doesn't set them to "0" anywhere I can see. How are you seeing it being set to "0"?

[brian.pratt@…]

Since NO_ZLIB defaults to 1 for VC8 and MinGW, it's necessary to set it to 0 at the bjam commandline (-sNO_ZLIB=0). My experience, though, was that this didn't work, and that the test as written seemed to act more as an "ifdef NO_ZLIB". If the test is rewritten to check explicitly for value "1" it acts as required and the zlib build is enabled. It's as if bjam has forgotten the difference between a boolean (zero vs everything else) and an ifdef (undefined vs everything else).

[Vladimir Prus]

By my reading of the code, NO_ZLIB will be set to 1, if you're on Windows, and have not set both ZLIB_SOURCE and ZLIB_INCLUDE. If you set NO_ZLIB=0 on command line and do not set ZLIB_SOURCE and ZLIB_INCLUDE, zlib won't be used anyway. And if you do set ZLIB_SOURCE and ZLIB_INCLUDE, zlib should be used without any other option. So, back to original question -- what exactly are you doing (exact command line), and what effect you see?

[brian.pratt@…]

bjam -toolset=msvc "-sNO_ZLIB=0" -sZLIB_SOURCE="/zlib123-dll" --build-type=complete --without-python --without-mpi stage

I tried various permutations of ZLIB_SOURCE, ZLIB_INCLUDE etc (docs are exceedingly murky on this), this commandline together with the patch is the one that results in zlib being enabled. Everything else gave the default no zlib behavior.

[alessandro_vergani]

The problem happens also with VC9. I think it is a problem with bjam because if I place in the jamfile.v2 a simple test like:

if 0 {

ECHO "Error" ;

}

the test always succeeds and the error string is diplayed.

Explicitly comparing for equality with 1 solves the problem.

[Vladimir Prus]

(In [52168]) Check if value of NO_COMPRESSION/NO_ZLIB is 0 or 1.

Originally, only presence of these variables was checked. Unfortunately, iostreams documentation said, incorrectly, that NO_ZLIB and NO_BZIP2 default to 1 on Windows, which caused some users to pass NO_ZLIB=0 explicitly, together with other variables,thereby still disabling zlib.

This match makes Jamfile forgiving of this error.

Fixes #1967.