Re: vms:test variables
On Thu, Apr 3, 2014 at 9:56 PM, John E. Malmberg wrote: > This is the patches for the variables tests on VMS. I'm kinda surprised that you haven't worked out some direct coordination with the GNU make developers for the handling of these diffs. I don't see how sending them to the full bug-make list is useful; are you expecting random list members to provide feedback on them? Philip Guenther ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
vms:test variables
This is the patches for the variables tests on VMS. This is the last of the tests that I have patched so far. variables: Tests are failing because VMS is not handing pre-defined macros "<" in the names. Fixed up some expected output for VMS. GNUMAKEFLAGS: Test is failing because it is missing the entering/leaving directory messages. Probably related to recursions not working. Use pipe command on VMS. private: Two tests are skipped on VMS. Use pipe command on VMS. Regards, -John 0001-vms-test-variables.patch.gz Description: application/gzip ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
vms: test targets - INTERMEDIATE
This is the patch to the targets test for VMS. INTERMEDIATE: Tests are failing because Gnu Make is not echoing the "rm" command for removing files. Change to use VMS syntax. Regards, -John 0001-vms-test-targets-INTERMEDIATE.patch.gz Description: application/gzip ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
vms: test options patches.
These are the patches that VMS needs for the option tests. dash-k: 1 test is failing as it is not aborting when it should. Need posix encoded exit status, exit 1 is a success on VMS. dash-W: VMS vpaths need to be in VMS format. Fix up for null commands and not having a Posix shell. eval: 1 test is failing because recurse is not working right. VMS needs to use a pipe command. Regards, -John 0001-vms-test-options.patch.gz Description: application/gzip ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
vms: tests misc
This is the patch for the misc tests for VMS. general1: VMS can not handle the line continuation, needs a single line. TODO: there should be a way to make this work on VMS. general3: VMS can not handle the line continuation, skipping 7 tests. general4: CC program on VMS can not do a link. Regards, -John 0001-vms-test-misc.patch.gz Description: application/gzip ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
vms: tests functions directory patches.
This is changes for the functions directory test scripts. dir: The returned path is VMS format. eval: Skip one test on VMS. file: Change to use VMS pipe command. filter-out: VMS escaping is apparently different. foreach: VMS logical names showing up as "environment override" instead of "environment". origin: VMS logical names showing up as "environment override" instead of "environment". substitution: VMS needs to use a pipe command. word: Change to use VMS specific syntax. Regards, -John 0001-vms-tests-functions.patch.gz Description: application/gzip ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
vms: test features - patspecific-vars - vpathplus.
I previously posted the patch for the tests that should currently be skipped on VMS. This is the second part of the changes VMS needs to the tests in the features directory which completes this directory. patspecific_vars: Create a VMS format makefile Skip one test because VMS does not currently export environment variables. Possible enhancement to create DCL symbols for those environment variables. patternrules: Use pipe command multiple commands on a line. Use POSIX encoded exit code, as exit 1 is success on VMS. reinvoke: One test is failing to interpret a macro properly. Convert makefile and result to VMS syntax. se_explicit: VMS makefile needs hack to convert commas back to spaces. se_implicit: One test is failing, claiming no action needed. VMS makefile needs hack to convert commas back to spaces. se_statpat: VMS makefile needs hack to convert commas back to spaces. targetvars: VMS makefile needs VMS syntax. Two tests skipped because they need a Posix shell vpath: VMS makefile needs hack to convert commas back to spaces. vpath only works with VMS syntax files. Enhancement: The rest of Make on VMS works with either VMS or UNIX filename syntax, so VPATH should also. vpathgpath: Test is currently failing, apparently gpath not implemented. Converted test to use VMS syntax for VPATH. vpathplus: vpath only works with VMS syntax files. Use VMS type, pipe command and POSIX encoded exit codes. 0001-vms-tests-features-patternrules-to-vpathplus.patch.gz Description: application/gzip ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
vms: tests features - archives - parallelism
I previously posted the patch for the tests that should currently be skipped on VMS. This is the first part of the changes VMS needs to the tests in the features directory. I am sending the test changes in chunks to keep each commit size down. archives: Most tests are failing. This is what the test should probably look like once the feature is fully implemented on VMS. VMS currently needs to use real object files for the archives. This test currently uses the GNV AR wrapper to the VMS librarian for the recipes. conditionals: On VMS "continue" is used instead of ":". Possible enhancement is to have GNU Make on VMS automatically do this translation. Currently the I have the test harness patched to ignore the error message from passing ":" as a DCL command. Otherwise even more tests will eventually need to be patched for VMS. double_colon: On VMS, the pipe command is needed for multiple commands on a line. Possible enhancement for VMS is to automatically convert such lines if this can be detected. That enhancement could remove a lot of VMS specific changes to the test suite. Because the ; is the version delimiter for files on VMS, it may not be possible to do this detection. escape: On VMS one of the tests in this script is not valid when not using a Posix shell like GNV Bash. parallelism: Some tests are failing. The feature does not appear to be implemented on VMS. This is close to what the test should look like if the feature can be implemented. I did not skip this test as I am hopeful that the feature can be implemented. Regards, -John 0001-vms-tests-features-archives-to-parallelism.patch.gz Description: application/gzip ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: VMS progname and exit handling - Take 4
On 4/3/2014 4:15 PM, h.becker wrote:
On 04/02/2014 07:15 AM, John E. Malmberg wrote:
With 20/20 hindsight, a new set of macros should have been created that
returned the data with comma delimiters that could have been used with
VMS specific rules and recipes. That can not be done now with out
breaking backward VMS compatibility.
But having a set of functions to easily swap commas for spaces and the
reverse would probably still be useful to add, as it would be more
convenient than the hack I had to use.
As far as I understand you are testing GNV, you are not testing VMS.
Currently I am testing VMS behavior. Once the remaining VMS test issues
are resolved, then I will start adding the GNV code, and start running
tests in both modes.
No
suprise that there are problems with the special variables, which have
comma delimiters ($+, $^, $?). I think I already said this, from my
point of view, a GNV GNU make should be separated from a VMS GNU make.
I only want one GNU make binary on my system that I can use anywhere I
need to use GNU Make and have it just work.
Here, in commands.c, you want to have the FILE_LIST_SEPARATOR defined as
' ' and not as ',' as it is in the #if VMS: you need to turn off the VMS
macro or add an own GNV macro.
Or make it a runtime behavior based on the presence of getenv("SHELL")
which GNU make is already checking for the other operating systems and
adjusting its behavior.
Regards,
-John
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
RE: Excessive $(strip)
> I'd say that make itself is sloppy wrt whitespace, where sometimes
> newlines are considered to be whitespace, othertimes not.
...
> the "word" family of functions do not.
Nice example. The source seems to draw a distinction between isblank,
terminology available, I learn, in C99, and the more familiar isspace. The
word "blanks" is used in the documentation, but not as frequently as the source
suggests and not, afaics, in relation to the "words" function. I retract my
previous suggested patch in favor of this. It doesn't go nearly far enough,
but verifying each mention of whitespace now looks like more than I'd bargained
for.
martind@whitewater:~/download/make-git/make$ git diff
diff --git a/doc/make.texi b/doc/make.texi
index 8fbdb61..2932c03 100644
--- a/doc/make.texi
+++ b/doc/make.texi
@@ -1173,9 +1173,9 @@ include @var{filenames}@dots{}
Extra spaces are allowed and ignored at the beginning of the line, but
the first character must not be a tab (or the value of
@code{.RECIPEPREFIX})---if the line begins with a tab, it will be
-considered a recipe line. Whitespace is required between
+considered a recipe line. At least one blank is required between
@code{include} and the file names, and between file names; extra
-whitespace is ignored there and at the end of the directive. A
+blanks are ignored there and at the end of the directive. A
comment starting with @samp{#} is allowed at the end of the line. If
the file names contain any variable or function references, they are
expanded. @xref{Using Variables, ,How to Use Variables}.
@@ -7522,7 +7522,7 @@ $(file @var{op} @var{filename},@var{text})
The operator @var{op} can be either @code{>} which indicates overwrite
mode, or @code{>>} which indicates append mode. The @var{filename}
indicates the file to be written to. There may optionally be
-whitespace between the operator and the file name.
+blanks between the operator and the file name.
When the @code{file} function is expanded all its arguments are
expanded first, then the file indicated by @var{filename} will be
martind@whitewater:~/download/make-git/make$
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
Re: VMS progname and exit handling - Take 4
On 04/02/2014 07:15 AM, John E. Malmberg wrote: > On 4/1/2014 4:22 PM, h.becker wrote: >> On 04/01/2014 06:41 AM, John E. Malmberg wrote: >>> If you have the make variable be a MCR command, it has a space which can >>> have side effects when if the resulting string is processed by other >>> strings or macros. >> >> You mentioned this already. Can you point me to an example where this >> fails? Is this in a test, which I couldn't run so far? > > For the $(MAKE), macro, I do not have an example. OK, so when I have the tests running, I'll give it a try. (I manually converted a few makefiles created by the tests, to see if my new code for ONESHELL works as expected.) > In the tests though, several examples show up where the VMS specific > change to have some macros return "," delimiters instead of " " > delimiters broke the tests and required some workarounds. > > That is why adding an unexpected space to the value returned by a > standard macro can be predicted to have problems. > > With 20/20 hindsight, a new set of macros should have been created that > returned the data with comma delimiters that could have been used with > VMS specific rules and recipes. That can not be done now with out > breaking backward VMS compatibility. > > But having a set of functions to easily swap commas for spaces and the > reverse would probably still be useful to add, as it would be more > convenient than the hack I had to use. As far as I understand you are testing GNV, you are not testing VMS. No suprise that there are problems with the special variables, which have comma delimiters ($+, $^, $?). I think I already said this, from my point of view, a GNV GNU make should be separated from a VMS GNU make. Here, in commands.c, you want to have the FILE_LIST_SEPARATOR defined as ' ' and not as ',' as it is in the #if VMS: you need to turn off the VMS macro or add an own GNV macro. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: Excessive $(strip)
"Gisle Vanem" writes: > "Martin Dorey" wrote: > >>> this also removes the newlines. >>... >>> IMHO make 4.x has a too strict definition of white-space. >> >> http://pubs.opengroup.org/onlinepubs/95399/basedefs/xbd_chap07.html >> sayeth: >> >> "In the POSIX locale, at a minimum, the , , >> , , , and shall be >> included." > > Then the make manual is a bit sloppy in the use of "whitespace". I'd say that make itself is sloppy wrt whitespace, where sometimes newlines are considered to be whitespace, othertimes not. For example, as you reported, gmake's $(strip ...) function treats newlines as whitespace. But the "word" family of functions do not. define x foo bar endef all: echo $(words $(x)) echo $(words $(strip $(x))) Given a choice, I'd prefer the word functions treat newlines as whitespace. --jtc -- J.T. Conklin ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
RE: Excessive $(strip)
> Then the make manual is a bit sloppy in the use of "whitespace".
> E.g. from the man-page (3.3 Including Other Makefiles):
> "Whitespace is required between include and the file names, and between file
> names"
That sounded all too plausible, so I went through all the mentions of
/whitespace/i in make.texi with the intent to produce a patch. I think you've
got a good case with the quoted part of 3.3:
martind@whitewater:~/playpen$ cat variable-include.make
define VERTICAL_SPACE
endef
include $(VERTICAL_SPACE) filename.make
martind@whitewater:~/playpen$ make -f variable-include.make
variable-include.make:8:
: No such file or directory
make: *** No rule to make target '
'. Stop.
martind@whitewater:~/playpen$
> (plus section 5.9 etc. etc.)
I think Gisle refers to:
>> It is sometimes useful to define recipes which do nothing. This is done
>> simply by giving a recipe that consists of nothing but whitespace. For
>> example:
>>
>> target: ;
I tried a similar test case and that, unlike the 3.3 one, seemed to work:
martind@whitewater:~/playpen$ cat
vertical-whitespace-in-otherwise-empty-recipe.make
define VERTICAL_SPACE
endef
mytarget: $(VERTICAL_SPACE);
martind@whitewater:~/playpen$ make -f
vertical-whitespace-in-otherwise-empty-recipe.make
make: 'mytarget' is up to date.
martind@whitewater:~/playpen$
The file command seems less tolerant:
martind@whitewater:~/playpen$ cat vertical-whitespace-in-file-command.make
define VERTICAL_SPACE
endef
$(file > $(VERTICAL_SPACE) file.txt,text)
martind@whitewater:~/playpen$ rm -f file.txt; make -f
vertical-whitespace-in-file-command.make; cat file.txt
make: *** No targets. Stop.
cat: file.txt: No such file or directory
martind@whitewater:~/playpen$ echo *file.txt
file.txt
martind@whitewater:~/playpen$ rm *file.txt
martind@whitewater:~/playpen$
Heh. So my suggestion would be:
martind@whitewater:~/download/make-git/make/doc$ git diff
diff --git a/doc/make.texi b/doc/make.texi
index 8fbdb61..c7122ef 100644
--- a/doc/make.texi
+++ b/doc/make.texi
@@ -1173,9 +1173,9 @@ include @var{filenames}@dots{}
Extra spaces are allowed and ignored at the beginning of the line, but
the first character must not be a tab (or the value of
@code{.RECIPEPREFIX})---if the line begins with a tab, it will be
-considered a recipe line. Whitespace is required between
+considered a recipe line. Horizontal whitespace is required between
@code{include} and the file names, and between file names; extra
-whitespace is ignored there and at the end of the directive. A
+horizontal whitespace is ignored there and at the end of the directive. A
comment starting with @samp{#} is allowed at the end of the line. If
the file names contain any variable or function references, they are
expanded. @xref{Using Variables, ,How to Use Variables}.
@@ -7522,7 +7522,7 @@ $(file @var{op} @var{filename},@var{text})
The operator @var{op} can be either @code{>} which indicates overwrite
mode, or @code{>>} which indicates append mode. The @var{filename}
indicates the file to be written to. There may optionally be
-whitespace between the operator and the file name.
+horizontal whitespace between the operator and the file name.
When the @code{file} function is expanded all its arguments are
expanded first, then the file indicated by @var{filename} will be
martind@whitewater:~/download/make-git/make/doc$
I think that I've (somewhat deliberately) missed the real point, about the
syntax of makefiles, rather than the semantics. Perhaps that's the purview of
3.1 What Makefiles Contain and 3.1.1 Splitting Long Lines. Perhaps that could
afford to be explicit that directives, except for define, are terminated by an
unescaped newline.
-Original Message-
From: bug-make-bounces+martin.dorey=hds@gnu.org
[mailto:bug-make-bounces+martin.dorey=hds@gnu.org] On Behalf Of Gisle Vanem
Sent: Thursday, April 03, 2014 07:37
To: bug-make@gnu.org
Subject: Re: Excessive $(strip)
"Martin Dorey" wrote:
>> this also removes the newlines.
>...
>> IMHO make 4.x has a too strict definition of white-space.
>
> http://pubs.opengroup.org/onlinepubs/95399/basedefs/xbd_chap07.html
> sayeth:
>
> "In the POSIX locale, at a minimum, the , , ,
> , , and shall be included."
Then the make manual is a bit sloppy in the use of "whitespace".
E.g. from the man-page (3.3 Including Other Makefiles):
"Whitespace is required between include and the file names, and between file
names"
(plus section 5.9 etc. etc.)
So a:
include
foo.mak
---
should work if that definition was true everywhere, but it doesn't.
--gv
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
Re: Excessive $(strip)
"Martin Dorey" wrote: this also removes the newlines. ... IMHO make 4.x has a too strict definition of white-space. http://pubs.opengroup.org/onlinepubs/95399/basedefs/xbd_chap07.html sayeth: "In the POSIX locale, at a minimum, the , , , , , and shall be included." Then the make manual is a bit sloppy in the use of "whitespace". E.g. from the man-page (3.3 Including Other Makefiles): "Whitespace is required between include and the file names, and between file names" (plus section 5.9 etc. etc.) So a: include foo.mak --- should work if that definition was true everywhere, but it doesn't. --gv ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: Test harness patch for VMS.
On 4/1/2014 1:14 PM, h.becker wrote: I still can't get it to work: Missed that it also needs the "sh" as a foreign command to run Bash. Replacement patch attached. Regards, -John 0001-Test-harness-updates-for-VMS-take-2.patch.gz Description: application/gzip ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: VMS progname and exit handling - Take 4
On 4/1/2014 4:22 PM, h.becker wrote: On 04/01/2014 06:41 AM, John E. Malmberg wrote: If you have the make variable be a MCR command, it has a space which can have side effects when if the resulting string is processed by other strings or macros. You mentioned this already. Can you point me to an example where this fails? Is this in a test, which I couldn't run so far? For the $(MAKE), macro, I do not have an example. In the tests though, several examples show up where the VMS specific change to have some macros return "," delimiters instead of " " delimiters broke the tests and required some workarounds. That is why adding an unexpected space to the value returned by a standard macro can be predicted to have problems. With 20/20 hindsight, a new set of macros should have been created that returned the data with comma delimiters that could have been used with VMS specific rules and recipes. That can not be done now with out breaking backward VMS compatibility. But having a set of functions to easily swap commas for spaces and the reverse would probably still be useful to add, as it would be more convenient than the hack I had to use. Regards, -John ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
