Re: Test harness on VMS working, 58 tests currently failing.
On 03/01/2014 09:50 PM, John E. Malmberg wrote: On 2/28/2014 8:07 PM, John E. Malmberg wrote: I have the test harness apparently working on VMS. I need to fix up the DCL command procedure that is needed set up a number of foreign commands needed by it before submitting a patch. For which version? I assume for the current development stream from the git repository, correct? If no one else is interested in immediately running the test harness on VMS, I can wait on submitting a patch until I determine what is causing all the test failures. So far running the test harness on VMS will require: Perl 5.18.1 or later. GNV 2.1.3 or later. Bash 4.2.45 or later. Coreutils 8.21 or later. From what I see, the tests are coded in perl. Can you give a short description for what the other stuff is needed? Investigation showed two additional VMS specific issues in the test harness that were affecting the test run. After fixing those issues: 69 Tests in 90 Categories Failed (See .diff* files in work dir for details) :-( As there were 126 log files created, this indicates that more tests were being run. I do not know why the category count changed. Still more than 1/2 the tests are failing. If I determine that a test failure is an actual bug in the VMS port instead of a feature of the implementation do you want tickets filed to track the issue, or just the the patch to fix it if it is possible to fix? If you have a patch, then I don't think a ticket is necessary. Otherwise a ticket is right thing to track the bug. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: Test harness on VMS working, 58 tests currently failing.
On 3/2/2014 6:11 AM, h.becker wrote: On 03/01/2014 09:50 PM, John E. Malmberg wrote: On 2/28/2014 8:07 PM, John E. Malmberg wrote: I have the test harness apparently working on VMS. I need to fix up the DCL command procedure that is needed set up a number of foreign commands needed by it before submitting a patch. For which version? I assume for the current development stream from the git repository, correct? This is for master of course. If no one else is interested in immediately running the test harness on VMS, I can wait on submitting a patch until I determine what is causing all the test failures. So far running the test harness on VMS will require: Perl 5.18.1 or later. GNV 2.1.3 or later. Bash 4.2.45 or later. Coreutils 8.21 or later. From what I see, the tests are coded in perl. Can you give a short description for what the other stuff is needed? The make scripts expect a number of GNU utilities to be present and for Perl to use UNIX filename syntax. The following commands are used by makefiles in the tests. ar, cat, cc, cp, diff, echo, false, mkdir, rm, sleep, sh, and touch. GNV provides the ar, and cc commands. I have not updated them yet. The bash in GNV is ancient and buggy. The Bash 4.2.45 is much more reliable. Coreutils supplies the rest of the utilities. While they are also supplied by GNV, the Coreutils kit is more up to date with significant bug fixes. Example: rm -rf actually works. It appears that GNU make on VMS is attempting to emulate touch. This is showing up in several test failures where the touch command is used in the makefile. So it looks like that emulation needs to be improved. So I will need to have a DCL procedure set these up as foreign commands temporarily before running the run_make_tests.pl. I have not yet finished that script. My plan get the tests that can be run to pass before merging in the GNV fork which runs the Bash shell from GNU Make. Regards, -John ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [bug #41246] Allow to switch shell batch mode at runtime instead of build time
On Thu, 2014-02-27 at 10:53 +0900, Mike Hommey wrote: I have no problems with your original patch. I think I said that right there and then. If Paul agrees, I will commit it. Paul? I'll reiterate my position that (a) I've seen nothing showing that it's inherently impossible for make to figure out for itself what the right thing to do is, instead requiring the user to specify it (if there is such a case it should be simple to show an example and explain why it's impossible for make to decide), and (b) given that (a) is true, I'm not excited about adding a makefile flag to force the user to make that decision... what happens, for example, if someone does decide to fix this the right way in the future so the user option is not needed... now we have this make setting which doesn't make any sense but which we have to maintain for backward-compatibility. HOWEVER. I don't know nearly enough about all the variations and different possibilities on Windows to make sound judgements on the specific situation, so if Eli is OK with it then I'm OK with it. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [bug #41246] Allow to switch shell batch mode at runtime instead of build time
From: Paul Smith psm...@gnu.org Cc: Eli Zaretskii e...@gnu.org, bug-make@gnu.org, bo...@kolpackov.net Date: Sun, 02 Mar 2014 10:52:33 -0500 I'll reiterate my position that (a) I've seen nothing showing that it's inherently impossible for make to figure out for itself what the right thing to do is, instead requiring the user to specify it (if there is such a case it should be simple to show an example and explain why it's impossible for make to decide), and (b) given that (a) is true, I'm not excited about adding a makefile flag to force the user to make that decision... what happens, for example, if someone does decide to fix this the right way in the future so the user option is not needed... now we have this make setting which doesn't make any sense but which we have to maintain for backward-compatibility. I don't think (a) is possible, unless we decide that the option is only for when MSYS Bash is being used as the shell, and we teach Make to detect that flavor of Bash. If we do that, other users who just might need this mode of operation will not have any fire escapes. And if we don't want this only for MSYS, then I don't even know how to define the conditions under which this option will be needed. HOWEVER. I don't know nearly enough about all the variations and different possibilities on Windows to make sound judgements on the specific situation, so if Eli is OK with it then I'm OK with it. OK. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [bug #41246] Allow to switch shell batch mode at runtimeinstead of build time
From: Gisle Vanem gva...@yahoo.no Date: Sun, 2 Mar 2014 17:28:41 +0100 If it's the value of 'batch_mode_shell' we speak of, it can easily be changed by the new load feature. This diff: --- Git-Latest/makeint.h 2014-02-09 15:03:22 + +++ makeint.h 2014-03-02 17:10:53 + @@ -593,7 +593,7 @@ extern int rebuilding_makefiles, one_shell, output_sync, verify_flag; /* can we run commands via 'sh -c xxx' or must we use batch files? */ -extern int batch_mode_shell; +extern GMK_EXPORT int batch_mode_shell; --- and a small mk_test.dll shows it's possible to force this to 1 irrespective of 'BATCH_MODE_ONLY_SHELL' is defined on build time or not. With a .def-file there would be no need to patch anything. The OP could export other stuff and extend gnumake to his liking. Assuming this works (I didn't test), and assuming Mike is OK with that, so am I. Thanks. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
[bug #41760] VMS outputting extra blank lines.
URL: http://savannah.gnu.org/bugs/?41760 Summary: VMS outputting extra blank lines. Project: make Submitted by: wb8tyw Submitted on: Mon 03 Mar 2014 04:54:59 AM GMT Severity: 3 - Normal Item Group: Bug Status: None Privacy: Public Assigned to: None Open/Closed: Open Discussion Lock: Any Component Version: 4.0 Operating System: VMS Fixed Release: None Triage Status: None ___ Details: VMS is outputting extra blank lines in the output. For example a recipe line @continue results in a blank line in the output. I am patching my local copy of the test harness to not consider this a test failure until I can fix this. ___ Reply to this item at: http://savannah.gnu.org/bugs/?41760 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
[bug #41762] VMS not reporting circular dependency dropped.
Follow-up Comment #2, bug #41762 (project make): This has turned out to be a bug in the VMS port of the test harness. Redirecting STDERR on VMS from perl is different than on Unix. ___ Reply to this item at: http://savannah.gnu.org/bugs/?41762 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
