On 16/12/11 03:39, Bovy, Stephen wrote:
Hi Tony,
Thanks very much for your response
I am compiling on IBM z/OS which has a very very strict implementation
that does not deviate from standards
Apparently the ibm compiler does not allow dups In the case switch
logic ( and to me that seems correct )
To me a dup in a case switch statement implies a bug !!!!
The 't' dup is between _three different_ switch statements (at lines
4846, 7809 and 9120), and as 't' and 'T' are different characters there
is no dup between them.
Testing one expression for a certain value and a different expression
(or the same expression in a different context) for the same value in a
*different* switch statement is hardly a bug. If your compiler does not
allow it, then I guess the bug is in the compiler.
So you're one of the few people using Vim on EBCDIC aren't you? Good
luck with that! Vim on zOS has a number of quirks compared to Vim on
other platforms, and it is not very extensively tested and maintained.
If you haven't yet, you should read very attentively
:help os_390.txt
or, if there is no Vim yet on your machine,
http://vimdoc.sourceforge.net/cgi-bin/help?tag=os_390.txt
and try to find and contact other people using Vim on zOS. I'm on Linux
on an Intel PC, a much "more densely populated" platform for Vim.
There may also be zOS-relevant paragraps in the top-level Makefile
and/or the src/Makefile (search them, not only for zOS but also for 390
and for EBCDIC).
We have often found that the ibm compiler finds bugs that other compilers
naively ignore !!!!!
But that aside I do not know why the " feat_windows" was defined
(if that is for ms-window ) I will have to search thru the
Makefile or config to figure out why or how it was set ( I certainly did not
set it or select it )
Oops, sorry, FEAT_WINDOWS is _split_ windows (inside Vim), not _MS_
windows. It corresponds to the +windows compile-time feature, included
in "small" (and bigger) versions of Vim.
I did ./configure , make (assuming that the magic configure would do
the right thing) but apparently not !!!!
See http://users.skynet.be/antoine.mechelynck/vim/compunix.htm about
using environment variables to make sure that configure and make do not
act at cross-purposes. I wrote that HowTo page on Linux but it should
apply more or less closely (with maybe some changes) on all Unix-like
platforms.
I found it better never to call configure directly, but only through
make. Running make with no arguments will call configure first if it
hasn't yet been run, and pass it the arguments you passed to make (see
my example bash script, to be sourced not run, in the page linked
above). Or you can invoke "make config" to run configure and not compile
(then "make" will see that configure has been run and usually just
compile… unless it notices that one of the files needed to make the
config.mk has been changed, in which case it will try to rerun configure
anyway, and fail, telling you that you must remove
src/auto/config.cache), or "make reconfig" to re-evaluate everything
that configure finds out for you and then compile. Such a reconfig may
for instance be necessary after updating some software package used by
Vim: after updating my openSUSE Linux from version 11.4 to 12.1, running
just "make && make install" produced a Vim executable which crashed at
startup; a "make reconfig" step was necessary.
Best regards,
Tony.
--
Ask not for whom the <CONTROL-G> tolls.
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
