Boost C++ Libraries: Ticket #4667: boost-build: configuration of toolset gcc does not enforce requested versions and accepts non-existing commands

attachment set

mhassert@… — Tue, 21 Sep 2010 13:37:01 GMT

attachment → tools_gcc.jam.patch

Patch for configuration of toolset gcc

attachment set

mhassert@… — Tue, 21 Sep 2010 15:36:02 GMT

attachment → tools_gcc.jam_v2.patch

Second version of patch. Fixed tool search on windows.

mhassert@… — Tue, 21 Sep 2010 15:40:55 GMT

My first patch failed to find tools on windows. I attached a fixed version tools_gcc.jam_v2.patch.

type changed

Vladimir Prus — Wed, 22 Sep 2010 05:54:59 GMT

type Bugs → Patches

Vladimir Prus — Mon, 27 Sep 2010 16:05:52 GMT

(In [65633]) Add verification on gcc version and command.

Most importantly, if version is specified and command is not, check for g++-$version and failing that, check if g++ -dumpversion returns the version we've asked about.

Patch from Moritz Hassert. Addresses #4667.

status changed; resolution set

Vladimir Prus — Mon, 27 Sep 2010 16:39:47 GMT

status new → closed
resolution → fixed

(In [65640]) Relax the check between user-specified version and the one from 'g++'.

Fixes #4667.

Vladimir Prus — Mon, 27 Sep 2010 16:42:58 GMT

Moritz,

thank you for the patch. I've checked in your patch. While playing with it I've noticed that the comparison between user-provided version and gcc output is pretty strict. If you specify '4.4', then the comparison fails because "g++ -dumpversion" reports 4.4.5. Since gcc developers don't even include the minor version in the binary name, this seems too strict check so I've checked in a follow-up patch to relax it.

Thanks again, Volodya

mhassert@… — Mon, 27 Sep 2010 17:27:47 GMT

Hi Volodya,

thanks for accepting the patch and fixing the version comparison. It was indeed too strict.

Now that I looked at the code again, I see another problem:

At the moment, specifying a command without a path and without ".exe" suffix does not work on Windows, because check-tool-aux() in common.jam auto-appends ".exe" only when the given command features a path. Omitting only one of path or .exe should to work. (I can't test right now.)

This behavior of check-tool-aux() seems kind of strange to me.

Passing the user specified command as the second argument in line 73 would work in case of omitted path but won't work for commands with a path. At least as far as I understand the rule find-tool().

Moritz

Vladimir Prus — Tue, 28 Sep 2010 06:31:35 GMT

Moritz,

I agree that logic is somewhat strange. We should first compose a list of suffixes to try, and then use on both branches. The reason we have two branches, I think, is to avoid doing GLOB when a directory is explicitly specified. I am not sure whether ther performance hit of GLOB is worth this trouble.

Are you interested in fixing this, or shall I try next time I get to windows?

mhassert@… — Tue, 28 Sep 2010 15:17:52 GMT

Volodya,

I'm afraid I'm not sure exactly how to fix it. A few thoughts / questions:

Why does find-tool use "path.glob" while check-tool-aux uses "GLOB"? Is there a difference?
What's the check-tool wrapper for?
Should check-tool-aux convert the path with path.native like find-tool does?
The rules find-tool() and check-tool-aux() should be merged somehow because it seems find-tool does basically the same as the else part of check-tool-aux. And if we allow .bat and .cmd in check-tool-aux it should be allowed in find-tool, too.