Okay, well I made some progress on this last night and just pushed the results
to the repo.
I have told CMake to always use Linux line endings for the test shell scripts.
Alan - Msys might be okay with windows line endings, but Cygwin isn't.
There is a slight change to the ctest call which creates an enviraonment
variable called VC_CTEST_DIRECTORY only for MSVC builds. This will be either
\Debug or \Release depending upon the -C parameter passed to ctest and it is
used to find the C and C++ examples. This now works fine.
For Tcl I have hit some other snags. I changed the way the paths are dealt with
- moving the path translation to the shell script rather than CMake - this is
because the script can check which flavour of "Linux" it is working on and do
the correct thing. Could somebody please check I haven't broken this for
"proper" Linux and for Msys?
Unfortunately though, even with all the paths set up correctly the test still
didn't work. After a bit of testing I found that running pltcl under Cygwin
bash, when it had been built under native windows does not work. I do not get
the tcl prompt like I do when running from Cmd. Therefore it seems that for the
this case we would need to get bash to run Cmd or something. I doubt I have
time to look into that right now, but I will add it to my list of things to do.
Just so you know I have left in some debug messages regarding paths etc. Once I
get confirmation that I haven't broken anything I will remove them - and if I
have broken anything it should be easy to spot why.
Phil
From: Arjen Markus <arjen.mar...@deltares.nl>
To: "plplot-devel@lists.sourceforge.net" <plplot-devel@lists.sourceforge.net>
Sent: Friday, 3 October 2014, 7:34
Subject: Re: [Plplot-devel] Testing on Windows
#yiv4746650222 #yiv4746650222 -- _filtered #yiv4746650222
{font-family:SimSun;panose-1:2 1 6 0 3 1 1 1 1 1;} _filtered #yiv4746650222
{font-family:SimSun;panose-1:2 1 6 0 3 1 1 1 1 1;} _filtered #yiv4746650222
{font-family:Tahoma;panose-1:2 11 6 4 3 5 4 4 2 4;} _filtered #yiv4746650222
{panose-1:2 1 6 0 3 1 1 1 1 1;}#yiv4746650222 #yiv4746650222
p.yiv4746650222MsoNormal, #yiv4746650222 li.yiv4746650222MsoNormal,
#yiv4746650222 div.yiv4746650222MsoNormal
{margin:0cm;margin-bottom:.0001pt;font-size:12.0pt;}#yiv4746650222 a:link,
#yiv4746650222 span.yiv4746650222MsoHyperlink
{color:blue;text-decoration:underline;}#yiv4746650222 a:visited, #yiv4746650222
span.yiv4746650222MsoHyperlinkFollowed
{color:purple;text-decoration:underline;}#yiv4746650222 p
{margin-right:0cm;margin-left:0cm;font-size:12.0pt;}#yiv4746650222
p.yiv4746650222MsoAcetate, #yiv4746650222 li.yiv4746650222MsoAcetate,
#yiv4746650222 div.yiv4746650222MsoAcetate
{margin:0cm;margin-bottom:.0001pt;font-size:8.0pt;}#yiv4746650222
span.yiv4746650222EmailStyle18 {color:black;}#yiv4746650222
span.yiv4746650222BalloonTextChar {}#yiv4746650222 .yiv4746650222MsoChpDefault
{font-size:10.0pt;} _filtered #yiv4746650222 {margin:72.0pt 72.0pt 72.0pt
72.0pt;}#yiv4746650222 div.yiv4746650222WordSection1 {}#yiv4746650222 Hi Phil,
The “alternative” path format /d/something should work under MSYS. Note that
the colon used by bare Windows to spearate the drive letter from the directory
interfers with the colon that UNIX and its kin use to separate the various path
components. (It is fun brain gymnastics, at times: MSYS uses /d/something,
Cygwin uses /cygdrive/d/something and some of the commands in both environments
actually accept the Windows form too. It took me a long time to get used to
that.) Regards, Arjen
> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
> Sent: Friday, October 03, 2014 12:35 AM
> To: phil rosenberg
> Cc: plplot-devel@lists.sourceforge.net
> Subject: Re: [Plplot-devel] Testing on Windows
>
> On 2014-10-02 18:23-0000 phil rosenberg wrote:
>
> > Okay, well I have fixed the spaces in the paths problem
> and added a Visual Studio specific extra configuration parameter.
>
> Good. Please commit and push those change so they can be tested by others.
>
> > I am not sure how to deal with the final couple of problems. CMake
> generates the shell scripts, from the .sh.in files and when it does so it
> creates them
> with Windows line endings - Alan do you know how/if CMake can be set to use
> Linux
> line endings when creating these scripts?
>
> I have gone through similar testing for the "MSYS Makefiles" and "MinGW
> Makefiles"
> (and several other generators), and there were no issues with the line
> endings for
> those configured files. And Arjen has done some testing of those configured
> scripts
> on both Cygwin ("Unix Makefiles" generator for that platform) and I believe
> "MSYS
> Makefiles" as well without line ending issues. So it could be your Visual
> Studio
> generator is the issue or it could be your bash version.
> So to help sort out the cause, please try the experiment of using MSYS bash
> (if you
> are currently using some other bash version).
>
> > [...]I am also having a bit of trouble with the Tcl test
> script. On line 27 of the sh.in file is the linePATH=@PLTCL_DIR@:$PATH which
> resolves toPATH=/D/usr/local/src/plplot-plplot/build/Visual Studio 11
> 64sd/bindings/tcl//$(Configuration)/:$PATHin the final script. Simply adding
> quotes
> will solve the spaces in the path, however the Windows style D: path has been
> mangled. Alan, any advice on this?
>
> CMake needs help to deal correctly with drive letters on paths. Take a look
> at the
> determine_msys_path function in cmake/modules/plplot_functions.cmake for one
> solution that works on MSYS. It is possible you could use that directly
> (without the
> if(MSYS) logic) or a variant of that to solve the issue for your case.
>
DISCLAIMER: This message is intended exclusively for the addressee(s) and may
contain confidential and privileged information. If you are not the intended
recipient please notify the sender immediately and destroy this message.
Unauthorized use, disclosure or copying of this message is strictly prohibited.
The foundation 'Stichting Deltares', which has its seat at Delft, The
Netherlands, Commercial Registration Number 41146461, is not liable in any way
whatsoever for consequences and/or damages resulting from the improper,
incomplete and untimely dispatch, receipt and/or content of this e-mail.
------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
