On 2006-12-01 23:11+0100 Werner Smekal wrote:
> Hi Alan,
>
>> find_program(SH_EXECUTABLE bash)
>>
>> works. If the name of the program is actually win-bash rather than bash in
>> your case you should use the following logic instead:
>>
>> find_program(SH_EXECUTABLE bash)
>> find_program(SH_EXECUT
Hi Alan,
> find_program(SH_EXECUTABLE bash)
>
> works. If the name of the program is actually win-bash rather than bash in
> your case you should use the following logic instead:
>
> find_program(SH_EXECUTABLE bash)
> find_program(SH_EXECUTABLE win-bash)
>
> The first one works on Unix, and th
On 2006-12-01 10:15+0100 Arjen Markus wrote:
>> On 2006-11-30 01:40-0800 Alan W. Irwin wrote:
>>
>>> [...]if one of you guys
>>> does not implement the above simple changes first, I will do that
>>> tomorrow evening (European time) and that may be all we need to get
>>> ctest scripts to work on ba
> On 2006-11-30 01:40-0800 Alan W. Irwin wrote:
>
>> [...]if one of you guys
>> does not implement the above simple changes first, I will do that
>> tomorrow evening (European time) and that may be all we need to get
>> ctest scripts to work on bare windows (without the extra GNUWin32
>> tools depe
On 2006-11-30 01:40-0800 Alan W. Irwin wrote:
> [...]if one of you guys
> does not implement the above simple changes first, I will do that tomorrow
> evening (European time) and that may be all we need to get ctest scripts to
> work on bare windows (without the extra GNUWin32 tools dependency).
Actually, sed is available for windows. I have used it to process the
fortran plplot sources to get the single precision versions that I use in
most of my work. It works quite well. It is just an executable that you
drop somewhere in your path.
It can be found at
http://gnuwin32.sourceforge.
On 2006-11-30 08:50+0100 Arjen Markus wrote:
> BUT: I do want to prevent us requiring Windows users to download and install
> all manner of tools before they can get started. The installation
> instructions for
> PLplot should ideally fit in 10 lines of text, each no longer than 80
> characters.
>
Werner Smekal wrote:
> I think this won't be the only command you will not find, e.g. sed is
> later used on, and there is no windows command I know of, that has
> this functionality. I use the very well ported GNUWin32 tools:
>
> http://GNUWin32.sf.net
>
> It has all the GNU Tools you need: cor
Hi Arjen,
> The Bourne shell uses -s if I remember correctly, but I never thought of
> putting these options in the magic first line. Good idea, though!
>
> Anyway, the culprit for the failure is clear: cat. It does not exist on
> Windows,
> so I will change the script to use echo instead (as th
Alan W. Irwin wrote:
On 2006-11-29 12:06+0100 Arjen Markus wrote:
Argh, why didn't I think of that! You are most probably right. Well, I
will check
what is happening (or rather, what is not happening) later then.
(Debugging shell
scripts is always, well, cumbersome)
Just learned a tr
On 2006-11-29 19:48+0100 Werner Smekal wrote:
Hi Werner:
>> I have just had an idea about that. I suggest you put the directory
>> where win-bash occurs last on your PATH. For those platforms with an
>> official shell (MinGW/MSYS, Cygwin, etc.) you will always use that
>> official
>> shell (wh
Hi Alan,
>
> "cmake doesn't like sh.exe in the path if I use MinGW/CLI combination, I
> have to rename it, run cmake, rename sh again to run the tests."
>
> I have just had an idea about that. I suggest you put the directory
> where win-bash occurs last on your PATH. For those platforms with a
On 2006-11-29 18:02+0100 Werner Smekal wrote:
> We might first try the win-bash approach and if we have a show stopper we can
> go for the windows batch files.
Sounds good.
On the question of win-bash showstoppers, you commmented before
"cmake doesn't like sh.exe in the path if I use MinGW/CLI
Hi Alan,
thanks for the hint. It shows that it finds the file:
C:\DevZone\plplot\buildnmake\test>bash -x plplot_test.sh
+ version=5.7.1
+ dirname=
+ EXAMPLES_DIR=.
+ SRC_EXAMPLES_DIR=.
+ OUTPUT_DIR=.
+ device=psc
+ export EXAMPLES_DIR SRC_EXAMPLES_DIR OUTPUT_DIR device
+ test 0 -gt 0
+ test ! -d
Hi,
> I hope he didn't mean that... :-) I want to keep the current scripting
> intact for the Unix side of everything since shell scripting is installed by
> default for Unix and most Unix developers understand it. OTOH, Tcl is not
> installed by default, and I am not sure that most Unix develope
On 2006-11-29 12:06+0100 Arjen Markus wrote:
> Argh, why didn't I think of that! You are most probably right. Well, I
> will check
> what is happening (or rather, what is not happening) later then.
> (Debugging shell
> scripts is always, well, cumbersome)
Just learned a trick about that from
(htt
Werner Smekal wrote:
> Hi Arjen,
>
>
> I think win-bash finds it, but has problems during execution, since
> the error message is:
> plplot_test.sh: 248352: No such file or directory
>
> while for executing a nonexisting file reveals
> no_exist.sh: no_exist.sh: No such file or directory
>
> all o
Hi Arjen,
> I appreciate your conservative approach to this topic. So I tried to get
> win-bash
> to work on my PC (http://win-bash.sf.net). Installing it is a non-issue
> - just get
> the executable and put it in a convenient directory. However, when I simply
> tried to run plplot-test.sh, it c
Alan W. Irwin wrote:
>Hmm... It's interesting how my comment about a parallel windows scripting
>system for ctest has sparked so much interest. A consensus seems to have
>formed for building jim/tcl as part of PLplot and making jim scripts with
>the same functionality as plplot-test.sh and the var
On 2006-11-27 21:41+0100 Werner Smekal wrote:
> I think, Arjen ment that we replace the sh-scripts with jim/tcl-scripts. So
> for Linux, we don't need to compile jim, since tcl might be available most of
> the times, and for Windows we use jim. So this might be a good solution.
I hope he didn't
Hi,
> Hmm... It's interesting [...]
>
> 1) It adds parallel maintenance that Werner and Arjen have to apply to
> the jim scripts any time there is a change to plplot-test.sh and the
> other test*.sh scripts. This is all fairly trivial stuff (adding new
> examples, finding better ways to configur
On 2006-11-27 12:12+0100 Werner Smekal wrote:
> Hi,
>
>>
>> I'm unhappy about requiring python (or anything else non-standard) for
>> running the tests. This adds another significant dependency to the build
>> process. We're already asking users to install a fair bit. I guess this
>> is particular
Hi,
>
> I'm unhappy about requiring python (or anything else non-standard) for
> running the tests. This adds another significant dependency to the build
> process. We're already asking users to install a fair bit. I guess this
> is particularly an issue for windows users.
Yes, windows user need
Andrew Ross wrote:
>I'm unhappy about requiring python (or anything else non-standard) for
>running the tests. This adds another significant dependency to the build
>process. We're already asking users to install a fair bit. I guess this
>is particularly an issue for windows users.
>
>
>
Which i
On Mon, Nov 27, 2006 at 10:59:56AM +0100, Werner Smekal wrote:
> Hi,
>
> > Sorry to pop in at the end of this discussion. When I first implemented
> > the ctest stuff I wondered about doing away with the scripts and doing
> > all the work in ctest.
>
> Actually using only ctest would be a good i
Hi,
> Sorry to pop in at the end of this discussion. When I first implemented
> the ctest stuff I wondered about doing away with the scripts and doing
> all the work in ctest.
Actually using only ctest would be a good idea, especially if we ever
use dashboard.
>
> Advantages:
> Should be more
On Mon, Nov 27, 2006 at 09:15:22AM +0100, Arjen Markus wrote:
> Werner Smekal wrote:
>
> >
> >So, long story short, ctest works now, with small problems though. I
> >wasn't actually successful running the plplot-test.sh script in the
> >examples folder of the install directory (share/plplot-5.7.
Hi Arjen,
> No, Tcl/Tk is fine without MinGW. I just noticed the condition that we
> only set
> the output path on Windows, unless we are using Cygwin. I am not sure if
> MinGW
> handles the rpath option in the same way as Cygwin. If it does, then for
> MinGW
> we do not need the output path ei
Werner Smekal wrote:
>
> As written before, it is possible, but with problems. With Vista also
> a new powershell was developed also for windows xp, but I don't want
> to learn another syntax - and as you said not nearly compatible to
> unix scripts but super powerful with objects and clas
Werner Smekal wrote:
>
>> - I get a failure for the Tcl examples, but I have not been able yet
>> to trace what is
>> causing it (did not have the time). I will look into this ASAP.
>
>
> You said in former emails, that you need the plserver.exe or so, and
> this exe files are not in the path,
Hi Arjen,
> They won't. Windows uses DOS batchfiles and I know there is a command
> language
> slightly more powerful than that, which I have never used, but it is
> completely
> incompatible with UNIX shell scripts.
As written before, it is possible, but with problems. With Vista also a
new p
Werner Smekal wrote:
>
>So, long story short, ctest works now, with small problems though. I
>wasn't actually successful running the plplot-test.sh script in the
>examples folder of the install directory (share/plplot-5.7.1), but this
>would need also minor tweaking.
>
>Arjen, would you willing
Hi Arjen,
> Hi Werner,
>
> I checked your changes using bare Windows (MSVC 6.0 and ordinary makefiles
> but that should not really matter):
> - It works for C and Fortran 95 - all relevant DLLs are stored in the
> dll subdirectory and
> by expanding the PATH, the examples work fine.
> - The di
Hi Alan,
> This build-tree change is a nice first step toward getting ctest working on
> windows. Of course, the problem still remains that the current ctest uses
> the shell scripts plplot-test.sh and test*.sh, and I assume (but correct me
> if I am wrong) those scripts will not work on bare win
Alan W. Irwin wrote:
>This build-tree change is a nice first step toward getting ctest working on
>windows. Of course, the problem still remains that the current ctest uses
>the shell scripts plplot-test.sh and test*.sh, and I assume (but correct me
>if I am wrong) those scripts will not work on
Werner Smekal wrote:
>Hi,
>
>I just committed a small change to plplot which should make life for
>windows developing easier (thanks for the hint, Alan):
>
>In CMakeLists.txt of the plplot main directory I added
>
>if(BUILD_SHARED_LIBS AND WIN32 AND NOT CYGWIN)
> SET(LIBRARY_OUTPUT_PATH ${CMAKE
On 2006-11-26 11:04+0100 Werner Smekal wrote:
> Hi,
>
> I just committed a small change to plplot which should make life for
> windows developing easier (thanks for the hint, Alan):
To summarize the effect of LIBRARY_OUTPUT_PATH, it collects all built
libraries in one directory in the build tree
Hi,
I just committed a small change to plplot which should make life for
windows developing easier (thanks for the hint, Alan):
In CMakeLists.txt of the plplot main directory I added
if(BUILD_SHARED_LIBS AND WIN32 AND NOT CYGWIN)
SET(LIBRARY_OUTPUT_PATH ${CMAKE_CURRENT_BINARY_DIR}/dll)
endif
38 matches
Mail list logo
