Also, in env.ps1.in, there is a reference to "$builddir" but it never has value
so the tests needing PYTHON_DIR will always fail.
$PYTHON_DIR="$builddir\python" ---> is interpreted as "\python"
I think there is a missing link between "$builddir" and some Cmake variable.
> From: [email protected]
> To: [email protected]
> Subject: RE: Qpid C++ 0.34 unit tests are failing with visual studio 2013
> Date: Fri, 27 May 2016 16:31:44 +0200
>
> Hello Justin,
> So I launched all the tests and I have 10 failing including the unit_tests
> (There is a disconnection error which I can also see in your appveyor).
>
> The following tests FAILED: 4 - federation_tests (Failed) 5 -
> flow_control_tests (Timeout) 6 - ha_tests (Failed) 9 - python_tests
> (Failed) 11 - qmf_tests (Failed) 14 - interlink_tests (Failed)
> 15 - interop_tests (Timeout) 16 - store_tests (Failed) 17 -
> store_tests_clfs (Failed)
> For the store_tests, powershell scripts in current directory cannot be
> launched as they are not trusted, so you should add ".\" prior to the script
> name.
> C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
> "run_store_tests.ps1" "MSSQL"The error message is helpful
> actually:run_store_tests.ps1 : The term 'run_store_tests.ps1' is not
> recognized as the name of a cmdlet, function... Suggestion [3,General]: The
> command run_store_tests.ps1 was not found, but does exist in the current
> location. Windows PowerShell does not load commands from the current location
> by default. If you trust this command, instead type ".\run_store_tests.ps1".
> See "get-help about_Command_Precedence" for more details.
> I am still debugging the other tests.
> Have you had a better luck than mine?
> I can send you the test logs if you like.
> PS: I am compiling with SASL/SSL disabled and valgrind disabled also
> completely.
> Regards,Adel
> > From: [email protected]
> > To: [email protected]
> > Subject: RE: Qpid C++ 0.34 unit tests are failing with visual studio 2013
> > Date: Fri, 27 May 2016 12:02:40 +0200
> >
> > Please ignore my last email. There was a problem with the PATH environment
> > variable.
> >
> > > From: [email protected]
> > > To: [email protected]
> > > Subject: RE: Qpid C++ 0.34 unit tests are failing with visual studio 2013
> > > Date: Fri, 27 May 2016 11:40:58 +0200
> > >
> > > Hello Justin,
> > > I updated to the head of the trunk and relaunched everything. I still
> > > have a problem with the qpid tools.I can see all the bat files, but the
> > > code still calls the original files for example:
> > > 1: run_acl_tests: Calling 'qpid-python-test --broker localhost:63666
> > > --time -m acl -Dport-i=63668 -Dport-u=63710 -Dport-q=63712
> > > -Dpolicy-file=D:\qpid-cpp-trunk.git\qpid\qpid\cpp\build-dir-RelWithDebInfo\src\tests\policy.acl'1:
> > > 'qpid-python-test' is not recognized as an internal or external command,
> > > All the .py files have not been updated to launch qpid-python-test.bat
> > > when on windows:Example:
> > > qpid/cpp/src/tests/run_interop_testscall("qpid-python-test -m
> > > interop_tests -DOUTDIR={0}", WORK_DIR)
> > > Regards,Adel
> > > > Date: Thu, 26 May 2016 15:02:59 -0700
> > > > Subject: Re: Qpid C++ 0.34 unit tests are failing with visual studio
> > > > 2013
> > > > From: [email protected]
> > > > To: [email protected]
> > > >
> > > > An update. I think I've fixed the python and backslash problems.
> > > >
> > > > https://issues.apache.org/jira/browse/QPID-7281
> > > >
> > > > Here's what I get now in appveyor:
> > > >
> > > >
> > > > https://ci.appveyor.com/project/ssorj/qpid-svn-reorg/build/hammerandtong.71
> > > >
> > > > The unit_test failure is one I've had for a long time. I've not yet
> > > > been
> > > > able to convince either appveyor to use "localhost" for its hostname or
> > > > unit_test to use "appveyor-vm" as its ssl cert name. So it times out.
> > > >
> > > > The other tests are running now, with some failures. Note that up to
> > > > now
> > > > I've been liberal in enabling the cross-platform tests that can
> > > > hypothetically work in windows. There may be specific instances where
> > > > I'm
> > > > wrong, and we'll need to adjust the target platform for the test.
> > > >
> > > > On Thu, May 26, 2016 at 9:45 AM, Andrew Stitcher <[email protected]>
> > > > wrote:
> > > >
> > > > > On Thu, 2016-05-26 at 09:38 -0700, Justin Ross wrote:
> > > > > > I tried this approach first. I wasn't able to make that
> > > > > > configuration
> > > > > > available in CTestCustom.cmake when I tried last. However, I don't
> > > > > > think I
> > > > > > tried repeating the find_package logic directly in the custom.cmake
> > > > > > file,
> > > > > > which I will do.
> > > > >
> > > > > CMake is hierarchical so the find_package() would need to be in a
> > > > > CMake
> > > > > file above the relevant one (and perhaps in the sequence before the
> > > > > add_directory(..) or include(...) that includes the file you want the
> > > > > definition in - I'm not too clear about that point.
> > > > >
> > > > > Andrew
> > > > >
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: [email protected]
> > > > > For additional commands, e-mail: [email protected]
> > > > >
> > > > >
> > >
> >
>
