Re: [PATCH] tests: don't use assert/abort on MSVC as they are interactive.
Den 2010-10-05 13:33 skrev Peter Rosin: Den 2010-09-30 09:44 skrev Peter Rosin: Maybe the shopt isn't needed after all. If the SetErrorMode call checks if the SEM_FAILCRITICALERRORS is already set, that could be used to determine if the CREATE_DEFAULT_ERROR_MODE flag should be added in spawn_guts. Then you could start an MSYS process with a custom error mode, and the error mode would be inherited. Hopefully anyway, I might easily have missed something... I have implemented exactly that and just posted this to the MinGW patch tracker: http://sourceforge.net/tracker/index.php?func=detailaid=3081421group_id=2435atid=302435 The silence is deafening. I wonder if I should have been more explicit about the implications of this patch? Let me spell it out, I can run the libtool testsuite on MSYS without having to dismiss a single dialog, independent of which compiler I'm using. All tests are non- interactive if you patch and start MSYS as described in the above tracker. If you want the dialogs, then simply start MSYS as you have always done and it will behave as it has always done. I find the patch really nice! Chuck, have you looked at this? Cheers, Peter
Re: [PATCH] tests: don't use assert/abort on MSVC as they are interactive.
Hi Peter, On 20 Oct 2010, at 13:31, Peter Rosin wrote: Den 2010-10-05 13:33 skrev Peter Rosin: Den 2010-09-30 09:44 skrev Peter Rosin: Maybe the shopt isn't needed after all. If the SetErrorMode call checks if the SEM_FAILCRITICALERRORS is already set, that could be used to determine if the CREATE_DEFAULT_ERROR_MODE flag should be added in spawn_guts. Then you could start an MSYS process with a custom error mode, and the error mode would be inherited. Hopefully anyway, I might easily have missed something... I have implemented exactly that and just posted this to the MinGW patch tracker: http://sourceforge.net/tracker/index.php?func=detailaid=3081421group_id=2435atid=302435 The silence is deafening. I wonder if I should have been more explicit about the implications of this patch? Let me spell it out, I can run the libtool testsuite on MSYS without having to dismiss a single dialog, independent of which compiler I'm using. All tests are non- interactive if you patch and start MSYS as described in the above tracker. If you want the dialogs, then simply start MSYS as you have always done and it will behave as it has always done. I find the patch really nice! If you are confident the patch is good, and doesn't need peer review, you can commit under the 72 hour rule as long as no-one has asked for more time to review or expressed doubts about applying it. If you're not confident about the patch, and would rather get a peer review before committing, then keep pinging like this until someone takes a look. I am following the lists, but I'm short on time, and don't have (or want) access to any windows machines to determine whether this works as advertised. Briefly following your link, this looks like a mingw patch anyway... there is no error-mode.c file in libtool; did you post the wrong link? Cheers, -- Gary V. Vaughan (g...@gnu.org) PGP.sig Description: This is a digitally signed message part
Re: [PATCH] tests: don't use assert/abort on MSVC as they are interactive.
Hi Gary, Den 2010-10-20 08:55 skrev Gary V. Vaughan: On 20 Oct 2010, at 13:31, Peter Rosin wrote: Den 2010-10-05 13:33 skrev Peter Rosin: Den 2010-09-30 09:44 skrev Peter Rosin: Maybe the shopt isn't needed after all. If the SetErrorMode call checks if the SEM_FAILCRITICALERRORS is already set, that could be used to determine if the CREATE_DEFAULT_ERROR_MODE flag should be added in spawn_guts. Then you could start an MSYS process with a custom error mode, and the error mode would be inherited. Hopefully anyway, I might easily have missed something... I have implemented exactly that and just posted this to the MinGW patch tracker: http://sourceforge.net/tracker/index.php?func=detailaid=3081421group_id=2435atid=302435 The silence is deafening. I wonder if I should have been more explicit about the implications of this patch? Let me spell it out, I can run the libtool testsuite on MSYS without having to dismiss a single dialog, independent of which compiler I'm using. All tests are non- interactive if you patch and start MSYS as described in the above tracker. If you want the dialogs, then simply start MSYS as you have always done and it will behave as it has always done. I find the patch really nice! If you are confident the patch is good, and doesn't need peer review, you can commit under the 72 hour rule as long as no-one has asked for more time to review or expressed doubts about applying it. If you're not confident about the patch, and would rather get a peer review before committing, then keep pinging like this until someone takes a look. I am following the lists, but I'm short on time, and don't have (or want) access to any windows machines to determine whether this works as advertised. Briefly following your link, this looks like a mingw patch anyway... there is no error-mode.c file in libtool; did you post the wrong link? No, everything is as intended. Well, apart from the fact that I made you waste time on this. I should have been more explicit about this being a patch for another project, with the only relevance for libtool being that it helps the libtool testsuite when it runs on MSYS. It is indeed a patch for MSYS (shipped by the MinGW crew) and not for libtool. But I thought at least Chuck would have something to say since he maintains libtool for the MinGW project and I imagine that he does a fair bit of libtool hacking on MSYS, at least from time to time, where this patch would be welcome. Cheers, Peter
Re: [PATCH] tests: don't use assert/abort on MSVC as they are interactive.
On 10/20/2010 2:31 AM, Peter Rosin wrote:
Den 2010-10-05 13:33 skrev Peter Rosin:
I have implemented exactly that and just posted this to the MinGW patch
tracker:
http://sourceforge.net/tracker/index.php?func=detailaid=3081421group_id=2435atid=302435
The silence is deafening.
Chuck, have you looked at this?
Yes, I have -- but MSYS patches are Cesar's domain. I guess I could
ping him...
wait...
Looks like Cesar responded earlier today. Coincidence?
I understand wanting to keep the current (popup-showing) behavior for
most MSYS process trees, since many users may rely on that information
to indicate real problems.
I wish there was some way to activate your patch other than launching
the top-level shell/window thru a run.exe-like starter app...but since
it has to be done before any other msys apps in the process tree start,
that means it probably should be done inside msys.bat itself (via an
--option?) somehow.
However, msys.bat launches its target (either rxvt or bash) via the
win32 program start.exe. So, we could launch the target using EITHER
start.exe OR your wrapper, depending on --no-popups. But then the
wrapper would need to be a lot smarter (e.g. use CreateProcess instead
of execve, so that it can set the CONSOLE hiding flags...but then, THAT
would use a different startup path inside msys.dll, and your patch
wouldn't activate!)
So, I don't think there is a better way than
error_mode.exe -cgf C:/mingw/msys/1.0/msys.bat [--rxvt]
if we (MSYS) want to preserve existing popup-showing behavior at all --
which I think we do. MAYBE the following (pseudo-bat-code, where
MSYS_NOPOP is set based on --no-popups arg to .bat file):
if x%MSYS_NOPOP% == x goto startrp
start %WD%error_mode -cgf /bin/rxvt {other args}
exit
:startrp
start %WD%rxvt {other args}
exit
with similar changes for the --no-rxvt case. It's sorta clunky, but it
might work.
But...that's something for the msys-dvlpr list to hash out.
Technically, I think your patch is fine.
--
Chuck
Re: [PATCH] tests: don't use assert/abort on MSVC as they are interactive.
Den 2010-10-20 17:55 skrev Charles Wilson:
On 10/20/2010 2:31 AM, Peter Rosin wrote:
Den 2010-10-05 13:33 skrev Peter Rosin:
I have implemented exactly that and just posted this to the MinGW patch
tracker:
http://sourceforge.net/tracker/index.php?func=detailaid=3081421group_id=2435atid=302435
The silence is deafening.
Chuck, have you looked at this?
Yes, I have -- but MSYS patches are Cesar's domain. I guess I could
ping him...
wait...
Looks like Cesar responded earlier today. Coincidence?
Yes, I think that was a coincidence.
I understand wanting to keep the current (popup-showing) behavior for
most MSYS process trees, since many users may rely on that information
to indicate real problems.
Yes, that was high priority.
I wish there was some way to activate your patch other than launching
the top-level shell/window thru a run.exe-like starter app...but since
it has to be done before any other msys apps in the process tree start,
that means it probably should be done inside msys.bat itself (via an
--option?) somehow.
The other ways to activate that I can think of is via some environment
variable, but checking that for every new process is going to add on
to the already painful fork cost. Either that or using some interface
like cygwin_internal to manipulate myself-children_error_mode, but
that would require adding a shopt to bash that sets the desired error
mode and that it should be inherited by future children. And what about
other shells?
However, msys.bat launches its target (either rxvt or bash) via the
win32 program start.exe. So, we could launch the target using EITHER
start.exe OR your wrapper, depending on --no-popups. But then the
wrapper would need to be a lot smarter (e.g. use CreateProcess instead
of execve, so that it can set the CONSOLE hiding flags...but then, THAT
would use a different startup path inside msys.dll, and your patch
wouldn't activate!)
So, I don't think there is a better way than
error_mode.exe -cgf C:/mingw/msys/1.0/msys.bat [--rxvt]
if we (MSYS) want to preserve existing popup-showing behavior at all --
which I think we do. MAYBE the following (pseudo-bat-code, where
MSYS_NOPOP is set based on --no-popups arg to .bat file):
if x%MSYS_NOPOP% == x goto startrp
start %WD%error_mode -cgf /bin/rxvt {other args}
exit
:startrp
start %WD%rxvt {other args}
exit
with similar changes for the --no-rxvt case. It's sorta clunky, but it
might work.
Yes, integration in msys.bat would be nice. But this is a corner case,
and if you create a shortcut (which I have done), it really doesn't
matter how you spell it. But as I said, it still would be nice.
But...that's something for the msys-dvlpr list to hash out.
Technically, I think your patch is fine.
I assume you mean the closed mingw-dvlpr list? In that case, I can't
join the fun, since I'm not a member...
(This is getting off topic)
Cheers,
Peter
Re: [PATCH] tests: don't use assert/abort on MSVC as they are interactive.
Den 2010-10-20 18:53 skrev Peter Rosin:
Den 2010-10-20 17:55 skrev Charles Wilson:
if we (MSYS) want to preserve existing popup-showing behavior at all --
which I think we do. MAYBE the following (pseudo-bat-code, where
MSYS_NOPOP is set based on --no-popups arg to .bat file):
if x%MSYS_NOPOP% == x goto startrp
start %WD%error_mode -cgf /bin/rxvt {other args}
Forgot to say that I think that this needs to be something like
start %WD%error_mode -cgf %WD%rxvt {other args}
since error_mode must be a MinGW app, and thus does not understand
MSYS paths.
Cheers,
Peter
Re: [PATCH] tests: don't use assert/abort on MSVC as they are interactive.
On 10/20/2010 02:53 PM, Peter Rosin wrote: Den 2010-10-20 17:55 skrev Charles Wilson: On 10/20/2010 2:31 AM, Peter Rosin wrote: Den 2010-10-05 13:33 skrev Peter Rosin: I have implemented exactly that and just posted this to the MinGW patch tracker: http://sourceforge.net/tracker/index.php?func=detailaid=3081421group_id=2435atid=302435 The silence is deafening. Chuck, have you looked at this? Yes, I have -- but MSYS patches are Cesar's domain. I guess I could ping him... wait... Looks like Cesar responded earlier today. Coincidence? Yes, I think that was a coincidence. Not really. I follow this particular list, and noticed Peter's ping for his MSYS patch over here. Regards, Cesar
Re: [PATCH] tests: don't use assert/abort on MSVC as they are interactive.
Den 2010-09-30 09:44 skrev Peter Rosin: Maybe the shopt isn't needed after all. If the SetErrorMode call checks if the SEM_FAILCRITICALERRORS is already set, that could be used to determine if the CREATE_DEFAULT_ERROR_MODE flag should be added in spawn_guts. Then you could start an MSYS process with a custom error mode, and the error mode would be inherited. Hopefully anyway, I might easily have missed something... I have implemented exactly that and just posted this to the MinGW patch tracker: http://sourceforge.net/tracker/index.php?func=detailaid=3081421group_id=2435atid=302435 Cheers, Peter
Re: [PATCH] tests: don't use assert/abort on MSVC as they are interactive.
Hi Peter, * Peter Rosin wrote on Wed, Sep 29, 2010 at 11:21:11PM CEST: Den 2010-09-29 21:01 skrev Ralf Wildenhues: * Peter Rosin wrote on Wed, Sep 29, 2010 at 10:06:00AM CEST: Ok to push this one? I don't mind it, but I'll note that the patch will cause testsuite failures when no wrapper is actually used. This can happen - with --disable-shared passed toplevel, or on static-only systems, - on systems where a wrapper is not needed even in shared mode At least for lalib-syntax it will thus cause failure for the wrong reason (the current XFAIL hides that I guess). I think you are wrong here. Well, all the better then, both because that means the situation is better than feared, and because you're not letting yourself get distracted. lalib-syntax only looks at the 1st argument so the fact that I have added a 2nd argument should not matter in practice. We don't call it without arguments so its argc 2 check is just cosmetics. For demo-relink that is irrelevant, as demo/main.c ignores its arguments, tests/depdemo/main.c however also uses them. The only prior argument to depdemo/main.c that I could find was -alt, which is explicitly tested for in main(), so if an extra --lt- option bleeds in, it should be ignored and not cause any harm. I might have missed something though. So, I actually don't think the patch will affect the testsuite results. OK good. Hmm, --lt-no-interactive instead of --lt-no-popup, for consistency with check-(non)interactive? --lt-no-interactive is fine by me, but why not --lt-non-interactive? Hmm. Was thinking about how GCC does options, I guess, with -ffoo mapped to -fno-foo. no-interactive sounds weirder when spoken out, though. I'll think some more about the general issue. What I really would like is a bash shopt to set the error mode from the shell when running testsuites. Then we could really forget this issue. Either that or some way to make MSYS not force the default error mode so hard. I have tried to start MSYS with an inherited error mode, but I couldn't make it stick. I guess I need to start digging in the sources of those projects, and see if I can see what would be the best/easiest solution. That would indeed be cool. IIUC your followup post shows this isn't so easy though. So feel free to go ahead with the change. Thanks, Ralf
Re: [PATCH] tests: don't use assert/abort on MSVC as they are interactive.
Den 2010-09-29 23:21 skrev Peter Rosin: I'll think some more about the general issue. What I really would like is a bash shopt to set the error mode from the shell when running testsuites. Then we could really forget this issue. Either that or some way to make MSYS not force the default error mode so hard. I have tried to start MSYS with an inherited error mode, but I couldn't make it stick. I guess I need to start digging in the sources of those projects, and see if I can see what would be the best/easiest solution. Ok, since I find this: int flags = CREATE_DEFAULT_ERROR_MODE | GetPriorityClass (hMainProc); in spawn_guts, line 616 in (1), introducing a shopt in bash is with all likelihood going to be futile. I wonder if that CREATE_DEFAULT_ERROR_MODE can be made optional somehow, or even removed? I don't really see what good it's doing. Sure, it makes it certain how things are going to behave when you are not relying on inheriting the error mode, but it's rather inflexible. *thinks* Maybe MSYS processes set the error mode on init, and this flag is set here so that you do get the popup instead of just a silent exit status when you are running a program that e.g. is missing a dll? *digging some more* Yes, that appears to be the case, since I find this: (void) SetErrorMode (SEM_FAILCRITICALERRORS); in dll_crt0_1, line 670 in (2). So, it is not acceptable to simply remove CREATE_DEFAULT_ERROR_MODE above. Which means that *both* a shopt in the shell and some support for it in MSYS is going to be needed. Good luck with that, because I'm not going to try anytime soon. *thinks again* Maybe the shopt isn't needed after all. If the SetErrorMode call checks if the SEM_FAILCRITICALERRORS is already set, that could be used to determine if the CREATE_DEFAULT_ERROR_MODE flag should be added in spawn_guts. Then you could start an MSYS process with a custom error mode, and the error mode would be inherited. Hopefully anyway, I might easily have missed something... Cheers, Peter (1) http://mingw.cvs.sourceforge.net/viewvc/mingw/msys/rt/src/winsup/cygwin/spawn.cc?revision=1.29view=markup (2) http://mingw.cvs.sourceforge.net/viewvc/mingw/msys/rt/src/winsup/cygwin/dcrt0.cc?revision=1.11view=markup
Re: [PATCH] tests: don't use assert/abort on MSVC as they are interactive.
Den 2010-09-28 22:09 skrev Ralf Wildenhues:
Hello Peter,
* Peter Rosin wrote on Tue, Sep 28, 2010 at 08:08:13PM CEST:
Ok to push?
Avoiding assert doesn't seem like a scalable solution: lots of packages
use assert for testing. assert is ANSI C. We use assert in slist.at.
Is there a way to avoid popups?
Hmm, or, if there is no way, then I guess you're saying popups are ok if
it only happens for unexpected failures. Then I don't have a good
argument against the patch any more.
I started out by setting the w32 error mode directly in the executable in
the test, and that revealed that I was wrong in what error mode flag
this was connected to (I thought SEM_FAILCRITICALERRORS, but it really is
SEM_NOGPFAULTERRORBOX). That revelation made me reimplement an idea I
had a while back that I didn't get to work because of that misconception.
So, here's a patch with a different take on the problem that makes the old
testsuite non-interactive on MSYS, and that fixes this non-interactiveness
too. The two remaining interactive tests (link-order2.at and static.at)
unfortunately runs installed binaries so this scheme is not working there.
I didn't want to unconditionally fiddle the error mode when running through
the wrapper, as that would royally screw users depending on the error
dialog to be there.
Cygwin is always running with this error mode (I think), MSYS is not.
Ok to push this one?
Cheers,
Peter
From fa648e86ec81defc48e035ca952635e2dc42cc51 Mon Sep 17 00:00:00 2001
From: Peter Rosin p...@lysator.liu.se
Date: Wed, 29 Sep 2010 09:59:18 +0200
Subject: [PATCH] tests: make more tests non-interactive on MSYS.
* libltdl/config/ltmain.m4sh (func_emit_cwrapperexe_src):
Recognize --lt-no-popup and set the w32 error mode so that
Windows do not popup dialogs if the option is seen.
* libltdl/config/ltmain.m4sh (func_parse_lt_options): Recognize
--lt-no-popup and strip it out (with no side effect, there is
no API for adjusting the w32 error mode from within a shell).
* tests/demo-relink.test, tests/depdemo-relink.test: Use the
above option to make the test non-interactive on MSYS.
tests/lalib-syntax.at: Use the above option to make the test
non-interactive on MSYS/MSVC (the MSVC version of assert/abort
pops up an error dialog).
* docs/libtool.texi (Wrapper executables): Document the new
option of the wrapper.
Signed-off-by: Peter Rosin p...@lysator.liu.se
---
ChangeLog | 17 +
doc/libtool.texi |7 +++
libltdl/config/ltmain.m4sh | 16 ++--
tests/demo-relink.test |2 +-
tests/depdemo-relink.test |2 +-
tests/lalib-syntax.at |2 +-
6 files changed, 41 insertions(+), 5 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index a7aa489..3967d0a 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,20 @@
+2010-09-29 Peter Rosin p...@lysator.liu.se
+
+ tests: make more tests non-interactive on MSYS.
+ * libltdl/config/ltmain.m4sh (func_emit_cwrapperexe_src):
+ Recognize --lt-no-popup and set the w32 error mode so that
+ Windows do not popup dialogs if the option is seen.
+ * libltdl/config/ltmain.m4sh (func_parse_lt_options): Recognize
+ --lt-no-popup and strip it out (with no side effect, there is
+ no API for adjusting the w32 error mode from within a shell).
+ * tests/demo-relink.test, tests/depdemo-relink.test: Use the
+ above option to make the test non-interactive on MSYS.
+ tests/lalib-syntax.at: Use the above option to make the test
+ non-interactive on MSYS/MSVC (the MSVC version of assert/abort
+ pops up an error dialog).
+ * docs/libtool.texi (Wrapper executables): Document the new
+ option of the wrapper.
+
2010-09-27 Peter Rosin p...@lysator.liu.se
tests: check if sys_lib_search_path_spec works on MSVC.
diff --git a/doc/libtool.texi b/doc/libtool.texi
index cd5a181..a9f6c5a 100644
--- a/doc/libtool.texi
+++ b/doc/libtool.texi
@@ -904,6 +904,13 @@ These command line options include:
Causes the wrapper to print a copy of the wrapper @emph{script}
to @code{stdout}, and exit.
+...@item --lt-no-popup
+This option makes the wrapper attempt to set things up so that the
+program does not issue any error dialogs, and instead report errors with
+an exit status as is the normal way. This is particularly useful in
+testsuites on w32, as w32 has a tendency to pop up error dialogs for
+certain errors potentially making the testsuite non-interactive.
+
@item --lt-debug
Causes the wrapper to print diagnostic information to @code{stdout},
before launching the program executable.
diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
index 0418007..cacf68f 100644
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -3111,8 +3111,8 @@ _LTECHO_EOF'
# (application programs are unlikely to have options which match
# this pattern).
#
-# There are only two supported options: --lt-debug and
-#
Re: [PATCH] tests: don't use assert/abort on MSVC as they are interactive.
On 9/29/2010 4:06 AM, Peter Rosin wrote: Cygwin is always running with this error mode (I think), MSYS is not. Cygwin no longer supports Win9x, MSYS does. Will this patch cause any issues if people try to use libtool + MSYS on a Win9x system? -- Chuck
Re: [PATCH] tests: don't use assert/abort on MSVC as they are interactive.
Den 2010-09-29 15:47 skrev Charles Wilson: On 9/29/2010 4:06 AM, Peter Rosin wrote: Cygwin is always running with this error mode (I think), MSYS is not. Cygwin no longer supports Win9x, MSYS does. Will this patch cause any issues if people try to use libtool + MSYS on a Win9x system? I don't foresee any problems, because SetErrorMode is really old. You were worrying about the entry point not being there, right? Cheers, Peter
Re: [PATCH] tests: don't use assert/abort on MSVC as they are interactive.
On 9/29/2010 10:15 AM, Peter Rosin wrote: Den 2010-09-29 15:47 skrev Charles Wilson: Will this patch cause any issues if people try to use libtool + MSYS on a Win9x system? I don't foresee any problems, because SetErrorMode is really old. You were worrying about the entry point not being there, right? Right. Sadly, MSDN no longer even references things that old; from reading it, you'd think that *nothing* existed prior to w2k, and *every* current entry point was brand new with that version. SetErrorMode: Minimum Supported Client: Windows 2000 Professional So it's no longer even possible to discover exactly HOW old an API is, if it predates w2k. At least, not via MSDN. -- Chuck
Re: [PATCH] tests: don't use assert/abort on MSVC as they are interactive.
Den 2010-09-29 17:00 skrev Charles Wilson: On 9/29/2010 10:15 AM, Peter Rosin wrote: Den 2010-09-29 15:47 skrev Charles Wilson: Will this patch cause any issues if people try to use libtool + MSYS on a Win9x system? I don't foresee any problems, because SetErrorMode is really old. You were worrying about the entry point not being there, right? Right. Sadly, MSDN no longer even references things that old; from reading it, you'd think that *nothing* existed prior to w2k, and *every* current entry point was brand new with that version. SetErrorMode: Minimum Supported Client: Windows 2000 Professional Yes, that's a complete drag. So it's no longer even possible to discover exactly HOW old an API is, if it predates w2k. At least, not via MSDN. Well, there are pages like this: http://www.sybase.be/detail?id=47705 Anyway, SetErrorMode is win9x-safe. Cheers, Peter
Re: [PATCH] tests: don't use assert/abort on MSVC as they are interactive.
Hi Peter, * Peter Rosin wrote on Wed, Sep 29, 2010 at 10:06:00AM CEST: Ok to push this one? I don't mind it, but I'll note that the patch will cause testsuite failures when no wrapper is actually used. This can happen - with --disable-shared passed toplevel, or on static-only systems, - on systems where a wrapper is not needed even in shared mode At least for lalib-syntax it will thus cause failure for the wrong reason (the current XFAIL hides that I guess). For demo-relink that is irrelevant, as demo/main.c ignores its arguments, tests/depdemo/main.c however also uses them. (This need for internal knowledge about when wrappers are used, is why I disliked the arguments to them; or am I misremembering and we have changed the wrappers to be used in more cases for some reason?) Hmm, --lt-no-interactive instead of --lt-no-popup, for consistency with check-(non)interactive? Thanks, Ralf Subject: [PATCH] tests: make more tests non-interactive on MSYS. * libltdl/config/ltmain.m4sh (func_emit_cwrapperexe_src): Recognize --lt-no-popup and set the w32 error mode so that Windows do not popup dialogs if the option is seen. * libltdl/config/ltmain.m4sh (func_parse_lt_options): Recognize --lt-no-popup and strip it out (with no side effect, there is no API for adjusting the w32 error mode from within a shell). * tests/demo-relink.test, tests/depdemo-relink.test: Use the above option to make the test non-interactive on MSYS. tests/lalib-syntax.at: Use the above option to make the test non-interactive on MSYS/MSVC (the MSVC version of assert/abort pops up an error dialog). * docs/libtool.texi (Wrapper executables): Document the new option of the wrapper.
Re: [PATCH] tests: don't use assert/abort on MSVC as they are interactive.
Hi Ralf, Den 2010-09-29 21:01 skrev Ralf Wildenhues: * Peter Rosin wrote on Wed, Sep 29, 2010 at 10:06:00AM CEST: Ok to push this one? I don't mind it, but I'll note that the patch will cause testsuite failures when no wrapper is actually used. This can happen - with --disable-shared passed toplevel, or on static-only systems, - on systems where a wrapper is not needed even in shared mode At least for lalib-syntax it will thus cause failure for the wrong reason (the current XFAIL hides that I guess). I think you are wrong here. lalib-syntax only looks at the 1st argument so the fact that I have added a 2nd argument should not matter in practice. We don't call it without arguments so its argc 2 check is just cosmetics. For demo-relink that is irrelevant, as demo/main.c ignores its arguments, tests/depdemo/main.c however also uses them. The only prior argument to depdemo/main.c that I could find was -alt, which is explicitly tested for in main(), so if an extra --lt- option bleeds in, it should be ignored and not cause any harm. I might have missed something though. So, I actually don't think the patch will affect the testsuite results. (This need for internal knowledge about when wrappers are used, is why I disliked the arguments to them; or am I misremembering and we have changed the wrappers to be used in more cases for some reason?) Agreed, it is hard(ish) to determine if it is safe to add the --lt- argument and if unrelated changes are needed it is easy to regress. Hmm, --lt-no-interactive instead of --lt-no-popup, for consistency with check-(non)interactive? --lt-no-interactive is fine by me, but why not --lt-non-interactive? I'll think some more about the general issue. What I really would like is a bash shopt to set the error mode from the shell when running testsuites. Then we could really forget this issue. Either that or some way to make MSYS not force the default error mode so hard. I have tried to start MSYS with an inherited error mode, but I couldn't make it stick. I guess I need to start digging in the sources of those projects, and see if I can see what would be the best/easiest solution. Cheers, Peter
[PATCH] tests: don't use assert/abort on MSVC as they are interactive.
Hi!
Ok to push?
Cheers,
Peter
From f17e568aea90ea2def14d0d0825da927b4a2421d Mon Sep 17 00:00:00 2001
From: Peter Rosin p...@lysator.liu.se
Date: Tue, 28 Sep 2010 20:02:22 +0200
Subject: [PATCH] tests: don't use assert/abort on MSVC as they are interactive.
* tests/lalib-syntax.at (main.c): Rewrite to not use assert as
assert in turn calls abort which pops up a dialog on MSVC.
Signed-off-by: Peter Rosin p...@lysator.liu.se
---
ChangeLog |6 ++
tests/lalib-syntax.at | 16 +++-
2 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index a7aa489..ce0c144 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2010-09-28 Peter Rosin p...@lysator.liu.se
+
+ tests: don't use assert/abort on MSVC as they are interactive.
+ * tests/lalib-syntax.at (main.c): Rewrite to not use assert as
+ assert in turn calls abort which pops up a dialog on MSVC.
+
2010-09-27 Peter Rosin p...@lysator.liu.se
tests: check if sys_lib_search_path_spec works on MSVC.
diff --git a/tests/lalib-syntax.at b/tests/lalib-syntax.at
index 0f78ca8..45fc2d6 100644
--- a/tests/lalib-syntax.at
+++ b/tests/lalib-syntax.at
@@ -30,7 +30,6 @@ AT_XFAIL_IF([:]) dnl libltdl does not consistently return
non-NULL lt_dlerror
AT_DATA([main.c],
[[#include ltdl.h
#include stdio.h
-#include assert.h
int
main (int argc, char* argv[])
@@ -54,9 +53,16 @@ main (int argc, char* argv[])
else
{
const char *error = lt_dlerror ();
- assert (error != NULL);
- printf (plugin failed to open: %s\n, error);
- err = 1;
+ if (NULL != error)
+ {
+ printf (plugin failed to open: %s\n, error);
+ err = 1;
+ }
+ else
+ {
+ printf (plugin failed to open\n);
+ err = 3;
+ }
}
lt_dlexit ();
return err;
@@ -131,7 +137,7 @@ libdir='/somewhere'
for file in ./missing-closing-quote.la ./wrong-quotes.la \
./no-dlname.la ./nonexistent-dlname.la; do
LT_AT_EXEC_CHECK([./main], [1], [stdout], [ignore], [$file])
- AT_CHECK([grep 'plugin failed to open' stdout], [], [ignore])
+ AT_CHECK([grep 'plugin failed to open:' stdout], [], [ignore])
done
AT_CLEANUP
--
1.7.1
