Need some help running library tests

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Need some help running library tests

Boost - Build mailing list
Dear Boost.Build experts,

I do have Boost 1.69 and was able to build boost from the sources with
Mingw-w64 gcc 8.1 on Windows 7. That was for boost itself, but now I need to
build the tests for the Boost library Spirit (the parser). I cannot get this
to work. To be more precise it's the Github develop version of that library.

My Boost.Build version is 2018.02-git.

According to Boost.Build documentation paragraph 3.3 Configuration, the
option "b2 --debug-configuration" gives info how my boost.build is
configured.

In the folder <boost-build>\example\hello the output of
 "b2 --debug-configuration" looks fine. So boost build seems to be setup
properly.

But when I run from the folder <boost-spirit-develop>\test
"b2 --debug-configuration" the output contains:
error: Could not find parent for project at '.'.

So in the folder <boost-spirit-develop>\test I rename Jamfile to
Jamroot.jam. Now with "b2 --debug-configuration" I get: output.txt
(attachtment of this email)

Also when I try to build the tests I get the same error messages, strarting
from:
config.jam: No such file or directory

How do I solve this?

Best regards,
Maarten Verhage

_______________________________________________
Unsubscribe & other changes: https://lists.boost.org/mailman/listinfo.cgi/boost-build

output.txt (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Need some help running library tests

Boost - Build mailing list
On 7/30/2019 10:00 AM, Maarten Verhage via Boost-build wrote:
> Dear Boost.Build experts,
>
> I do have Boost 1.69 and was able to build boost from the sources with
> Mingw-w64 gcc 8.1 on Windows 7. That was for boost itself, but now I need to
> build the tests for the Boost library Spirit (the parser). I cannot get this
> to work. To be more precise it's the Github develop version of that library.

What does building Boost in version 1.69 using gcc-8.1 have to do with
running the latest Spirit 'develop branch tests using gcc-8.1 ?

I have successfully run the latest Spirit 'develop' branch tests using
mingw-w64/gcc-8.1 on Windows 10, both in 32-bit and 64-bit mode. All
tests pass.

Here are the things I think you need to do to do this:

1) Get the latest Boost from Github into a directory and then run these
comamnds from that directory:
2) git checkout develop
3) git pull
4) get submodule update --init
5) git submodule foreach --recursive git checkout develop
6) git submodule foreach --recursive git pull
7) ./bootstrap.bat to create the latest b2
8) ./b2 headers
10) cd to the Spirit test directory
11) ../../../b2 toolset=gcc-8.1 etc.

The last step needs an appropriate entry for the gcc-8.1 toolset in your
user-config.jam. My user-config.jam entry for running gcc-8.1 in 32-bit
mode is:

using gcc : 8.1 :
     "E:/programming/bat/cp_gcc81.bat" :
     <cxxflags>-Wno-unused-local-typedefs
     <cxxflags>-ftrack-macro-expansion=0
     <cxxflags>-Wno-unused-variable
     <cxxflags>-D_GLIBCXX_USE_CXX11_ABI=1
 
<root>"C:/Utilities/mingw-w64/i686-8.1.0-posix-dwarf-rt_v6-rev0/mingw32" ;

where "E:/programming/bat/cp_gcc81.bat" is:

@echo off
set
PATH=C:\Utilities\mingw-w64\i686-8.1.0-posix-dwarf-rt_v6-rev0\mingw32\bin;%PATH%
g++ %*

I have always found that a mingw-w64/gcc bin directory must be in the
Windows PATH or else gcc on Windows can not find what it needs. I have a
similarly appropriate gcc entry for 64-bit mode using the 64-bit version
of mingw-w64/gcc. I have a sneeking suspicion that the 64-bit version of
mingw-w64/gcc can do both the 32-bit and 64-bit compiles.

I do hope that you are not telling me that you are trying to run the
Spirit test in Boost 1.69 by using the latest 'develop" Spirit and the
latest 'develop' Boost Build/b2 somehow. I assume you know that you
should never mix up versions of Boost libraries/Boost Build between
different Boost distributions.

I hope this helps, but I can only reflect what succeeds for me.

>
> My Boost.Build version is 2018.02-git.
>
> According to Boost.Build documentation paragraph 3.3 Configuration, the
> option "b2 --debug-configuration" gives info how my boost.build is
> configured.
>
> In the folder <boost-build>\example\hello the output of
>   "b2 --debug-configuration" looks fine. So boost build seems to be setup
> properly.
>
> But when I run from the folder <boost-spirit-develop>\test
> "b2 --debug-configuration" the output contains:
> error: Could not find parent for project at '.'.
>
> So in the folder <boost-spirit-develop>\test I rename Jamfile to
> Jamroot.jam. Now with "b2 --debug-configuration" I get: output.txt
> (attachtment of this email)
>
> Also when I try to build the tests I get the same error messages, strarting
> from:
> config.jam: No such file or directory
>
> How do I solve this?

_______________________________________________
Unsubscribe & other changes: https://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|

Re: Need some help running library tests

Boost - Build mailing list
On 7/30/2019 6:14 PM, Edward Diener via Boost-build wrote:

> On 7/30/2019 10:00 AM, Maarten Verhage via Boost-build wrote:
>> Dear Boost.Build experts,
>>
>> I do have Boost 1.69 and was able to build boost from the sources with
>> Mingw-w64 gcc 8.1 on Windows 7. That was for boost itself, but now I
>> need to
>> build the tests for the Boost library Spirit (the parser). I cannot
>> get this
>> to work. To be more precise it's the Github develop version of that
>> library.
>
> What does building Boost in version 1.69 using gcc-8.1 have to do with
> running the latest Spirit 'develop branch tests using gcc-8.1 ?
>
> I have successfully run the latest Spirit 'develop' branch tests using
> mingw-w64/gcc-8.1 on Windows 10, both in 32-bit and 64-bit mode. All
> tests pass.
>
> Here are the things I think you need to do to do this:
>
> 1) Get the latest Boost from Github into a directory and then run these
> comamnds from that directory:
> 2) git checkout develop
> 3) git pull
> 4) get submodule update --init
> 5) git submodule foreach --recursive git checkout develop
> 6) git submodule foreach --recursive git pull
> 7) ./bootstrap.bat to create the latest b2
> 8) ./b2 headers
> 10) cd to the Spirit test directory
> 11) ../../../b2 toolset=gcc-8.1 etc.
>
> The last step needs an appropriate entry for the gcc-8.1 toolset in your
> user-config.jam. My user-config.jam entry for running gcc-8.1 in 32-bit
> mode is:
>
> using gcc : 8.1 :
>      "E:/programming/bat/cp_gcc81.bat" :
>      <cxxflags>-Wno-unused-local-typedefs
>      <cxxflags>-ftrack-macro-expansion=0
>      <cxxflags>-Wno-unused-variable
>      <cxxflags>-D_GLIBCXX_USE_CXX11_ABI=1
>
> <root>"C:/Utilities/mingw-w64/i686-8.1.0-posix-dwarf-rt_v6-rev0/mingw32" ;

Should be:

using gcc : 8.1 :
     "$(TSE_BATCH_DRIVE)/programming/bat/cp_gcc81.bat" :
     <cxxflags>-Wno-unused-local-typedefs
     <cxxflags>-ftrack-macro-expansion=0
     <cxxflags>-Wno-unused-variable
     <cxxflags>-D_GLIBCXX_USE_CXX11_ABI=1
 
<root>"$(TSE_MINGW64_DRIVE)/Utilities/mingw-w64/i686-8.1.0-posix-dwarf-rt_v6-rev0/mingw32"

     ;
My use of "Paste As Quotation" in Thunderbird went awry in my first
response.

_______________________________________________
Unsubscribe & other changes: https://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|

Re: Need some help running library tests

Boost - Build mailing list
Hi Edward,

>> Here are the things I think you need to do to do this:
>>
>> 1) Get the latest Boost from Github into a directory and then run these
>> comamnds from that directory:
>> 2) git checkout develop
>> 3) git pull
>> 4) get submodule update --init
>> 5) git submodule foreach --recursive git checkout develop
>> 6) git submodule foreach --recursive git pull
>> 7) ./bootstrap.bat to create the latest b2
>> 8) ./b2 headers
>> 10) cd to the Spirit test directory
>> 11) ../../../b2 toolset=gcc-8.1 etc.

I prefered to continue using boost 1.69 as the main library. But I did a
Github clone of
just the Boost-build develop library and did the above steps on that.

>>
>> The last step needs an appropriate entry for the gcc-8.1 toolset in your
>> user-config.jam. My user-config.jam entry for running gcc-8.1 in 32-bit
>> mode is:

The mingw-w64 library I use is x86_64-8.1.0-release-win32-seh-rt_v6-rev0.
In the bootstrap build of boost-build I switched temporarily to the
posix-seh variant (this has to do with thread support). But the build of b2
was succesful.

I do have a problem with the last part of your instructions. The only
user-config.jam file is located in the folder <path-to-boost-build>\example,
do you mean I use that one somehow? Additionally for the mingw-w64 version I
use I don't have a cp_gcc81.bat file.

If I run b2 now in the spirit\test folder I still get the:
config.jam: No such file of directory
followed be the same stuff as output.txt in the attachment of my first post
here.

Are you willing to explain a bit more on what is happening? Then you can
give me a chance to apply my own judgement as how to attack this problem. As
I'm now under the impression that this new b2.exe file is not solving
anything.

> using gcc : 8.1 :
>     "$(TSE_BATCH_DRIVE)/programming/bat/cp_gcc81.bat" :
>     <cxxflags>-Wno-unused-local-typedefs
>     <cxxflags>-ftrack-macro-expansion=0
>     <cxxflags>-Wno-unused-variable
>     <cxxflags>-D_GLIBCXX_USE_CXX11_ABI=1
>
> <root>"$(TSE_MINGW64_DRIVE)/Utilities/mingw-w64/i686-8.1.0-posix-dwarf-rt_v6-rev0/mingw32"
>     ;

 Regards, Maarten

_______________________________________________
Unsubscribe & other changes: https://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|

Re: Need some help running library tests

Boost - Build mailing list
On 7/31/2019 1:06 PM, Maarten Verhage via Boost-build wrote:

> Hi Edward,
>
>>> Here are the things I think you need to do to do this:
>>>
>>> 1) Get the latest Boost from Github into a directory and then run these
>>> comamnds from that directory:
>>> 2) git checkout develop
>>> 3) git pull
>>> 4) get submodule update --init
>>> 5) git submodule foreach --recursive git checkout develop
>>> 6) git submodule foreach --recursive git pull
>>> 7) ./bootstrap.bat to create the latest b2
>>> 8) ./b2 headers
>>> 10) cd to the Spirit test directory
>>> 11) ../../../b2 toolset=gcc-8.1 etc.
>
> I prefered to continue using boost 1.69 as the main library. But I did a
> Github clone of
> just the Boost-build develop library and did the above steps on that.

If you use Boost 1.69 as the distribution you want to test you must
build b2 for that distribution, and then use the version of b2 you
create to test the Spirit library in 1.69. This is what I meant by not
mixing Boost Build/b2 built in a particular Boost distribution with a
library in another distribution which you are trying to test. This can
be done because the './bootstrap.bat' command in Windows generates
'b2.exe' in the top-level directory of a distribution. It is asking for
trouble if you try to use a version of b2 created by one Boost
distribution to build/run tests for a different Boost distribution. Why
do it even if it might actually seem to work.

>
>>>
>>> The last step needs an appropriate entry for the gcc-8.1 toolset in your
>>> user-config.jam. My user-config.jam entry for running gcc-8.1 in 32-bit
>>> mode is:
>
> The mingw-w64 library I use is x86_64-8.1.0-release-win32-seh-rt_v6-rev0.
> In the bootstrap build of boost-build I switched temporarily to the
> posix-seh variant (this has to do with thread support). But the build of b2
> was succesful.
>
> I do have a problem with the last part of your instructions. The only
> user-config.jam file is located in the folder <path-to-boost-build>\example,
> do you mean I use that one somehow? Additionally for the mingw-w64 version I
> use I don't have a cp_gcc81.bat file.
>
> If I run b2 now in the spirit\test folder I still get the:
> config.jam: No such file of directory
> followed be the same stuff as output.txt in the attachment of my first post
> here.
>
> Are you willing to explain a bit more on what is happening? Then you can
> give me a chance to apply my own judgement as how to attack this problem. As
> I'm now under the impression that this new b2.exe file is not solving
> anything.
>
>> using gcc : 8.1 :
>>      "$(TSE_BATCH_DRIVE)/programming/bat/cp_gcc81.bat" :
>>      <cxxflags>-Wno-unused-local-typedefs
>>      <cxxflags>-ftrack-macro-expansion=0
>>      <cxxflags>-Wno-unused-variable
>>      <cxxflags>-D_GLIBCXX_USE_CXX11_ABI=1
>>
>> <root>"$(TSE_MINGW64_DRIVE)/Utilities/mingw-w64/i686-8.1.0-posix-dwarf-rt_v6-rev0/mingw32"
>>      ;

If you have mingw-w64/gcc-8.1 in your Windows PATH before any other
Windows gcc distribution you might have installed then you don't need a
user-config.jam entry for that toolset unless you want to also set
certain compilation/link options using a toolset definition.

In my particular case I have more than one mingw-w64/gcc distribution
installed ( fifteen versions actually, with 32bit and 64bit distros for
each version ) which I can theoretically test against any given Boost
library, so it is useless for me to rely on a single PATH and no
user-config.jam in order to run tests. So in my setup what I have is a
user-config.jam entry for each version. The toolset definition command I
then use for each toolset definition is therefore a script which
prepends that version's mingw-w64/gcc bin directory to the Windows PATH
and then invokes g++ passing all the parameters which are passed to the
script. My script in the example above for mingw-w64/gcc-8.1 is a
Windows batch file although of course you could use whatever you wanted
such as Python or Perl scripts if you liked. That is what my
cp_gcc81.bat does in the toolset definition above. Furthermore again,
because I don't have a single version of mingw-w64/gcc in my Windows
PATH, I need to specify in my toolset definition the path to the
particular mingw-w64/gcc's root directory at runtime so any necessary
DLLs will be found when b2 encounters the 'run' ( or 'run-fail' ) action
in a library's tests. This is what my <root> option does above. Please
disregard the $(TSE_BATCH_DRIVE) and $(TSE_MINGW64_DRIVE) above as they
just substitute some drive letter ( such as 'C:' ), for my setup through
bjam variables I initially set. Why I do this rather than just
specifying 'C:/etc.' or 'E:/etc.' in the toolset definition is too
tedious to explain and has no importance in this explanation.

Finally the rules I have found with mingw-w64/gcc distributions are:

1) You can't use a 64-bit distribution to compile 32-bit code because,
for whatever reason, the linker used does not find the appropriate
32-bit libraries needed during the linking phase. I don't have the time
or patience to figure out why this is so, therefore I use the
appropriate mingw-w64/gcc version's 32-bit distribution to compile/link
32-bit code and the appropriate mingw-w64/gcc version's 64-bit
distribution to compile/link 64-bit code. A real PITA but what can you do.

2) The bin directory of a given distribution must be in the Windows
PATH, or be the current directory, in order to compile/link
successfully. Just specifying the full path to the g++ command is not
enough. Fight with the gcc or mingw-w64 developers about this if you
like. Their answer to me is that VC++ does the same so they do it also,
although what I believe VC++ does is set environment variables to find
what it needs at compile/link time.

3) At runtime the bin directory of a given distribution often has
run-time DLLs which must be found in order for dynamically linked exes
to run correctly. This is at least normal when some application does not
install their DLLs in the PATH, such as in the Windows or Windows/system
directories or more modernly use a manifest, such as VC++ does.

Hopefully this helps you but if you have any questions feel free to ask.

_______________________________________________
Unsubscribe & other changes: https://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|

Re: Need some help running library tests

Boost - Build mailing list
Hi Edward,

I do appreciate your efforts to explain stuff to me. As far as software
development with the Windows API is concerned I'm pretty happy with
mingw-w64 in combination with the distributed gcc.

But I haven't seen something in your instructions that gives me the
impression that it will deal with the actual errors that are displayed (my
original output.txt), when I run b2 in the spirit test folder.

It starts off with:
config.jam: No such file of directory

I'm getting to a point of suspicion you're trolling me with your reluctance
to address this particular issue. You are involved with Boost-Build
development, aren't you? Now, when you see me reporting: "config.jam: No
such file of directory", It wouldn't be too hard for you to get to a
diagnoses what might have gone wrong, isn't it?

After all. My goal to run the tests for Spirit is to verify a pull request
that I promised to prepare for Joel (the author or that library)

Best regards,
Maarten Verhage

_______________________________________________
Unsubscribe & other changes: https://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|

Re: Need some help running library tests

Boost - Build mailing list
Hi Maarten,

On 7/31/19 8:16 PM, Maarten Verhage via Boost-build wrote:
> Hi Edward,
>
> I do appreciate your efforts to explain stuff to me. As far as software
> development with the Windows API is concerned I'm pretty happy with
> mingw-w64 in combination with the distributed gcc.
>
> But I haven't seen something in your instructions that gives me the
> impression that it will deal with the actual errors that are displayed
(my
> original output.txt), when I run b2 in the spirit test folder.
>
> It starts off with:
> config.jam: No such file of directory
>
> I'm getting to a point of suspicion you're trolling me with your
reluctance
> to address this particular issue.

Maarten, I seriously doubt Edward is trolling.  He's been a
long time contributor to boost and, although I've not paid
real close attention to all his replies over the years, I
never had the impression he ever "trolled".

> You are involved with Boost-Build development, aren't you?

What lead you to that assumption?  I vaguely remember Edward asking
a lot of questions about build, but I never got the
impression he was a contributor.  If you search the build
sources:

  https://github.com/boostorg/build/tree/develop/src

I think you'll find no mention of Edward in the copyright
notices.

> Now, when you see me reporting: "config.jam: No such file
> of directory", It wouldn't be too hard for you to get to a
> diagnoses what might have gone wrong, isn't it?

If, as I believe, Edward is not involved in the build
development, I wouldn't expect him to know right off the
cause of your "config.jam: No such file or directory" error.

However, this:


https://boostorg.github.io/build/manual/master/index.html#bbv2.util.debugger

suggests you could, if you're really interested in the
cause, run the debugger to try and find the cause of the
error.  I imagine that would seem like an awful lot of work
to find out why something so simple is causing a mysterious
problem, but that's life :(

BTW, I think Steven Watanabe might have a better idea of
what's the cause of this problem.  I recall him making many
suggests about how to use build and his name **does**
appear the the copyright notices in the source code.  I've
no idea how to contact him, but you might investigate how to
do that.  It might be fruitful.

> After all. My goal to run the tests for Spirit is to verify a pull
request
> that I promised to prepare for Joel (the author or that library)

An admirable goal.  I sincerely wish you luck!

> Best regards,
> Maarten Verhage

Best regards,
Larry Evans


_______________________________________________
Unsubscribe & other changes: https://lists.boost.org/mailman/listinfo.cgi/boost-build