Re: Five (5) new features request
On Wednesday 16 July 2008, Milan Vancura wrote: 5. Ever used Vim in a putty window, and pasted a giant section of code after hitting insert when you accidently left auto-indent on? The pasted text is all screwed up cause of the tabs and such. Of course, you have to :h pastetoggle Milan vim tip of the day for me, thank you :-) Marc -- Marc Haisenko Comdasys AG Rüdesheimer Str. 7 80686 München Germany Tel.: +49 (0)89 548 433 321 --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: 7.2a: No color in xterm?
On Tuesday 01 July 2008, Corinna Vinschen wrote: xterm has color capabilities for ages and the terminfo xterm entry contains this information. Yes, but in a lot of places it is still assumed that xterm means monochrome. For example, try OpenSolaris: if TERM=xterm you'll get a monochrome vim. Setting it to xterm-color or xterm-256color fixes that. I ran into this when I installed OpenSolaris a few weeks back :-) Code that outputs color escape sequences for xterm is, in a very strict sense, wrong. Of course there's always the correct-according-to-the-specs vs. Do-What-I-Mean conflict :-) Of course, when linking against libtermcap instead of ncurses... ;) Corinna Hehe :-) Marc -- Marc Haisenko Comdasys AG Rüdesheimer Str. 7 80686 München Germany Tel.: +49 (0)89 548 433 321 --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: git for vim was: Re: Vim 7.2a in CVS
On Thursday 26 June 2008, Mike Williams wrote: Sorry to rain on the git love fest going on but ... There are other options. There is no killer reason to use git over the other systems, and the need for a Cygwin base system for windows does raise the bar for Windows users - not everyone will want to have to install and maintain a Unix like command system just to use a source control system. It would be nice to have a reasoned review of the options for Vim development. Mercurial is widely used, with a possible plus of svn like command interface. Bzr is also good, if not so widely used. IIRC there has been a recent SVN release that supports disconnected working (one of the big selling points of DVCSs) so perhaps that should not be discounted just yet. I don't know what disconnected working should mean, but SubVersion was designed to have as few talking to the server as possible. But if you like to do stuff like checking in and so on without being connected to the real server then there's always SVK, which is a special SubVersion client. AFAIK there's nothing you need to do to your server to make it work. SubVersion has the disadvantage of being a centralized VCS while Bazaar, GIT and Mercurial are decentralized. But the advantages of SubVersion are that CVS users will propably have few trouble adapting to SubVersion (that was one of the design goals), there a clients for all major OS's out there (even OS/390), and there are even several GUIs for Windows, Mac and Unix. I think by now all Linux distros contain SubVersion (all 1.x clients are guaranteed to be able to speak with all 1.x servers) and there are pre-compiled packages for Mac and Windows. A major downside of SubVersion has been the missing merge-tracking but SubVersion 1.5.0 which is out for a week or so has finally closed that gap (AFAIK there are still corner-cases that aren't handled as elegant as the SVN developers want it to be, but for the majority of people the current state of merge tracking in SVN should be working just fine). With cvs2svn it's possible to migrate an existing CVS repository to SubVersion. I like SVN because it's rock-solid. I use it at home and we are using it in our company for about 6 years now. And if it's good enough for KDE and GCC which are really huge projects than it should be good enough for mere mortals as well ;-) That being said, which VCS to use really depends on your target audience and how you want to work. There's a very nice page summarizing all kind of aspects of various VCS systems: http://better-scm.berlios.de/comparison/comparison.html Bye, Marc -- Marc Haisenko Comdasys AG Rüdesheimer Str. 7 80686 München Germany Tel.: +49 (0)89 548 433 321 --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: git for vim was: Re: Vim 7.2a in CVS
On Thursday 26 June 2008, Christian MICHON wrote: On Thu, Jun 26, 2008 at 1:03 PM, Marc Haisenko [EMAIL PROTECTED] wrote: A major downside of SubVersion has been the missing merge-tracking but SubVersion 1.5.0 which is out for a week or so has finally closed that gap there's no branch in vim if I recall well. No branch, no merge... ... yet :-) -- Marc Haisenko Comdasys AG Rüdesheimer Str. 7 80686 München Germany Tel.: +49 (0)89 548 433 321 --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: GSOC: On-the-fly Code Checking for Vim - Challenges
On Monday 14 April 2008, Lin wrote: On Apr 14, 11:18 pm, Charles E Campbell Jr [EMAIL PROTECTED] wrote: The primary disadvantage is that effectively writing a new yacc/bison is not a small task. I have a real thick book about writing a yacc-like parser somewhere; if anyone's interested, I could look up its ISBN. The biggest advantage for writing a brand new LALR parser I think is that we can make it incremental. I know something about parsing LALR grammars. They would produce some intermediate table from the grammar definition (called status table?) to guide the parser, so that it operates like a finite automata with a stack equipped. If we have that table we can just store the stack and the parser's state to avoid looking back to previous codes. Then we also need a scanner recognizing different types of words. For this we can seek help from tools like Lex. Is C++ an LALR language? Not sure... Regards, Lin IMHO not a good idea. You will waste most of the time writing/debugging the parser instead of the Vim part (plus all the time you need to solve problems related to the parser and the grammar). Don't reinvent the wheel when there's one that might suit your need sufficiently well. Writing a parser seems not that hard at first, but how many have you written so far ? It really is not an easy task and that's why yacc/bison is still so popular despite it having some limitations. Plus writing a grammar for C sounds as joyful as driving a glowing steel rod through your private parts, considering all its ambiguities. Marc -- Marc Haisenko Comdasys AG Rüdesheimer Str. 7 80686 München Germany Tel.: +49 (0)89 548 433 321 --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: About: can not compile a GUI version vim on OpenSolaris
So, the interesting output of ./configure is this: checking --enable-gui argument... GNOME 2.x GUI support checking whether or not to look for GTK... yes checking --with-gtk-prefix argument... no checking --with-gtk-exec-prefix argument... no checking --disable-gtktest argument... gtk test enabled checking for gtk-config... (cached) no checking for gtk12-config... (cached) no checking for pkg-config... (cached) /usr/bin/pkg-config checking for GTK - version = 2.2.0... no checking for GTK - version = 1.1.16... no It says it can't find GTK (to be more precise: the gtk-config script). You're propably missing the development package of GTK (don't know what and how to install it on Solaris). Bye, Marc -- Marc Haisenko Comdasys AG Rüdesheimer Str. 7 80686 München Germany Tel.: +49 (0)89 548 433 321 --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: [PATCH] Cross-compilation patch to avoid looking for /usr/local at compile time
On Friday 11 January 2008, Bram Moolenaar wrote: Marc Haisenko wrote: What about the main configure.in fixes for cross-compiling patch by me ? Is there anything I need to tweak so you can accept it or is there some reason why you'd say the patch wouldn't be necessary ? When adding a new argument to configure it's always good to document this in the appropriate places. No worry, the patch doesn't add any new arguments. It only allows to use the appropiate autoconf mechanism (well-named environment variables) to pass the results of tests in environments where those tests can't be done (cross-compiling). Is there any file I'd need to document them ? Haven't seen any yet. Don't get me wrong, I wouldn't be mad if you'd declined it, I just want a definitive accepted or declined. I still need to look into this. Configure patches are always tricky. Yes, they are :-) Marc -- Marc Haisenko Comdasys AG Rüdesheimer Str. 7 80686 München Germany Tel.: +49 (0)89 548 433 321 --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Repost: [PATCH] Enable cross-compiling
On Thursday 10 January 2008, Ben Schmidt wrote: Although according the Ben's earlier posting, we're both in the pipeline. So I guess we just sit tight a little longer... If you haven't seen Bram's post to you now (that should comt to you directly and via the vim_dev list), let me know and I will forward its text only to you. Seems he has been having trouble reaching you (emails bouncing). If ones he sends to you via the mailing list bounce too, it could get tricky! Ben. Sorry, haven't received anything. Could you please forward it to me ? Thank you, Marc -- Marc Haisenko Comdasys AG Rüdesheimer Str. 7 80686 München Germany Tel.: +49 (0)89 548 433 321 --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: [PATCH] Cross-compilation patch to avoid looking for /usr/local at compile time
On Thursday 10 January 2008, Bram Moolenaar wrote: The reason you don't hear from me is that most of my emails to you bounce back. Ouch, that's bad... don't know why that happens. What I tried to say: excluding /usr/local/[include|lib] is not specific for cross compiling. This should be a separate setting. Then it can also be set for cross compiling. Philip's patch is independent of mine, I think... the problem it addresses just happened to bite him while cross-compiling. Most configure features are explained in the Makefile. Or in the INSTALL file. I prefer the Makefile, there you can uncomment a line to have it used, no need to type it (configure doesn't warn for unrecognized arguments). What about the main configure.in fixes for cross-compiling patch by me ? Is there anything I need to tweak so you can accept it or is there some reason why you'd say the patch wouldn't be necessary ? Don't get me wrong, I wouldn't be mad if you'd declined it, I just want a definitive accepted or declined. Bye, Marc -- Marc Haisenko Comdasys AG Rüdesheimer Str. 7 80686 München Germany Tel.: +49 (0)89 548 433 321 --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Repost: [PATCH] Enable cross-compiling
On Wednesday 09 January 2008, Marc Haisenko wrote: Hi folks, a few weeks back I posted a patch that helps enabling cross-compiling by adding the necessary stuff in configure.in to tell configure the necessary values when cross-compiling. The patch also includes a README explaining everything. As people asked me about it I'd like to know if there's anything to fix in that patch before it can get accepted or if there are any other problems to resolve first. Thanks a lot, Marc PING. Could I please get a comment about this, even if it's go away ? -- Marc Haisenko Comdasys AG Rüdesheimer Str. 7 80686 München Germany Tel.: +49 (0)89 548 433 321 --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Repost: [PATCH] Enable cross-compiling
Hi folks,
a few weeks back I posted a patch that helps enabling cross-compiling by
adding the necessary stuff in configure.in to tell configure the necessary
values when cross-compiling. The patch also includes a README explaining
everything.
As people asked me about it I'd like to know if there's anything to fix in
that patch before it can get accepted or if there are any other problems to
resolve first.
Thanks a lot,
Marc
--
Marc Haisenko
Comdasys AG
Rüdesheimer Str. 7
80686 München
Germany
Tel.: +49 (0)89 548 433 321
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
diff -Nur vim71.orig/src/configure.in vim71/src/configure.in
--- vim71.orig/src/configure.in 2007-05-12 11:19:27.0 +0200
+++ vim71/src/configure.in 2007-09-21 14:58:23.0 +0200
@@ -47,13 +47,6 @@
fi
fi
-dnl If configure thinks we are cross compiling, there is probably something
-dnl wrong with the CC or CFLAGS settings, give an understandable error message
-if test $cross_compiling = yes; then
- AC_MSG_ERROR([cannot compile a simple program, check CC and CFLAGS
- (cross compiling doesn't work)])
-fi
-
dnl gcc-cpp has the wonderful -MM option to produce nicer dependencies.
dnl But gcc 3.1 changed the meaning! See near the end.
test $GCC = yes CPP_MM=M; AC_SUBST(CPP_MM)
@@ -1986,11 +1979,24 @@
dnl Checks for libraries and include files.
-AC_MSG_CHECKING(quality of toupper)
-AC_TRY_RUN([#include ctype.h
-main() { exit(toupper('A') == 'A' tolower('z') == 'z'); }],
- AC_DEFINE(BROKEN_TOUPPER) AC_MSG_RESULT(bad),
- AC_MSG_RESULT(good), AC_MSG_ERROR(failed to compile test program))
+AC_CACHE_CHECK([toupper is broken],[vim_cv_toupper_broken],
+ [
+AC_RUN_IFELSE([
+#include ctype.h
+main() { exit(toupper('A') == 'A' tolower('z') == 'z'); }
+ ],[
+vim_cv_toupper_broken=yes
+AC_MSG_RESULT(yes)
+ ],[
+vim_cv_toupper_broken=no
+AC_MSG_RESULT(no)
+ ],[
+AC_MSG_ERROR(cross-compiling: please set 'vim_cv_toupper_broken')
+ ])])
+
+if test x$vim_cv_toupper_broken = xyes ; then
+ AC_DEFINE(BROKEN_TOUPPER)
+fi
AC_MSG_CHECKING(whether __DATE__ and __TIME__ work)
AC_TRY_COMPILE(, [printf(( __DATE__ __TIME__ ));],
@@ -2202,28 +2208,52 @@
Or specify the name of the library with --with-tlib.]))
fi
-AC_MSG_CHECKING(whether we talk terminfo)
-AC_TRY_RUN([
+AC_CACHE_CHECK([whether we talk terminfo], [vim_cv_terminfo],
+ [
+AC_RUN_IFELSE([
#ifdef HAVE_TERMCAP_H
# include termcap.h
#endif
main()
-{char *s; s=(char *)tgoto(%p1%d, 0, 1); exit(!strcmp(s==0 ? : s, 1)); }],
- AC_MSG_RESULT([no -- we are in termcap land]),
- AC_MSG_RESULT([yes -- terminfo spoken here]); AC_DEFINE(TERMINFO),
- AC_MSG_ERROR(failed to compile test program.))
+{char *s; s=(char *)tgoto(%p1%d, 0, 1); exit(!strcmp(s==0 ? : s, 1)); }
+],[
+ vim_cv_terminfo=no
+ AC_MSG_RESULT([no -- we are in termcap land])
+],[
+ vim_cv_terminfo=yes
+ AC_MSG_RESULT([yes -- terminfo spoken here])
+],[
+ AC_MSG_ERROR(cross-compiling: please set 'vim_cv_terminfo')
+])
+ ])
+
+if test x$vim_cv_terminfo = xyes ; then
+ AC_DEFINE(TERMINFO)
+fi
if test x$olibs != x$LIBS; then
- AC_MSG_CHECKING(what tgetent() returns for an unknown terminal)
- AC_TRY_RUN([
+ AC_CACHE_CHECK([what tgetent() returns for an unknown terminal], [vim_cv_tgent],
+[
+ AC_RUN_IFELSE([
#ifdef HAVE_TERMCAP_H
# include termcap.h
#endif
main()
-{char s[1]; int res = tgetent(s, thisterminaldoesnotexist); exit(res != 0); }],
- AC_MSG_RESULT(zero); AC_DEFINE(TGETENT_ZERO_ERR, 0),
- AC_MSG_RESULT(non-zero),
- AC_MSG_ERROR(failed to compile test program.))
+{char s[1]; int res = tgetent(s, thisterminaldoesnotexist); exit(res != 0); }
+ ],[
+ vim_cv_tgent=zero
+ AC_MSG_RESULT(zero)
+ ],[
+ vim_cv_tgent=non-zero
+ AC_MSG_RESULT(non-zero)
+ ],[
+ AC_MSG_ERROR(failed to compile test program.)
+ ])
+])
+
+ if test x$vim_cv_tgent = xzero ; then
+AC_DEFINE(TGETENT_ZERO_ERR, 0)
+ fi
fi
AC_MSG_CHECKING(whether termcap.h contains ospeed)
@@ -2333,9 +2363,10 @@
dnl pty mode/group handling
dnl
dnl support provided by Luke Mewburn [EMAIL PROTECTED], 931222
-AC_MSG_CHECKING(default tty permissions/group)
rm -f conftest_grp
-AC_TRY_RUN([
+AC_CACHE_CHECK([default tty permissions/group], [vim_cv_tty_group],
+ [
+AC_RUN_IFELSE([
#include sys/types.h
#include sys/stat.h
#include stdio.h
@@ -2363,20 +2394,35 @@
fclose(fp);
exit(0);
}
-],[
-if test -f conftest_grp; then
- ptygrp=`cat conftest_grp`
- AC_MSG_RESULT([pty mode: 0620, group: $ptygrp])
- AC_DEFINE(PTYMODE, 0620)
- AC_DEFINE_UNQUOTED(PTYGROUP,$ptygrp)
-else
+],[
+ if test -f conftest_grp; then
+ vim_cv_tty_group=`cat conftest_grp`
+ if test x$vim_cv_tty_mode = x
Re: Porting vim to Astlinux
On Thursday 13 December 2007, Philip Prindeville wrote:
Marc Haisenko wrote:
Sorry, forgot to attach the patch.
Thanks. Tried it out.
I guess since you wrote it, someone added:
{ echo $as_me:$LINENO: checking quality of toupper 5
echo $ECHO_N checking quality of toupper... $ECHO_C 6; }
if test $cross_compiling = yes; then
{ { echo $as_me:$LINENO: error: failed to compile test program 5
echo $as_me: error: failed to compile test program 2;}
{ (exit 1); exit 1; }; }
else
cat conftest.$ac_ext _ACEOF
/* confdefs.h. */
_ACEOF
cat confdefs.h conftest.$ac_ext
cat conftest.$ac_ext _ACEOF
...
Bunch of other places, too:
[...]
After applying my patch, have you run autoconf ? Otherwise the patch doesn't
do anything ;-)
Marc
--
Marc Haisenko
Comdasys AG
Rüdesheimer Str. 7
80686 München
Germany
Tel.: +49 (0)89 548 433 321
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: Porting vim to Astlinux
On Wednesday 12 December 2007, Ben Schmidt wrote: Well, I'm a little confused... the configure that was distributed seems to very deliberately go out of its way to defeat cross-compilation, as opposed to simply being unaware of it (agnostic). I was wondering if there were historical reasons for that. Possibly. Or maybe it's just the way autoconf works--it has cross-compilation options available by default, so if you don't support them, it may be smartest to make a point of not supporting them. I don't think the way Vim uses configure is quite standard, either, so that may have something to do with it. I'm sure there's no good reason Vim couldn't be cross compiled. It would take considerable effort, though. But then cross-compilation almost always does! Ben. Well, VIM cross-compiles quite nicely, haven't had an issues yet (I'm cross-compiling to x86, PowerPC and ARM5). I've posted a patch a while ago to fix configure.in. The patch includes a README. Marc -- Marc Haisenko Comdasys AG Rüdesheimer Str. 7 80686 München Germany Tel.: +49 (0)89 548 433 321 --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Porting vim to Astlinux
Sorry, forgot to attach the patch.
--
Marc Haisenko
Comdasys AG
Rüdesheimer Str. 7
80686 München
Germany
Tel.: +49 (0)89 548 433 321
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
diff -Nur vim71.orig/src/configure.in vim71/src/configure.in
--- vim71.orig/src/configure.in 2007-05-12 11:19:27.0 +0200
+++ vim71/src/configure.in 2007-09-21 14:58:23.0 +0200
@@ -47,13 +47,6 @@
fi
fi
-dnl If configure thinks we are cross compiling, there is probably something
-dnl wrong with the CC or CFLAGS settings, give an understandable error message
-if test $cross_compiling = yes; then
- AC_MSG_ERROR([cannot compile a simple program, check CC and CFLAGS
- (cross compiling doesn't work)])
-fi
-
dnl gcc-cpp has the wonderful -MM option to produce nicer dependencies.
dnl But gcc 3.1 changed the meaning! See near the end.
test $GCC = yes CPP_MM=M; AC_SUBST(CPP_MM)
@@ -1986,11 +1979,24 @@
dnl Checks for libraries and include files.
-AC_MSG_CHECKING(quality of toupper)
-AC_TRY_RUN([#include ctype.h
-main() { exit(toupper('A') == 'A' tolower('z') == 'z'); }],
- AC_DEFINE(BROKEN_TOUPPER) AC_MSG_RESULT(bad),
- AC_MSG_RESULT(good), AC_MSG_ERROR(failed to compile test program))
+AC_CACHE_CHECK([toupper is broken],[vim_cv_toupper_broken],
+ [
+AC_RUN_IFELSE([
+#include ctype.h
+main() { exit(toupper('A') == 'A' tolower('z') == 'z'); }
+ ],[
+vim_cv_toupper_broken=yes
+AC_MSG_RESULT(yes)
+ ],[
+vim_cv_toupper_broken=no
+AC_MSG_RESULT(no)
+ ],[
+AC_MSG_ERROR(cross-compiling: please set 'vim_cv_toupper_broken')
+ ])])
+
+if test x$vim_cv_toupper_broken = xyes ; then
+ AC_DEFINE(BROKEN_TOUPPER)
+fi
AC_MSG_CHECKING(whether __DATE__ and __TIME__ work)
AC_TRY_COMPILE(, [printf(( __DATE__ __TIME__ ));],
@@ -2202,28 +2208,52 @@
Or specify the name of the library with --with-tlib.]))
fi
-AC_MSG_CHECKING(whether we talk terminfo)
-AC_TRY_RUN([
+AC_CACHE_CHECK([whether we talk terminfo], [vim_cv_terminfo],
+ [
+AC_RUN_IFELSE([
#ifdef HAVE_TERMCAP_H
# include termcap.h
#endif
main()
-{char *s; s=(char *)tgoto(%p1%d, 0, 1); exit(!strcmp(s==0 ? : s, 1)); }],
- AC_MSG_RESULT([no -- we are in termcap land]),
- AC_MSG_RESULT([yes -- terminfo spoken here]); AC_DEFINE(TERMINFO),
- AC_MSG_ERROR(failed to compile test program.))
+{char *s; s=(char *)tgoto(%p1%d, 0, 1); exit(!strcmp(s==0 ? : s, 1)); }
+],[
+ vim_cv_terminfo=no
+ AC_MSG_RESULT([no -- we are in termcap land])
+],[
+ vim_cv_terminfo=yes
+ AC_MSG_RESULT([yes -- terminfo spoken here])
+],[
+ AC_MSG_ERROR(cross-compiling: please set 'vim_cv_terminfo')
+])
+ ])
+
+if test x$vim_cv_terminfo = xyes ; then
+ AC_DEFINE(TERMINFO)
+fi
if test x$olibs != x$LIBS; then
- AC_MSG_CHECKING(what tgetent() returns for an unknown terminal)
- AC_TRY_RUN([
+ AC_CACHE_CHECK([what tgetent() returns for an unknown terminal], [vim_cv_tgent],
+[
+ AC_RUN_IFELSE([
#ifdef HAVE_TERMCAP_H
# include termcap.h
#endif
main()
-{char s[1]; int res = tgetent(s, thisterminaldoesnotexist); exit(res != 0); }],
- AC_MSG_RESULT(zero); AC_DEFINE(TGETENT_ZERO_ERR, 0),
- AC_MSG_RESULT(non-zero),
- AC_MSG_ERROR(failed to compile test program.))
+{char s[1]; int res = tgetent(s, thisterminaldoesnotexist); exit(res != 0); }
+ ],[
+ vim_cv_tgent=zero
+ AC_MSG_RESULT(zero)
+ ],[
+ vim_cv_tgent=non-zero
+ AC_MSG_RESULT(non-zero)
+ ],[
+ AC_MSG_ERROR(failed to compile test program.)
+ ])
+])
+
+ if test x$vim_cv_tgent = xzero ; then
+AC_DEFINE(TGETENT_ZERO_ERR, 0)
+ fi
fi
AC_MSG_CHECKING(whether termcap.h contains ospeed)
@@ -2333,9 +2363,10 @@
dnl pty mode/group handling
dnl
dnl support provided by Luke Mewburn [EMAIL PROTECTED], 931222
-AC_MSG_CHECKING(default tty permissions/group)
rm -f conftest_grp
-AC_TRY_RUN([
+AC_CACHE_CHECK([default tty permissions/group], [vim_cv_tty_group],
+ [
+AC_RUN_IFELSE([
#include sys/types.h
#include sys/stat.h
#include stdio.h
@@ -2363,20 +2394,35 @@
fclose(fp);
exit(0);
}
-],[
-if test -f conftest_grp; then
- ptygrp=`cat conftest_grp`
- AC_MSG_RESULT([pty mode: 0620, group: $ptygrp])
- AC_DEFINE(PTYMODE, 0620)
- AC_DEFINE_UNQUOTED(PTYGROUP,$ptygrp)
-else
+],[
+ if test -f conftest_grp; then
+ vim_cv_tty_group=`cat conftest_grp`
+ if test x$vim_cv_tty_mode = x ; then
+ vim_cv_tty_mode=0620
+ fi
+ AC_MSG_RESULT([pty mode: $vim_cv_tty_mode, group: $vim_cv_tty_group])
+ else
+ vim_cv_tty_group=world
AC_MSG_RESULT([ptys are world accessable])
-fi
-],
-AC_MSG_RESULT([can't determine - assume ptys are world accessable]),
-AC_MSG_ERROR(failed to compile test program))
+ fi
+],[
+ vim_cv_tty_group=world
+ AC_MSG_RESULT([can't determine
Re: [PATCH] Enable cross-compiling
On Monday 24 September 2007 12:52, Tony Mechelynck wrote: Marc Haisenko wrote: Hi folks, I've finished the INSTALL.cross file. Comments ? Marc If you want consistency with the other files, shouldn't this be named INSTALLcross.txt instead? Best regards, Tony. Maybe, yes... I saw these INSTALL*.txt files mentioned in the INSTALL file but there are none in my vim-7.1.tar.bz2 ? Do you know why ? Marc -- Marc Haisenko Comdasys AG Rüdesheimer Straße 7 D-80686 München Tel: +49 (0)89 - 548 433 321 e-mail: [EMAIL PROTECTED] http://www.comdasys.com --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
