Boost logo

Boost Testing :

From: David Abrahams (dave_at_[hidden])
Date: 2005-08-22 09:38:45

David Abrahams <dave_at_[hidden]> writes:

> Aleksey Gurtovoy <agurtovoy_at_[hidden]> writes:
>> David Abrahams writes:
>>> Aleksey Gurtovoy <agurtovoy_at_[hidden]> writes:
>>>> make a wrapper toolset file which includes the version and
>>>> platform information in its name and place it in the same directory
>>>> with "".
>>> This technique isn't working for me. Neither is
>>> "--bjam-options=-sBOOST_BUILD_PATH=/path/to/my/toolset/file".
>>> In both cases bjam reports that the toolset isn't found.
>> Does it work for you if you copy the bjam command line from the
>> '' log and execute it on its own (from the script's
>> directory)?
> Kinda hard to do that since IIRC the image of boost gets cleaned up
> for me after the build fails. If I get a moment I'll look again.

I guess IDRC.

>> If not, either the command line is wrong, or something in
>> bjam is broken.

The command line is wrong. You're using Unix-style path separators (":")
instead of windows-style (";") in setting up BOOST_BUILD_PATH.

python -c "import os ; help(os.path)"

  Help on module ntpath:

      ntpath - Common pathname manipulations, WindowsNT/95 version.



      __all__ = ['normcase', 'isabs', 'join', 'splitdrive', 'split', 'splite...
      altsep = '/'
      curdir = '.'
      defpath = r'.;C:\bin'
      devnull = 'nul'
      extsep = '.'
      pardir = '..'
      pathsep = ';'
      sep = r'\'
      supports_unicode_filenames = True

I'd try to fix it myself, but I honestly don't know how multiple path
elements get into the bjam command line, from looking at the code:

  def bjam_command( toolsets ):
      build_path = regression_root
      if build_path[-1] == '\\': build_path += '\\'
      result = '"%s" "-sBOOST_BUILD_PATH=%s" "-sBOOST_ROOT=%s"'\
        % (
            tool_path( bjam )
          , build_path
          , boost_root
Unless regression_root is somehow a list of paths(?)...

>> In either case, you are more qualified to say which
>> one it is ;).

Not this time ;)

>>> So now I'm wondering how to use my own toolset.
>>> Aside: I found it surprising that downloads the tarball
>>> into the directory where the script is, rather than into the current
>>> directory when it was invoked. At least, that's what it says it's
>>> doing ;-)
>> Yep, that's what it's doing. Why did you find it surprising? After
>> all, the first line of the installation docs says:
>> * Download regression driver from here
>> ( and put it in the directory where you
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> want all the regression test files to be placed.
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> It's just a slightly surprising design decision from my POV because I
> always have an image of Boost lying around. The "obvious" interface
> would have be doing cd $(TEMP) followed by python
> $(BOOST_ROOT)/status/xsl_reports/runner/

Also, let me point out, there isn't much precedent for the location of
the script being a factor unless it's part of a larger package and
needs to find its brethren. There's nothing *wrong* with the current
behavior per-se, but well, my expectations were for something
different, and I got it wrong the first few times. Just an
ease-of-use datapoint.

Dave Abrahams
Boost Consulting

Boost-testing list run by mbergal at