[bug #63818] V=1 stopped working for Linux kernel module builds with make-4.4

[Martin Dorey]

URL:
  <https://savannah.gnu.org/bugs/?63818>

 Summary: V=1 stopped working for Linux kernel module builds
with make-4.4
   Group: make
   Submitter: mdorey
   Submitted: Sun 19 Feb 2023 11:59:36 AM PST
Severity: 3 - Normal
  Item Group: Documentation
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: 4.4
Operating System: POSIX-Based
   Fixed Release: None
   Triage Status: None


___

Follow-up Comments:


---
Date: Sun 19 Feb 2023 11:59:36 AM PST By: Martin Dorey 
As reported by Jan Palus in
https://lists.gnu.org/archive/html/bug-make/2022-11/msg00185.html with the
diagnosis polished by Paul in reply, the Linux kernel build system goes into
silent mode, stopping V=1 from telling you eg about the compiler commands,
with make-4.4 (but not earlier), if an s is present in certain parts of the
command line.  When compiling modules, this is more likely than it might seem,
because an argument of the form M=$(CURDIR) is given to make and s is common
in directory names.

This was fixed in the Linux kernel build system by Dmitry with help from
Masahiro Yamada for v6.2-rc1
(https://github.com/torvalds/linux/commit/4bf73588165ba7d32131a043775557a54b6e1db5).
 I think the problem arrived with v4.13-rc1
(https://github.com/torvalds/linux/commit/6f0fa58e459642b16901521cc58ac474b787ec5b).
 To put that in Debian terms, that means that Buster, Bullseye and (likely)
Bookworm are afflicted.

Here's a complete example, derived from https://sysprog21.github.io/lkmpg/ but
with the Makefile simplified the way I would have written it and a stray quote
left deliberately at the end of the .c file:


martind@pizzagate:~/tmp/make-kernel-MAKEFLAGS-with-an-s$ cat Makefile
obj-m += hello-1.o 

KVERSION ?= $(shell uname -r)
KVERSION := $(KVERSION)

TARGETS = modules clean
.PHONY: $(TARGETS)
$(TARGETS): %:; $(MAKE) -C /lib/modules/$(KVERSION)/build M=$(CURDIR) $@
martind@pizzagate:~/tmp/make-kernel-MAKEFLAGS-with-an-s$ cat hello-1.c 
/* 
 * hello-1.c - The simplest kernel module. 
 */ 
#include  /* Needed for pr_info() */ 
#include  /* Needed by all modules */ 
 
int init_module(void) 
{ 
pr_info("Hello world 1.\n"); 
 
/* A non 0 return means init_module failed; module can't be loaded. */ 
return 0; 
} 
 
void cleanup_module(void) 
{ 
pr_info("Goodbye world 1.\n"); 
} 
 
MODULE_LICENSE("GPL");
"
martind@pizzagate:~/tmp/make-kernel-MAKEFLAGS-with-an-s$ 


This is what the problem looks like:


martind@pizzagate:~/tmp/make-kernel-MAKEFLAGS-with-an-s$
~/download/make-4.4/make V=1
/home/martind/download/make-4.4/make -C /lib/modules/4.19.0-21-amd64/build
M=/home/martind/tmp/make-kernel-MAKEFLAGS-with-an-s modules
make[1]: Entering directory '/usr/src/linux-headers-4.19.0-21-amd64'
/home/martind/download/make-4.4/make -C /usr/src/linux-headers-4.19.0-21-amd64
KBUILD_SRC=/usr/src/linux-headers-4.19.0-21-common \
-f /usr/src/linux-headers-4.19.0-21-common/Makefile modules
mkdir -p /home/martind/tmp/make-kernel-MAKEFLAGS-with-an-s/.tmp_versions ; rm
-f /home/martind/tmp/make-kernel-MAKEFLAGS-with-an-s/.tmp_versions/*
/home/martind/download/make-4.4/make -f
/usr/src/linux-headers-4.19.0-21-common/scripts/Makefile.build
obj=/home/martind/tmp/make-kernel-MAKEFLAGS-with-an-s
(cat /dev/null;   echo
kernel//home/martind/tmp/make-kernel-MAKEFLAGS-with-an-s/hello-1.ko;) >
/home/martind/tmp/make-kernel-MAKEFLAGS-with-an-s/modules.order
/home/martind/tmp/make-kernel-MAKEFLAGS-with-an-s/hello-1.c:21:1: warning:
missing terminating " character
 "
 ^
/home/martind/tmp/make-kernel-MAKEFLAGS-with-an-s/hello-1.c:21:1: error:
missing terminating " character
make[4]: ***
[/usr/src/linux-headers-4.19.0-21-common/scripts/Makefile.build:315:
/home/martind/tmp/make-kernel-MAKEFLAGS-with-an-s/hello-1.o] Error 1
make[3]: *** [/usr/src/linux-headers-4.19.0-21-common/Makefile:1561:
_module_/home/martind/tmp/make-kernel-MAKEFLAGS-with-an-s] Error 2
make[2]: *** [Makefile:146: sub-make] Error 2
make[1]: *** [Makefile:8: all] Error 2
make[1]: Leaving directory '/usr/src/linux-headers-4.19.0-21-amd64'
make: *** [Makefile:8: modules] Error 2
martind@pizzagate:~/tmp/make-kernel-MAKEFLAGS-with-an-s$ 


The one new piece of information I want to present with this not-really-a-bug
report is the work around of adding quiet= to the command line, which then
adds the gcc line to the output:


martind@pizzagate:~/tmp/make-kernel-MAKEFLAGS-with-an-s$
~/download/make-4.4/make V=1 quiet=
/home/martind/download/make-4.4/make -C /lib/modules/4.19.0-21-amd64/build
M=/home/martind/tmp/make-kernel-MAKEFLAGS-with-an-s modules
make[1]: Entering directory '/us

[bug #63417] .NOTINTERMEDIATE with no prerequisites is not working

[Paul D. Smith]

Update of bug #63417 (project make):

  Status:None => Fixed  
 Open/Closed:Open => Closed 
   Fixed Release:None => SCM
   Triage Status:None => Medium Effort  

___

Follow-up Comment #3:

Pushed, thanks Dmitry!


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #63417] .NOTINTERMEDIATE with no prerequisites is not working

[Masahiro Yamada]

Follow-up Comment #2, bug #63417 (project make):

Thanks, the patch worked for me.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #63417] .NOTINTERMEDIATE with no prerequisites is not working

[Dmitry Goncharov]

Follow-up Comment #1, bug #63417 (project make):

Thank you for your report.

At makefile parse time make processes .NOTINTERMEDIATE and marks all files as
notintermediate. The issue with this example, is that at that time make does
not yet have a notion of x.b. x.b appears later at build time, when make
performs implicit search to find a rule to build x.a.
We had a test, but the test was broken.
A fix is in the attachment.


(file #54021, file #54022)

___

Additional Item Attachment:

File name: sv63417_fix.diff   Size:4 KB


File name: sv63417_test.diff  Size:1 KB




___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #63417] .NOTINTERMEDIATE with no prerequisites is not working

[Masahiro Yamada]

URL:
  <https://savannah.gnu.org/bugs/?63417>

 Summary: .NOTINTERMEDIATE with no prerequisites is not
working
 Project: make
   Submitter: masahiroy
   Submitted: Fri 25 Nov 2022 09:16:11 PM UTC
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: 4.4
Operating System: None
   Fixed Release: None
   Triage Status: None


___

Follow-up Comments:


---
Date: Fri 25 Nov 2022 09:16:11 PM UTC By: Masahiro Yamada 
The manual says: ".NOTINTERMEDIATE with no prerequisites causes all targets to
be treated as not intermediate."

I tested this on GMU Make 4.4, but it does not work as claimed.


[Test code]
%.a: %.b
cp $< $@

%.b: %.c
cp $< $@

.NOTINTERMEDIATE:


[Result]
$ touch x.c
$ make x.a
cp x.c x.b
cp x.b x.a
rm x.b



x.b was removed (as the effect of the chained rule).


BTW, ".NOTINTERMEDIATE: %.b" correctly suppresses the removal of x.b







___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?63417>

___
Message sent via Savannah
https://savannah.gnu.org/

Re: Dependency tracking not working on macOS

[Paul Eggert]

On 2022-10-16 14:42, Christoph Grüninger wrote:
Any idea what I am missing? I double-checked hat the used make has 
version 4.3.91.


Yes, my idea is that either your bleeding-edge "make" is busted, or your 
environment variables are messed up. Either way it's not an Autoconf bug.


What happens when you run this shell command?

LC_ALL=C truss -fo my.tr ./configure

Look toward the end of my.tr for the system call that's failing, just 
before the "fopen" diagnostics are written. What does the log look like 
in the neighborhood?


If your environment is messed up, the log should make it fairly clear 
what's wrong and how you'll need to change your environment variables. 
If "make" is busted, I again suggest that you rebuild "make" with the 
patch I sent you earlier, here:


https://lists.gnu.org/r/bug-make/2022-10/msg00064.html

(It's possible that you have both problems, and need to fix both.)

Re: Dependency tracking not working on macOS

[Paul Eggert]

On 2022-10-09 15:43, Christoph Grüninger wrote:
TMPDIR is also set, to an uncommon name 
(/var/folders/lr/5gw1xrv53h1b_9mjjvs2k1drgn/T/).


Is that directory searchable, readable, writeable? Does its file system 
have enough free space? Any problems in that area could cause the 
symptoms you're describing.


What happens if you apply the patch proposed here?

https://lists.gnu.org/r/bug-make/2022-10/msg00064.html

Re: Dependency tracking not working on macOS

[Paul Eggert]

On 2022-10-09 15:17, Paul Smith wrote:

On Sun, 2022-10-09 at 16:39 -0400, Zack Weinberg wrote:

can I suggest that this kind of problem would be easier to
troubleshoot if make printed the name of the temporary file that it
could not fopen?

In the current Git version, it does do this:

   ... _("fopen: temporary file %s: %s"), newnm, strerror (errno));


It also does in the latest version of the proposed "Fix some temp file 
issues" patch , 
except that if tmpfile fails the diagnostic simply mentions tmpfile. I 
could change that to mention DEFAULT_TMPDIR instead, if you prefer.


In the proposed patch tmpfile is used only on platforms that lack 
fdopen, or that lack dup, so the point I'm raising here matters only on 
unusual platforms (AmigaOS and VMS perhaps?).

[bug #62162] patsubst not working in prerequisites under .SECONDEXPANSION

[Paul D. Smith]

Update of bug #62162 (project make):

  Status:None => Not A Bug  
 Open/Closed:Open => Closed 


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #62162] patsubst not working in prerequisites under .SECONDEXPANSION

[Mikhail]

Follow-up Comment #5, bug #62162 (project make):

Oh, I got it now, % expands as a stem of static pattern rule, and not being
used by patsubst. 

The issue is resolved. 

Thanks,
Mikhail

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #62162] patsubst not working in prerequisites under .SECONDEXPANSION

[Mikhail]

Follow-up Comment #4, bug #62162 (project make):

Thanks, _$$(percent)_ trick makes the job done. 

However what is happening is still obscure. For example, here _patsubst_ does
everything correctly


lib1_SRCS := main.c try.c test.c
lib2_SRCS := lib.c api.c

.SECONDEXPANSION:
lib1 lib2: $$(patsubst %.c,%.o,$$($$@_SRCS))


and _lib1_  depends on main.o, try.o and test.o.

Reworking it in static pattern rule fashion results in prerequisites main.c,
try.c and test.c for _lib1_, i.e. patsubst does nothing.


lib1_SRCS := main.c try.c test.c
lib2_SRCS := lib.c api.c

.SECONDEXPANSION:
lib1 lib2: lib% : $$(patsubst %.c,%.o,$$(lib$$*_SRCS))


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #62162] patsubst not working in prerequisites under .SECONDEXPANSION

[Dmitry Goncharov]

Follow-up Comment #3, bug #62162 (project make):

A typo, ofcourse should be $$(percent)



percent:=%
$(files) : %.ext : $$(patsubst r$$(percent),$$(percent),$$(lastword $$(subst
.stem., ,$$*)))-prereq


___

Reply to this item at:

  

___
  Сообщение отправлено по Savannah
  https://savannah.gnu.org/

[bug #62162] patsubst not working in prerequisites under .SECONDEXPANSION

[Dmitry Goncharov]

Follow-up Comment #2, bug #62162 (project make):

You can store % in a variable


percent:=%
$(files) : %.ext : $$(patsubst r$(percent),$(percent),$$(lastword $$(subst
.stem., ,$$*)))-prereq


___

Reply to this item at:

  

___
  Сообщение отправлено по Savannah
  https://savannah.gnu.org/

[bug #62162] patsubst not working in prerequisites under .SECONDEXPANSION

[Andreas Schwab]

Follow-up Comment #1, bug #62162 (project make):

The replacement of % by the stem happens before the secondary expansion is
performed.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #62162] patsubst not working in prerequisites under .SECONDEXPANSION

[anonymous]

URL:
  <https://savannah.gnu.org/bugs/?62162>

 Summary: patsubst not working in prerequisites under
.SECONDEXPANSION
 Project: make
Submitted by: None
Submitted on: Thu 10 Mar 2022 10:06:34 AM UTC
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: 4.3
Operating System: POSIX-Based
   Fixed Release: None
   Triage Status: None

___

Details:

For some reason `patsubst` function doesn't do its work in the following
snippet. 

```
prereq_files = 1-prereq 2-prereq
all: prefix.stem.r1.ext

files = $(foreach file,$(prereq_files),prefix.stem.r$(patsubst
%-prereq,%,$(file)).ext)
# Files is prefix.stem.r1.ext prefix.stem.r2.ext
$(files) : %.ext : $$(patsubst r%,%,$$(lastword $$(subst .stem.,
,$$*)))-prereq
cat $< > $@
```

I get `make: *** No rule to make target 'r1-prereq'` error, when trying to
make `prefix.stem.r1.ext` which by design should depend on `1-prereq`.
patsubst doesn't do its job and makes it depend on r1-prereq which is
non-existent. Weirdly if I just use $(subst r,,<...>) everything is fine. 

Any ideas?
-Mikhail



___

File Attachments:


---
Date: Thu 10 Mar 2022 10:06:34 AM UTC  Name: Makefile  Size: 253B   By: None

<http://savannah.gnu.org/bugs/download.php?file_id=52975>

___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?62162>

___
  Message sent via Savannah
  https://savannah.gnu.org/

Re: Paths above current/working directory don't work with suffix rules

[Adam Tuja]

Thanks for an answer. With your help I was able to come up with this piece:
--PROG = ab
LD = $(CC)
SRCS = a.c b.c ../c-1up.c
OBJS = $(SRCS:.c=.o)
.c.o:        $(CC) $(CFLAGS) -c -o $@ $<
.cpp.o:        $(CXX) $(CXXFLAGS) -c -o $@ $<
all: $(PROG)
$(PROG): $(OBJS)
$(LD) -o $@ $(OBJS) $(LIBS)
--Now, when I understand it, it works. It's not the same thing as objects are placed beside source files but step forward nevertheless.I will check VPATH later.
Regards
Adam

Re: Paths above current/working directory don't work with suffix rules

[Paul Smith]

On Mon, 2022-01-24 at 21:27 +0100, Adam Tuja wrote:
> SRCS = a.c b.c ../c-1up.c
> OBJS = $(SRCS:.c=.o)
> 
> .c.o:
> $(CC) $(CFLAGS) -c -o $@ $<
> 
> $(PROG): $(OBJS)
> 
> Now, when I understand it, it works. It's not the same thing as
> objects are placed beside source files but step forward nevertheless.

Did you mean to write something different in your last sentence?  It 
IS the same thing as objects placed beside source files, unless I
misunderstand what you mean by "beside".

This makefile will always write the object files into the same
directory as the source files.  As long as you want to do that, then
you can use suffix rules or pattern rules very easily.

It's when you want object files to go into a different directory from
source files that suffix rules won't work well (you can use VPATH to
help somewhat).

Re: Paths above current/working directory don't work with suffix rules

[Paul Smith]

On Mon, 2022-01-24 at 19:09 +0100, Adam Tuja wrote:
> It doesn't matter how with many levels above current directory the
> path has (../ ../../ ...), it's still the same.

Suffix rules are very limited: this is why pattern rules were invented.

As long as you're happy with creating the object file in the current
directory, AND you're happy with ensuring that no two directories ever
have the same source file name, then it's possible to use suffix rules
to build them.

However you can see from the rule:

  .c.o:

that there's nothing here to tell make where the source file will be,
so clearly that cannot work by itself.  A suffix rule is identical to
the pattern rule:

  %.o : %.c

so, the prefix of the target and prerequisite MUST be identical
strings.  The string "c-1up" is not identical to the string "../c-1up", 
and so this rule cannot match.

You can use VPATH to give make a list of directories to use to search
for source files.  So, in your makefile if you add this:

  VPATH = .. ../..

when make wants to build c-1up.c it will look for ./c-1up.c, then
../c-1up.c, then ../../c-1up.c, and build the first one it finds.

https://www.gnu.org/software/make/manual/html_node/Directory-Search.html

> PS.
> Not to mention that if I don't specify target (all) then it only
> processes one file

Make has to choose SOME target to build by default, if you don't
specify one.  Make always chooses the first target in the makefile by
default.  So, move your "all" target to the top so it's the first
target and it will work as you expect.

https://www.gnu.org/software/make/manual/html_node/Goals.html

Paths above current/working directory don't work with suffix rules

[Adam Tuja]

Hello,I had this problem trying to compile a source with relative paths above current/working directory level. I took me hours of frustration to make work and, it eventually didn't.Then, by a chance I realised that when I use a path within current working directory it more or less works.It doesn't matter how with many levels above current directory the path has (../ ../../ ...), it's still the same.--PROG = abLD = $(CC)OBJS = a.o b.o c-1up.oa.o: a.cb.o: b.cc-1up.o: ../c-1up.c.c.o:        $(CC) $(CFLAGS) -c -o $@ $<.cpp.o:        $(CXX) $(CXXFLAGS) -c -o $@ $<$(PROG): $(OBJS)        $(LD) -o $@ $(OBJS) $(LIBS)all: $(PROG)--```$ make -f makefile-ab3x-suffix-rules.mk allcc  -c -o a.o a.ccc  -c -o b.o b.ccc -o ab a.o b.o c-1up.o cc: error: c-1up.o: No such file or directorymake: *** [ab] Error 1```And then I found that it only fails when I use suffix rules. When every file has its own rule it works.--PROG = abLD = $(CC)OBJS = a.o b.o c-1up.oa.o: a.c        $(CC) $(CFLAGS) -c -o $@ $<b.o: b.c        $(CC) $(CFLAGS) -c -o $@ $<c-1up.o: ../c-1up.c        $(CC) $(CFLAGS) -c -o $@ $<$(PROG): $(OBJS)        $(LD) -o $@ $(OBJS) $(LIBS)all: $(PROG)--```$ make -f makefile-ab3y-dependencies-for-every1.mk allcc  -c -o a.o a.ccc  -c -o b.o b.ccc  -c -o c-1up.o ../c-1up.ccc -o ab a.o b.o c-1up.o ```I don't know if it's a feature or a bug, or a bug in my makefile but it seems to work somewhat strange.Above Test files are attached.PS.Not to mention that if I don't specify target (all) then it only processes one file```$ make -f makefile-ab3x-suffix-rules.mkcc  -c -o a.o a.c$ make -f makefile-ab3y-dependencies-for-every1.mk cc  -c -o a.o a.c```That's minor I guess.Kind regardsAdam

65544
Description: GNU Zip compressed data

[bug #60919] Communicating -j to sub-make not working properly after make 4.1

[Paul D. Smith]

Update of bug #60919 (project make):

  Status:None => Not A Bug  
 Open/Closed:Open => Closed 

___

Follow-up Comment #1:

Your parent makefile is incorrect.  By adding an explicit -j option to the
submake command line you are forcing the sub-make to run in a mode with no
restrictions on the amount of parallelism; see the documentation:

> If there is nothing looking like an integer after the ‘-j’ option, there
is no limit on the number of job slots.

If you want to have your sub-makes participate in the jobserver and obey the
limits provided by the make command line, you should remove the -j option from
the submake command line.  In other words, change:


test1:
sleep .1; echo start test1; sleep .1; cd child; $(MAKE) -j ;  echo end 
test1


to this:


test1:
sleep .1; echo start test1; sleep .1; cd child; $(MAKE) ;  echo end 
test1


And the same for all other sub-make invocations obviously.

In general you never want to add specific options to the command line of
sub-makes unless you're trying to modify or override the operations that the
user specified when they invoked the top-level make (which should be extremely
rare).

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #60919] Communicating -j to sub-make not working properly after make 4.1

[Bahaa Hamza]

Additional Item Attachment, bug #60919 (project make):

File name: testcase.tar.gzSize:0 KB




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #60919] Communicating -j to sub-make not working properly after make 4.1

[Bahaa Hamza]

URL:
  <https://savannah.gnu.org/bugs/?60919>

 Summary: Communicating -j to sub-make not working properly
after make 4.1
 Project: make
Submitted by: bahaahamza
Submitted on: Thu 15 Jul 2021 07:56:37 AM UTC
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: 4.1
Operating System: None
   Fixed Release: None
   Triage Status: None

___

Details:


Referring to make manual, in "Communicating Options to a Sub-make". The
following was mentioned:
"The ‘-j’ option is a special case (see Parallel Execution). If you set it
to some numeric value ‘N’ and your operating system supports it (most any
UNIX system will; others typically won’t), the parent make and all the
sub-makes will communicate to ensure that there are only ‘N’ jobs running
at the same time between them all."

Prior to make version 4.1 (4.0 and earlier), this was working fine. If parent
make was run with -jN, eventually make and sub-make will be running only N
jobs.

But since make 4.1 (till 4.3), it's not working as before.
sub-make will spawn several jobs and the total count is more than N.

I tried to check in Changelog if this was an intended change in behavior, but
i didn't find this change. 

** Testcase:
I've attached a testcase to this bug. 
For example, you can run "make -j 2" using make 3.8 and make 4.2. 
For v3.8, you will notice that only 2 jobs will be running at a time
(subtests).
While for v4.2, all chile subtests will be spawned (2 * 8).





___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?60919>

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #57625] Shell builtins not working unless explicitly set SHELL to "sh"

[Paul D. Smith]

Update of bug #57625 (project make):

  Status:None => Fixed  
 Assigned to:None => psmith 
 Open/Closed:Open => Closed 
   Fixed Release:None => SCM
   Triage Status:None => Small Effort   

___

Follow-up Comment #1:

There are a confluence of factors involved here.

First, make tries to avoid invoking a shell as a performance improvement.  If
make determines that the command to be invoked is a simple command it uses a
"fast path" where it simply forks and execs the command directly and doesn't
use a shell to do it.

GNU make contains a list of special commands which are known to be shell
built-ins, etc.; if the command starts with those make knows it needs to
invoke a shell _even if_ the command appears to be simple enough to invoke
directly.

Unfortunately, "type" is missing from that list; I have fixed that, along with
adding a few other missing items, and the fix will be in the next release.

As for setting SHELL; the documentation actually doesn't say the default value
of SHELL is "sh", it says the default value is "/bin/sh".  If you used "SHELL
= /bin/sh" instead of "SHELL = sh" then you wouldn't see the odd behavior (it
would work the same as if you hadn't set SHELL).  The change you observe is
because make also tries to detect whether the SHELL you set is a POSIX shell
or not.  If make isn't sure, it will never choose the fast path and always
invoke the shell.  Make is very conservative about this and only checks a few
well-known paths to decide whether the shell is POSIX or not; "sh" doesn't
meet that criteria so by setting "SHELL = sh" you've disabled fast-path for
all your recipes.

As a workaround for your current environment you can easily convince make to
always invoke a shell for your command simply by using a special character. 
One simple one is ";"; if make sees a semicolon in the command it will always
skip the fast path and invoke a shell:


.POSIX:
run:
type make;


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #57625] Shell builtins not working unless explicitly set SHELL to "sh"

[anonymous]

URL:
  <https://savannah.gnu.org/bugs/?57625>

 Summary: Shell builtins not working unless explicitly set
SHELL to "sh"
 Project: make
Submitted by: None
Submitted on: Sat 18 Jan 2020 12:48:39 PM UTC
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: 4.2.1
Operating System: POSIX-Based
   Fixed Release: None
   Triage Status: None

___

Details:

Example contents of makefile:


.POSIX:
#SHELL = sh
.PHONY: run
run:
type make


The target fails because "make: type: Command not found".
If you uncomment the line, it works just fine and outputs "/usr/bin/make". The
documentation
(https://www.gnu.org/software/make/manual/html_node/Choosing-the-Shell.html#Choosing-the-Shell)
says that the default shell is "sh", so I'm not sure why setting SHELL to "sh"
should affect the execution of commands.




___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?57625>

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #51309] Determination of a file list from a single folder without changing the working directory

[Markus Elfring]

Follow-up Comment #10, bug #51309 (project make):

Would you like to compare run time characteristics a bit more with an approach
similar to “$(shell find ~/Projekte/Bau/OCamlbuild -name '*.txt' -printf "%f
")”?

___

Reply to this item at:

  

___
  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

Re: [bug #51309] Determination of a file list from a single folder without changing the working directory

[SF Markus Elfring]

> Are you able to provide any example proving how it matters under some more
> or less rare circumstances?

I guess not at the moment.


> Or do you find the current software good enough

I dared to point some change possibilities out recently.


> and no changes needed?

It depends on your views for software developments which your prefer.

I imagine that algorithm comparisons can lead to related improvements,
can't they?

Regards,
Markus

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: [bug #51309] Determination of a file list from a single folder without changing the working directory

[Henrik Carlqvist]

On Sun,  2 Jul 2017 16:14:31 -0400 (EDT)
Markus Elfring  wrote:
> It might matter more under other circumstances.

Are you able to provide any example proving how it matters under some more
or less rare circumstances?

> (The current software can be fast enough to some degree.)

Or do you find the current software good enough and no changes needed?

regards Henrik

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

[bug #51309] Determination of a file list from a single folder without changing the working directory

[Markus Elfring]

Follow-up Comment #9, bug #51309 (project make):

I suggested also a comparison of two algorithms
.

* A simple time measurement can also show test results for which you might not
be looking for.
* The usage of data structures like list and trees has got also different run
time characteristics. Each of them can have a corresponding application
domain.
* Which test environments would you find representative?


> From this I conclude that the performance impact of an additional notdir
function is negligible and there's no performance advantage to avoiding it.

It might matter more under other circumstances. (The current software can be
fast enough to some degree.)

___

Reply to this item at:

  

___
  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 #51309] Determination of a file list from a single folder without changing the working directory

[Paul D. Smith]

Follow-up Comment #8, bug #51309 (project make):

If, for example, you can show an example of notdir adding significantly to the
amount of time the make program takes.

To test this I created a makefile like this:


foo = ...

all: ; : $(words $(foo))


where the "..." represents 6000 paths hardcoded into the makefile.  I then ran
"time make":


$ time make
: 6000

real0m0.004s
user0m0.000s
sys 0m0.000s


Then I modified the makefile to add a notdir like this:


foo = $(notdir ...)

all: ; : $(words $(foo))


where the "..." is the same as last time.  I got this result:


$ time make
: 6000

real0m0.004s
user0m0.000s
sys 0m0.000s


Same time.  This means that the amount of time needed to run notdir on 6000
paths is less than 1/1000th of a second.  From this I conclude that the
performance impact of an additional notdir function is negligible and there's
no performance advantage to avoiding it.

___

Reply to this item at:

  

___
  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 #51309] Determination of a file list from a single folder without changing the working directory

[Markus Elfring]

Follow-up Comment #7, bug #51309 (project make):

> (a) you prefer to do it this way rather than the currently supported method
of post-processing the wildcard results, …

Yes.


>(b) there's a significant performance benefit to avoiding the extra
processing.

I find that the difference can be eventually measured.

We have got different opinions about the circumstances when it would be
significant enough.


> … adding new features in a backward- and POSIX-compatible way is difficult
due …

How many software developers would dare to extend corresponding programming
interfaces so that they can be better reused by the make function library?

I am curious if this story could ever turn into a more promising “maybe”
thing.

___

Reply to this item at:

  

___
  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 #51309] Determination of a file list from a single folder without changing the working directory

[Martin Dorey]

Follow-up Comment #6, bug #51309 (project make):

A theoretical argument is not what Paul meant by "actual results".  Have you
measured the time spent adding and removing the directory names in some
realistic case?  If not, then please do not advocate for making Make bigger..

___

Reply to this item at:

  

___
  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 #51309] Determination of a file list from a single folder without changing the working directory

[Paul D. Smith]

Follow-up Comment #5, bug #51309 (project make):

I understand what you are suggesting.

But I don't see any need to add new capabilities for this when the existing
features of GNU make can already give these results.

The only reasons for it that I can see would be (a) you prefer to do it this
way rather than the currently supported method of post-processing the wildcard
results, or (b) there's a significant performance benefit to avoiding the
extra processing.  For (a), I'm not inclined to create new capabilities just
for this reason.  For (b), I seriously doubt that there will be any measurable
performance difference in a real makefile.

If you can show an example where there _is_ a significant performance
difference then we can discuss that.

To be clear, my attitudes on makefile syntax are that (1) it's already complex
and there are already a lot of features, complexities, and "gotchas", (2)
adding new features in a backward- and POSIX-compatible way is difficult due
to the relatively free-form syntax of makefiles, and (3) features combine in
ways that are multiplicative, not additive, which greatly increases the
potential for incorrect interactions, bugs, and the testing needed to support
them.

Thus, my initial answer to adding new capabilities is almost always going to
be "no".  It requires a clear improvement in power (not just syntactic sugar)
and a reasonable syntax that makes sense and doesn't break lots of existing
makefiles to clear that hurdle and get to "maybe" or "yes".

___

Reply to this item at:

  

___
  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 #51309] Determination of a file list from a single folder without changing the working directory

[Markus Elfring]

Follow-up Comment #4, bug #51309 (project make):

I repeat my argument from 26. June:
https://lists.gnu.org/archive/html/bug-make/2017-06/msg00198.html

If the desired directory on which a file filter should be applied could be
selected before, the file names would not contain references to this directory
and another function call is therefore unnecessary to remove it from the
returned list elements.

___

Reply to this item at:

  

___
  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 #51309] Determination of a file list from a single folder without changing the working directory

[Paul D. Smith]

Follow-up Comment #3, bug #51309 (project make):

There's no question that


FOO := $(notdir $(wildcard Bau/*.txt))


is more efficient than:


~/Projekte> $(cd Bau && echo "echo $(ls *txt)")


because the latter involves starting a whole new shell (two, technically)
while the former is handled entirely within the make process with no fork/exec
operation required.

If you can show actual results where adding the notdir makes a significant
performance difference in a makefile environment we can reconsider, but I'm
not interested in adding new features duplicating existing capabilities
without proof that there's a real need.

___

Reply to this item at:

  

___
  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 #51309] Determination of a file list from a single folder without changing the working directory

[Markus Elfring]

Follow-up Comment #2, bug #51309 (project make):

I disagree with the run time characteristics of the mentioned functionality
for my special use case.


~/Projekte> $(cd Bau && echo "echo $(ls *txt)")
MOTD.txt



Can a similar data processing operation be performed faster by advanced make
functions?

___

Reply to this item at:

  

___
  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 #51309] Determination of a file list from a single folder without changing the working directory

[Paul D. Smith]

Update of bug #51309 (project make):

  Status:None => Wont Fix   
 Open/Closed:Open => Closed 

___

Follow-up Comment #1:

The current capabilities (using notdir to remove the entire directory, or
using patsubst etc. to remove partial directories) is sufficient.  Nothing new
is needed here.

___

Reply to this item at:

  

___
  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

Re: [bug #51309] Determination of a file list from a single folder without changing the working directory

[SF Markus Elfring]

> MY_FILES=$(notdir $(wildcard somedir/*.ext))

I agree that this algorithm can work. But it does not fit to my imaginations
for efficient data processing.

If the desired directory on which a file filter should be applied
could be selected before, the file names would not contain references
to this directory and another function call is therefore unnecessary
to remove it from the returned list elements.

The difference can eventually better seen by an approach like the following.

~/Projekte> ls Bau/*txt
Bau/MOTD.txt
~/Projekte> cd Bau && ls *txt
MOTD.txt


I would like to achieve the second list result without using
the command “cd” before.

Regards,
Markus

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

[bug #51309] Determination of a file list from a single folder without changing the working directory

[Markus Elfring]

URL:
  <http://savannah.gnu.org/bugs/?51309>

 Summary: Determination of a file list from a single folder
without changing the working directory
 Project: make
Submitted by: elfring
Submitted on: Sun 25 Jun 2017 07:53:27 PM CEST
Severity: 3 - Normal
  Item Group: Enhancement
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: 4.2.1
Operating System: Any
   Fixed Release: None
   Triage Status: None

___

Details:

The function “wildcard”
<https://www.gnu.org/software/make/manual/html_node/File-Name-Functions.html#index-wildcard-2>
is supported by the make software.
Corresponding file patterns work also in combination with directory names.
Such combinations are occasionally useful. The query result will contain them
as usual.

I came along the need to query a single folder without changing the working
directory
<https://github.com/elfring/Coccinelle-20160205/blob/replace_suffix_rules_by_pattern_rules1/modules_without_mli.make#L7>
so that only file names (without folder names) will be in the result.
Can another software extension become useful for the function library to make
such data processing more efficient?




___

Reply to this item at:

  <http://savannah.gnu.org/bugs/?51309>

___
  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

Re: ifeq and ifneq not working

[Martin Dorey]

TESTSRC depends on $@, an automatic variable set at the time of recipe 
execution.  ifneq by contrast runs earlier.  
https://www.gnu.org/software/make/manual/html_node/Conditionals.html#Conditionals
 explains "Conditionals control what make actually “sees” in the makefile, so 
they cannot be used to control recipes at the time of execution".

On Apr 23, 2016, at 09:12, Sedrubal 
<sedru...@sedrubal.de<mailto:sedru...@sedrubal.de>> wrote:

Hi,

I'm not sure but I think I found a bug in ifeq and ifneq:

My project structure is like this:

$ tree
.
├── Makefile
├── subprojA
│   ├── src.cpp
│   ├── Makefile
│   └── test.cpp
└── subprojA
   ├── src.cpp
   ├── Makefile
   └── test.cpp

The upper Makefile should run `make test` for each sub project if "test.cpp" is
in this folder.

My Makefile is like this:

SUBDIRS:= $(wildcard */)
TESTDIRS:= $(SUBDIRS:%=test-%)

.PHONY: test $(SUBDIRS) $(TESTDIRS)

all: $(SUBDIRS)

test: $(TESTDIRS)

$(SUBDIRS):
   CC=$(CC) CFLAGS='$(CFLAGS)' LDFLAGS='$(LDFLAGS)' $(MAKE) all -C $@

$(TESTDIRS):
   $(eval TARGETDIR := $(@:test-%=%))
   $(eval TESTSRC := $(TARGETDIR)test.cpp)
   @echo "$(wildcard $(TESTSRC))" # <-- prints subproj{A,B}/test.cpp if it
exists -> this is working
ifneq ("$(wildcard $(TESTSRC))","")
   @#file exists --> but even if the test src exists, this will never be
reached
   CC=$(CC) CFLAGS='$(CFLAGS)' LDFLAGS='$(LDFLAGS)' $(MAKE) test -C
$(TARGETDIR)
else
   @echo "[i] $(TARGETDIR) has no tests..."
endif

Can you explain, why this shouldn't work? Is this a bug or only a fail in
Makefile logic?

Best regards and grml,

Sedrubal
___
Bug-make mailing list
Bug-make@gnu.org<mailto: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

ifeq and ifneq not working

[Sedrubal]

Hi,

I'm not sure but I think I found a bug in ifeq and ifneq:

My project structure is like this:

$ tree
.
├── Makefile
├── subprojA
│   ├── src.cpp
│   ├── Makefile
│   └── test.cpp
└── subprojA
├── src.cpp
├── Makefile
└── test.cpp

The upper Makefile should run `make test` for each sub project if "test.cpp" is 
in this folder.

My Makefile is like this:

SUBDIRS := $(wildcard */)
TESTDIRS:= $(SUBDIRS:%=test-%)

.PHONY: test $(SUBDIRS) $(TESTDIRS)

all: $(SUBDIRS)

test: $(TESTDIRS)

$(SUBDIRS):
CC=$(CC) CFLAGS='$(CFLAGS)' LDFLAGS='$(LDFLAGS)' $(MAKE) all -C $@

$(TESTDIRS):
$(eval TARGETDIR := $(@:test-%=%))
$(eval TESTSRC := $(TARGETDIR)test.cpp)
@echo "$(wildcard $(TESTSRC))" # <-- prints subproj{A,B}/test.cpp if it 
exists -> this is working
ifneq ("$(wildcard $(TESTSRC))","")
@#file exists --> but even if the test src exists, this will never be 
reached
CC=$(CC) CFLAGS='$(CFLAGS)' LDFLAGS='$(LDFLAGS)' $(MAKE) test -C 
$(TARGETDIR)
else
@echo "[i] $(TARGETDIR) has no tests..."
endif

Can you explain, why this shouldn't work? Is this a bug or only a fail in 
Makefile logic?

Best regards and grml,

Sedrubal

signature.asc
Description: This is a digitally signed message part.
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: Make recursion does not appear working in VMS

[John E. Malmberg]

On 3/13/2014 8:14 AM, h.becker wrote:


It looks like execve uses argv[0] to run make.

With a VMS/DCL-style version of the Makefile and my mcr version of make
it seems to work:


I changed from the wrapper code to code that sets the makefile name, and 
temporarily set a local symbol as a foreign command.  At exit the symbol 
is either deleted or replaced with the original value, which leaves 
argv[0] alone.


I also found that the vms_exit() code had a bug in it, because it was 
written with the expectation of getting a UNIX exit status, and GNU make 
is passing it VMS exit statuses.


As only codes 0, 1, 2 are defined for GNU make status, and the lowest 
failure status from VMS is 8, for GNU make, the conversion to VMS status 
should only be done for codes 1-7, the rest should be passed through.


With that those two changes, I now have:

EAGLE del lcl_root:[...]*.*;*/exc=(*.dir,*.pm)
EAGLE perl run_make_tests.pl features/parallelism
--
  Running tests for GNU make on VMS
   GNU Make 4.0.90
--

Clearing /lcl_root/make/tests/work...
Making work dirs...

features/parallelism  Error running 
make (expected 0; got 512): make -f 
/lcl_root/make/tests/work/features/parallelism.mk_1 -j4
Error running make (expected 512; got 0): make -f 
/lcl_root/make/tests/work/features/parallelism.mk_3 -rR -j5

FAILED (6/8 passed)

2 Tests in 1 Category Failed (See .diff* files in work dir for details) :-(


The first failure is that the recursion is not happening:

The 1.inc and 2.inc recipe lines are probably wrapped in the e-mail client.

LCL_ROOT:[make.tests.work.features]parallelism.log_1;1

THREE.inc
ONE.inc
TWO.inc
make: *** No rule to make target '1', needed by 'all'.  Stop.

LCL_ROOT:[make.tests.work.features]parallelism.mk_1;1


all : 1 2 ; @echo success
-include 1.inc 2.inc
1.inc : ; @pipe echo ONE.inc ; sleep 3 ; echo TWO.inc ; define/user 
sys$$output $@ ; echo 1 : ; @pipe echo ONE ; sleep 2 ; echo TWO ; 
close sys$$output
2.inc : ; @pipe sleep 2 ; echo THREE.inc ; define/user sys$$output $@ ; 
echo 2: ; @pipe sleep 1 ; echo THREE ; close sys$$output


LCL_ROOT:[make.tests.work.features]parallelism.run_1;1

make -f /lcl_root/make/tests/work/features/parallelism.mk_1 -j4


The second failure is that the make prematurely exits on the first fail.
It should have 3 failures.  The test script currently converts the
0x1035a00a to 1 so that it matches.  That should probably be done by 
Make.


There should be 3 failure lines, not just one.

EAGLE type LCL_ROOT:[make.tests.work.features]parallelism.*_3

LCL_ROOT:[make.tests.work.features]parallelism.log_3;1

Fail
/lcl_root/make/tests/work/features/parallelism.mk_3:6: recipe for target 
'fail.1

' failed
make: *** [fail.1] Error 0x1035a00a

LCL_ROOT:[make.tests.work.features]parallelism.mk_3;1


.PHONY: all fail.1 fail.2 fail.3 ok
all: fail.1 ok fail.2 fail.3

fail.1 fail.2 fail.3:
@sleep $(patsubst fail.%,%,$@)
@echo Fail
@exit 271949834;

ok:
@sleep 4
@echo Ok done

LCL_ROOT:[make.tests.work.features]parallelism.run_3;1

make -f /lcl_root/make/tests/work/features/parallelism.mk_3 -rR -j5

Regards,
-John



___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: Make recursion does not appear working in VMS

[John E. Malmberg]

On 3/16/2014 6:14 PM, John E. Malmberg wrote:

On 3/13/2014 8:14 AM, h.becker wrote:


It looks like execve uses argv[0] to run make.

With a VMS/DCL-style version of the Makefile and my mcr version of make
it seems to work:


I changed from the wrapper code to code that sets the makefile name, and
temporarily set a local symbol as a foreign command.  At exit the symbol
is either deleted or replaced with the original value, which leaves
argv[0] alone.

I also found that the vms_exit() code had a bug in it, because it was
written with the expectation of getting a UNIX exit status, and GNU make
is passing it VMS exit statuses.

As only codes 0, 1, 2 are defined for GNU make status, and the lowest
failure status from VMS is 8, for GNU make, the conversion to VMS status
should only be done for codes 1-7, the rest should be passed through.

With that those two changes, I now have:

EAGLE del lcl_root:[...]*.*;*/exc=(*.dir,*.pm)
EAGLE perl run_make_tests.pl features/parallelism
--

   Running tests for GNU make on VMS
GNU Make 4.0.90
--


Clearing /lcl_root/make/tests/work...
Making work dirs...

features/parallelism  Error running
make (expected 0; got 512): make -f
/lcl_root/make/tests/work/features/parallelism.mk_1 -j4
Error running make (expected 512; got 0): make -f
/lcl_root/make/tests/work/features/parallelism.mk_3 -rR -j5
FAILED (6/8 passed)

2 Tests in 1 Category Failed (See .diff* files in work dir for details) :-(


The first failure is that the recursion is not happening:

The 1.inc and 2.inc recipe lines are probably wrapped in the e-mail client.

LCL_ROOT:[make.tests.work.features]parallelism.log_1;1

THREE.inc
ONE.inc
TWO.inc
make: *** No rule to make target '1', needed by 'all'.  Stop.

LCL_ROOT:[make.tests.work.features]parallelism.mk_1;1


all : 1 2 ; @echo success
-include 1.inc 2.inc
1.inc : ; @pipe echo ONE.inc ; sleep 3 ; echo TWO.inc ; define/user
sys$$output $@ ; echo 1 : ; @pipe echo ONE ; sleep 2 ; echo TWO ;
close sys$$output
2.inc : ; @pipe sleep 2 ; echo THREE.inc ; define/user sys$$output $@ ;
echo 2: ; @pipe sleep 1 ; echo THREE ; close sys$$output

LCL_ROOT:[make.tests.work.features]parallelism.run_1;1

make -f /lcl_root/make/tests/work/features/parallelism.mk_1 -j4


The second failure is that the make prematurely exits on the first fail.
It should have 3 failures.  The test script currently converts the
0x1035a00a to 1 so that it matches.  That should probably be done by
Make.

There should be 3 failure lines, not just one.


Found another bug in the exit_failure routine, and now second test is 
passing.  So only the parallelism_mk_1 test is failing out of the set.


Regards,
-John



___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: Make recursion does not appear working in VMS

[h.becker]

On 03/13/2014 05:29 AM, John E. Malmberg wrote:
 Further tests show that the parallelism is not fully working on VMS, or
 not working as a Unix program would expect.

As far as I know, --jobs is not implemented for VMS, unfortunately I
can't point to an obvious line in the sources. It seems to be hidden in
#if[n]def VMS in job.c and vmsjobs.c. Silently explicitly or implicitly
reseting jobs to 1 isn't good.

To look at this, can you post or send (one of) the modified makefiles
for VMS?

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: Make recursion does not appear working in VMS

[John E. Malmberg]

On 3/13/2014 4:19 AM, h.becker wrote:

On 03/13/2014 05:29 AM, John E. Malmberg wrote:

Further tests show that the parallelism is not fully working on VMS, or
not working as a Unix program would expect.


As far as I know, --jobs is not implemented for VMS, unfortunately I
can't point to an obvious line in the sources. It seems to be hidden in
#if[n]def VMS in job.c and vmsjobs.c. Silently explicitly or implicitly
reseting jobs to 1 isn't good.

To look at this, can you post or send (one of) the modified makefiles
for VMS?



Sorry for long lines, only a seconds before I have to run.

recurse line is wrapped in the e-mail client.
1.inc and 2.inc lines are wrapped in the e-mail client.

This is one of the files that fails for recursion.  I will have to send 
one that shows the parallelism failures later.



EAGLE del 1.inc;,2.inc;
EAGLE
EAGLE
EAGLE make -f /lcl_root/make/tests/work/features/parallelism.mk_2 -j4
THREE.inc
ONE.inc
TWO.inc
make: execve: make: no such file or directory
/lcl_root/make/tests/work/features/parallelism.mk_2:2: recipe for target 
'recurse' failed

make: *** [recurse] Error 0xbf2bffbc

Or if you prefer:

EAGLE del 1.inc;,2.inc;
EAGLE make -f [.work.features]parallelism.mk_2 -j4
THREE.inc
ONE.inc
TWO.inc
make: execve: make: no such file or directory
[.work.features]parallelism.mk_2:2: recipe for target 'recurse' failed
make: *** [recurse] Error 0xbf2bffbc


Directory LCL_ROOT:[make.tests.work.features]

parallelism.log_2;1 parallelism.mk_2;1

Total of 2 files.
EAGLE type LCL_ROOT:[make.tests.work.features]parallelism.mk_2

recurse : ; @$(MAKE) --no-print-directory -f 
/lcl_root/make/tests/work/features/

parallelism.mk_2 INC=yes all
all : 1 2 ; @echo success

INC = no
ifeq ($(INC),yes)
-include 1.inc 2.inc
endif
1.inc : ; @pipe echo ONE.inc ; sleep 2 ; echo TWO.inc ; define/user 
sys$$output $@ ; echo 1 : ; @pipe echo ONE ; sleep 2 ; echo TWO ; 
close sys$$output
2.inc : ; @pipe sleep 1 ; echo THREE.inc ; define/user sys$$output $@ ; 
echo 2: ; @pipe sleep 1 ; echo THREE ; close sys$$output



Regards,
-John


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: Make recursion does not appear working in VMS

[h.becker]

On 03/13/2014 01:17 PM, John E. Malmberg wrote:
 EAGLE del 1.inc;,2.inc;
 EAGLE
 EAGLE
 EAGLE make -f /lcl_root/make/tests/work/features/parallelism.mk_2 -j4
 THREE.inc
 ONE.inc
 TWO.inc
 make: execve: make: no such file or directory
 /lcl_root/make/tests/work/features/parallelism.mk_2:2: recipe for target
 'recurse' failed
 make: *** [recurse] Error 0xbf2bffbc
 
 Or if you prefer:
 
 EAGLE del 1.inc;,2.inc;
 EAGLE make -f [.work.features]parallelism.mk_2 -j4
 THREE.inc
 ONE.inc
 TWO.inc
 make: execve: make: no such file or directory
 [.work.features]parallelism.mk_2:2: recipe for target 'recurse' failed
 make: *** [recurse] Error 0xbf2bffbc

It looks like execve uses argv[0] to run make.

With a VMS/DCL-style version of the Makefile and my mcr version of make
it seems to work:

$ del %.inc;*
$ mc [.make]mcr -f parallelism.mk_2 -j4
THREE.inc
ONE.inc
TWO.inc
ONE
TWO
THREE
success
$
$ del %.inc;*
$ mc [.make]mcr -nf parallelism.mk_2 -j4
mcr eisner$lda2:[usr_ods5.][becker_h.make.make]mcr.exe;1
--no-print-directory -f parallelism.mk_2 INC=yes all
THREE.inc
ONE.inc
TWO.inc
ONE
TWO
THREE
success
$

$ type parallelism.mk_2
recurse : ; @$(MAKE) --no-print-directory -f parallelism.mk_2 INC=yes all
all : 1 2 ; @write sys$$output success 

INC = no
ifeq ($(INC),yes)
-include 1.inc 2.inc
endif

1.inc : ; @pipe write sys$$output ONE.inc ; wait 0:0:2 ; write
sys$$output TWO.inc ; define sys$$output $@ ; write sys$$output 1 : ;
@pipe write sysoutput ONE ; wait 0:0:2 ; write sysoutput
TWO ; close sys$$output
2.inc : ; @pipe wait 0:0:1 ; write sys$$output THREE.inc ; define
sys$$output $@ ; write sys$$output 2: ; @pipe wait 0:0:1 ; write
sysoutput THREE ; close sys$$output

$


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: Make recursion does not appear working in VMS

[John E. Malmberg]

On 3/12/2014 7:10 AM, John E. Malmberg wrote:

I converted the features parallelism.mk_1 test to VMS and if I run it
with out the two generated 1.inc and 2.inc files, it always fails to
find the rules specified by them.

It does generate the files correctly and the output up to that point.

As near as I can figure out, it means that make is not doing its
recursion to re-run the makefile on VMS.


Further tests show that the parallelism is not fully working on VMS, or 
not working as a Unix program would expect.


Of the 9 parallelism tests, 4 work, 4 fail, and one is not current valid 
to run on VMS.


Regards,
-John



___
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.

[h.becker]

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.

[John E. Malmberg]

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: Test harness on VMS working, 58 tests currently failing.

[John E. Malmberg]

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.

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.

This limits running the test harness on Alpha/VMS 8.3 and 8.4 and IA64
VMS 8.4.

58 Tests in 103 Categories Failed (See .diff* files in work dir for
details) :-(

As there appears to be 111 log files, this is just less than half the
tests passing.


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?


Regards,
-John


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Test harness on VMS working, 58 tests currently failing.

[John E. Malmberg]

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.

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 it 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.

This limits running the test harness on Alpha/VMS 8.3 and 8.4 and IA64 
VMS 8.4.


58 Tests in 103 Categories Failed (See .diff* files in work dir for 
details) :-(


As there appears to be 111 log files, this is just less than half the 
tests passing.


I still need to investigate all of these failures.

The features/archives test fails because the GNV AR utility requires 
real VMS object files at this time, and the test just creates some 
files.  I will need to adjust the test setup section for VMS.


Some of the other tests are failing because the VMS sets argv[0] 
differently than what is expected.  I have a fix from the Bash 4.2.45 
port that will handle that.


3 tests timed out after 5 seconds.


Here is an example of a passing test.
EAGLE perl run_make_tests.pl features/comments
--
  Running tests for GNU make on VMS
   GNU Make 4.0.90
--

Clearing /lcl_root/make/tests/work...
Making work dirs...

features/comments ... ok (1 passed)

1 Test in 1 Category Complete ... No Failures :-)

Regards,
-John


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: .ONESEHLL not working as expected in 3.82

[Eli Zaretskii]

 From: Paul Smith psm...@gnu.org
 Cc: bug-make@gnu.org
 Date: Sun, 28 Apr 2013 15:15:09 -0400
 
 I think it pseudo-code it would look something like this:
 
   if (posix-shell)
 {
   ...strip out @-+ from LINE...
 }
 #ifdef WINDOWS32
   if (need a batch file)
 {
   ...write LINE to the batch file  setup new_argv for batch...
 }
   else
 #endif
 {
   ...chop LINE up into new_argv...
 }
   return new_argv;

I fixed it a bit differently, please see commit 9a7fe22.

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: .ONESEHLL not working as expected in 3.82

[Eli Zaretskii]

 From: Paul Smith psm...@gnu.org
 Cc: bug-make@gnu.org
 Date: Sun, 28 Apr 2013 14:37:29 -0400
 
  My plan was to write dlopen and dlsym, and add them to
  w32/compat/posixfcn.c.  But I need to understand the semantics of
  global_dl in order to do that correctly.
 
 It's up to you how you think it best to implement, whether it makes more
 sense to try to reimplement POSIX functions, or do it at a higher level.
 Whatever is simpler.

OK, done as commit 19a69ba.

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: Dynamic objects (was: .ONESEHLL not working as expected in 3.82)

[Eli Zaretskii]

 From: Paul Smith psm...@gnu.org
 Cc: bug-make@gnu.org
 Date: Sat, 27 Apr 2013 16:58:54 -0400
 
 On Sat, 2013-04-27 at 23:00 +0300, Eli Zaretskii wrote:
  That would be nice, indeed.
 
 OK, pushed.  You should be able to simply write a new load_objects()
 function and drop it in.  Or put it into a w32 file or whatever.

Thanks, I did that.

As result of reading the docs and the code, I have a few comments on
this feature, hopefully it will be useful:

1. Doesn't the FSF frown upon capability to load _any_ dynamic
   objects?  I think they like the GCC method whereby each extension
   is required to define a symbol with a certain name
   (plugin_is_GPL_compatible in GCC), which is tested at load time,
   before the dynamic object is allowed to be loaded.

2. The fact that the dynamic object's file extension (.so) is exposed
   to the Makefile is unfortunate, because it will hurt portability of
   Makefiles: the extension on Windows is .dll.  Can we omit the
   extension and append it internally?

3. I suggest to extend the search for dynamic object to a
   Make-specific directory (${prefix}/share/make/), before falling
   back to the system-specific path.  Or maybe even not fall back to
   any system-specific defaults, because those are generally set for
   shared libraries, not for plugins.  (You do NOT want to know where
   Windows will look for shared libraries.)

4. It would be good to have at least a single simple example of a
   dynamic extension, either in the tarball or in the manual.  The
   only ones I found are in the test suite; did I miss something?

5. Is the following a valid 'load' directive?

 load /foo/bar/

   If it is valid, what is its semantics?  If it is invalid, the code
   in load_object should detect it and give a diagnostics; currently
   it will happily use this, and will try to call a symbol _gmk_setup.

6. The diagnostics in read.c:

  if (! load_file (ebuf-floc, name, noerror)  ! noerror)
fatal (ebuf-floc, _(%s: failed to load), name);

   is IMO misleading: it says failed to load also in the case that
   the dynamic object was successfully loaded, but the function called
   from it returned zero.  It would be better to make a more precise
   message in that case.

6. API:

   . I suggest to request that the buffers for expansions and
 evaluation by gmk_expand and gmk_eval be provided by the caller.
 It is not safe (and not very convenient) to return buffers
 allocated internally by these functions, because the dynamic
 object might be compiled/linked with an incompatible
 implementation of memory allocation routines.

   . The manual says that the setup function should return non-zero on
 success, but the code actually requires a non-negative value;
 anything else prevents the dynamic object from being recorded in
 .LOADED.

HTH

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: Dynamic objects (was: .ONESEHLL not working as expected in 3.82)

[Tim Murphy]

Sorry to keep adding in my 2c but I have also submitted a plugin
implementation so I have a couple of ideas


On 29 April 2013 17:33, Eli Zaretskii e...@gnu.org wrote:


 2. The fact that the dynamic object's file extension (.so) is exposed
to the Makefile is unfortunate, because it will hurt portability of
Makefiles: the extension on Windows is .dll.  Can we omit the
extension and append it internally?


load allows one to build the plugin from within the makefile so you have
to deal with platform specific problems right there.


 4. It would be good to have at least a single simple example of a
dynamic extension, either in the tarball or in the manual.  The
only ones I found are in the test suite; did I miss something?


This is a great idea.


 6. API:

. I suggest to request that the buffers for expansions and
  evaluation by gmk_expand and gmk_eval be provided by the caller.
  It is not safe (and not very convenient) to return buffers
  allocated internally by these functions, because the dynamic
  object might be compiled/linked with an incompatible
  implementation of memory allocation routines.


Yes!

IMHO the plugin needs to be able to allocate and deallocate memory in
gmakes world i.e. you need gmk_alloc() and gmk_free().

Here's one of the tests:
static char * func_test (const char *funcname, int argc, char **argv)
{
if (strcmp (funcname, test-expand) == 0)
return test_expand (argv[0]);

if (strcmp (funcname, test-eval) == 0)
return test_eval (argv[0]);

return strdup (unknown);
}

That strdup at the end should be a gmk_strdup() if possible.

:-) Probably seems like over-engineering.

Regards, Tim

 ___
 Bug-make mailing list
 Bug-make@gnu.org
 https://lists.gnu.org/mailman/listinfo/bug-make




-- 
You could help some brave and decent people to have access to uncensored
news by making a donation at:

http://www.thezimbabwean.co.uk/friends/
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: Dynamic objects (was: .ONESEHLL not working as expected in 3.82)

[Tim Murphy]

I must clarify - I think that make should provide plugins with an
allocation mechanism. Not the other way around.


the snprintf model for dealing with expansion is not so bad - I mean the
problem is that nobody knows how big an expansion is going to be in the
end, right?  So how does make deal with this already? The same way would be
fine for the plugin and it would be nice to not simply push that problem on
to all plugin writers.

Cheers,

Tim



On 29 April 2013 18:59, Paul Smith psm...@gnu.org wrote:

 On Mon, 2013-04-29 at 19:33 +0300, Eli Zaretskii wrote:
   From: Paul Smith psm...@gnu.org
   Cc: bug-make@gnu.org
   Date: Sat, 27 Apr 2013 16:58:54 -0400
  
   On Sat, 2013-04-27 at 23:00 +0300, Eli Zaretskii wrote:
That would be nice, indeed.
  
   OK, pushed.  You should be able to simply write a new load_objects()
   function and drop it in.  Or put it into a w32 file or whatever.

  1. Doesn't the FSF frown upon capability to load _any_ dynamic
 objects?  I think they like the GCC method whereby each extension
 is required to define a symbol with a certain name
 (plugin_is_GPL_compatible in GCC), which is tested at load time,
 before the dynamic object is allowed to be loaded.

 Hm.  I guess the concern is that someone will introduce a proprietary
 plug-in?  My position on this is that it would be a violation of the
 GPL.  I don't believe there is any useful way to utilize this feature
 without becoming a derived work of GNU make, since the only way to do
 anything with this feature is to invoke GNU make functions.  As GNU make
 is GPL'd there's no dynamic linking exception.  I'll check with the
 legal folks.

  2. The fact that the dynamic object's file extension (.so) is exposed
 to the Makefile is unfortunate, because it will hurt portability of
 Makefiles: the extension on Windows is .dll.  Can we omit the
 extension and append it internally?

 Yes, that should be possible.  My concern is that, at least on UNIX, the
 rules for this are complex and I don't want to reimplement the runtime
 linker :-).  Maybe something like, first try the path as given and if
 that fails, try adding arch-specific extensions?

 The other problem here is that we want to allow rebuilding of dynamic
 objects then re-exec'ing make... if we're trying different extensions
 THAT can be a real problem... what order do we do this in?

 I'm not sure I can come up with a reliable algorithm for this that's
 understandable.

  3. I suggest to extend the search for dynamic object to a
 Make-specific directory (${prefix}/share/make/), before falling
 back to the system-specific path.  Or maybe even not fall back to
 any system-specific defaults, because those are generally set for
 shared libraries, not for plugins.  (You do NOT want to know where
 Windows will look for shared libraries.)

 I'm not sure about having a make-specific directory.  It's not so easy
 to do in UNIX--we'd have to modify the LD_LIBRARY_PATH env. var. I
 suppose.  Also we don't really have a precedent of a make-specific
 directory like that.

 On UNIX there's no way to avoid looking in the system-specific locations
 except by forcing the object path to contain a /.  I suppose that if
 the object didn't contain a / we could prefix it with ./ to force
 the avoiding of system paths.  On the other hand we DO have precedence
 for searching system paths; for example make's include will search for
 included makefiles in places like /usr/include, /usr/local/include, etc.
 even though I can't see how THAT makes sense.

  4. It would be good to have at least a single simple example of a
 dynamic extension, either in the tarball or in the manual.  The
 only ones I found are in the test suite; did I miss something?

 No.  The documentation does need to be enhanced.

  5. Is the following a valid 'load' directive?
 
   load /foo/bar/
 
 If it is valid, what is its semantics?  If it is invalid, the code
 in load_object should detect it and give a diagnostics; currently
 it will happily use this, and will try to call a symbol _gmk_setup.

 Hm.  That's odd.  It shouldn't try to call an init function unless the
 load of the dynamic object succeeds, and I would think that trying to
 dlopen(/foo/bar/) would fail.  I'll check it out.

  6. The diagnostics in read.c:
 
if (! load_file (ebuf-floc, name, noerror)  ! noerror)
  fatal (ebuf-floc, _(%s: failed to load), name);
 
 is IMO misleading: it says failed to load also in the case that
 the dynamic object was successfully loaded, but the function called
 from it returned zero.  It would be better to make a more precise
 message in that case.

 Yes, good point.

  6. API:
 
 . I suggest to request that the buffers for expansions and
   evaluation by gmk_expand and gmk_eval be provided by the caller.
   It is not safe (and not very convenient) to return buffers
   allocated internally by 

Re: Dynamic objects (was: .ONESEHLL not working as expected in 3.82)

[Eli Zaretskii]

 Date: Mon, 29 Apr 2013 18:19:09 +0100
 From: Tim Murphy tnmur...@gmail.com
 Cc: Paul D. Smith psm...@gnu.org, bug-make@gnu.org bug-make@gnu.org
 
  2. The fact that the dynamic object's file extension (.so) is exposed
 to the Makefile is unfortunate, because it will hurt portability of
 Makefiles: the extension on Windows is .dll.  Can we omit the
 extension and append it internally?
 
 
 load allows one to build the plugin from within the makefile so you have
 to deal with platform specific problems right there.

How can one deal with them?  The underlying OS is not easily
detectable by Make.

In any case, these problems are bets avoided to begin with, rather
than solved when they appear.

 . I suggest to request that the buffers for expansions and
   evaluation by gmk_expand and gmk_eval be provided by the caller.
   It is not safe (and not very convenient) to return buffers
   allocated internally by these functions, because the dynamic
   object might be compiled/linked with an incompatible
   implementation of memory allocation routines.
 
 
 Yes!
 
 IMHO the plugin needs to be able to allocate and deallocate memory in
 gmakes world i.e. you need gmk_alloc() and gmk_free().

That could also work, but sometimes will probably be inconvenient.
E.g., you'd need to copy data from a buffer that was already
allocated, just not with Make-compatible allocator.

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: Dynamic objects (was: .ONESEHLL not working as expected in 3.82)

[Eli Zaretskii]

 From: Paul Smith psm...@gnu.org
 Cc: bug-make@gnu.org
 Date: Mon, 29 Apr 2013 13:59:16 -0400
 
  1. Doesn't the FSF frown upon capability to load _any_ dynamic
 objects?  I think they like the GCC method whereby each extension
 is required to define a symbol with a certain name
 (plugin_is_GPL_compatible in GCC), which is tested at load time,
 before the dynamic object is allowed to be loaded.
 
 Hm.  I guess the concern is that someone will introduce a proprietary
 plug-in?

Yes.

  2. The fact that the dynamic object's file extension (.so) is exposed
 to the Makefile is unfortunate, because it will hurt portability of
 Makefiles: the extension on Windows is .dll.  Can we omit the
 extension and append it internally?
 
 Yes, that should be possible.  My concern is that, at least on UNIX, the
 rules for this are complex and I don't want to reimplement the runtime
 linker :-).  Maybe something like, first try the path as given and if
 that fails, try adding arch-specific extensions?

No, much simpler: _always_ append _a_single_ arch-specific extension,
and try loading that.  We should document that extension; using the
one that is used by default by the compiler for producing shared
libraries should be good enough, I think.

 The other problem here is that we want to allow rebuilding of dynamic
 objects then re-exec'ing make... if we're trying different extensions
 THAT can be a real problem... what order do we do this in?

Again, let's use only one extension.  .so on Unix, .dll on Windows.
Same as the linker does when you say -lFOO.

  3. I suggest to extend the search for dynamic object to a
 Make-specific directory (${prefix}/share/make/), before falling
 back to the system-specific path.  Or maybe even not fall back to
 any system-specific defaults, because those are generally set for
 shared libraries, not for plugins.  (You do NOT want to know where
 Windows will look for shared libraries.)
 
 I'm not sure about having a make-specific directory.  It's not so easy
 to do in UNIX--we'd have to modify the LD_LIBRARY_PATH env. var. I
 suppose.

??? I thought dlopen will gladly use an absolute file name, without
looking at LD_LIBRARY_PATH.  Was I wrong?

 Also we don't really have a precedent of a make-specific directory
 like that.

Gawk puts them into ${prefix}/lib/gawk.

 . I suggest to request that the buffers for expansions and
   evaluation by gmk_expand and gmk_eval be provided by the caller.
   It is not safe (and not very convenient) to return buffers
   allocated internally by these functions, because the dynamic
   object might be compiled/linked with an incompatible
   implementation of memory allocation routines.
 
 I don't see how this can work easily.  We have no idea how large the
 buffer will be until after we complete the expansion/eval.  The only way
 this could work is to use the snprintf() model where we do the expansion
 as now, and if it's too small we return the expected length and they'd
 have to re-invoke with a larger buffer.

Yes, that's what I had in mind.

 I think we should go with this for now.  Hopefully users that do have a
 problem will find a way to make this work.

At least on Windows, it can be a real problem, because the libraries
with which a shared object was linked are hardcoded into it, and
there's more than one way of allocating memory.

How about a callback for allocating memory?  Then Make could call that
callback and get memory that the extension could free.

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: Dynamic objects (was: .ONESEHLL not working as expected in 3.82)

[Tim Murphy]

On 29 April 2013 20:12, Eli Zaretskii e...@gnu.org wrote:

  Date: Mon, 29 Apr 2013 18:19:09 +0100
  From: Tim Murphy tnmur...@gmail.com
  Cc: Paul D. Smith psm...@gnu.org, bug-make@gnu.org 
 bug-make@gnu.org
 
   2. The fact that the dynamic object's file extension (.so) is exposed
  to the Makefile is unfortunate, because it will hurt portability of
  Makefiles: the extension on Windows is .dll.  Can we omit the
  extension and append it internally?
  
 
  load allows one to build the plugin from within the makefile so you
 have
  to deal with platform specific problems right there.

 How can one deal with them?  The underlying OS is not easily
 detectable by Make.


the same way one creates 1 makefile that can build the same code for 2
operating systems - something done every day.  You make it up. You run
uname with $(shell) or you pass in an argument from a top level script that
does know the platform or whatever.   In the end you have a bit of makefile
that says:

foo.dll: foo.obj
   .
load foo.dll

or

foo.so: foo.o
   
load foo.so


SYSTEM:=$(shell uname -s)
perhaps one has to say
ifeq ($(SYSTEM),)   # assume windows

foo.dll: foo.obj
   .
load foo.dll

else

foo.so: foo.o
   
load foo.so

endif

Regards,

Tim


-- 
You could help some brave and decent people to have access to uncensored
news by making a donation at:

http://www.thezimbabwean.co.uk/friends/
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: Dynamic objects (was: .ONESEHLL not working as expected in 3.82)

[Eli Zaretskii]

 Date: Mon, 29 Apr 2013 20:40:46 +0100
 From: Tim Murphy tnmur...@gmail.com
 Cc: Paul D. Smith psm...@gnu.org, bug-make@gnu.org bug-make@gnu.org
 
  How can one deal with them?  The underlying OS is not easily
  detectable by Make.
 
 
 the same way one creates 1 makefile that can build the same code for 2
 operating systems - something done every day.  You make it up. You run
 uname with $(shell) or you pass in an argument from a top level script that
 does know the platform or whatever.   In the end you have a bit of makefile
 that says:
 
 foo.dll: foo.obj
.
 load foo.dll
 
 or
 
 foo.so: foo.o

 load foo.so

First, there's no uname on Windows.  You are in fact saying that in
order to run a Makefile one would need something similar to autoconf.

More importantly: this is a lot of trouble we are going to impose on
_users_, just to decide which one of the two extensions to use,
something that Make can know a-priori to begin with.  How does that
make sense?  When users will ask why didn't we teach Make to do that
automatically, what answer will we have for them?

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: Dynamic objects (was: .ONESEHLL not working as expected in 3.82)

[Eli Zaretskii]

 Date: Mon, 29 Apr 2013 22:34:51 +0300
 From: Eli Zaretskii e...@gnu.org
 Cc: bug-make@gnu.org
 
  Also we don't really have a precedent of a make-specific directory
  like that.
 
 Gawk puts them into ${prefix}/lib/gawk.

Correction: ${prefix}/lib/gawk-extensions.

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: .ONESEHLL not working as expected in 3.82

[Eli Zaretskii]

 From: Paul Smith psm...@gnu.org
 Cc: bug-make@gnu.org
 Date: Sat, 27 Apr 2013 16:58:54 -0400
 
 On Sat, 2013-04-27 at 23:00 +0300, Eli Zaretskii wrote:
  That would be nice, indeed.
 
 OK, pushed.

Thanks!  But I see you kept global_dl and the call to dlopen with the
1st argument NULL.  What is the purpose of these now?

 You should be able to simply write a new load_objects() function and
 drop it in.  Or put it into a w32 file or whatever.

My plan was to write dlopen and dlsym, and add them to
w32/compat/posixfcn.c.  But I need to understand the semantics of
global_dl in order to do that correctly.

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: .ONESEHLL not working as expected in 3.82

[Eli Zaretskii]

 From: Paul Smith p...@mad-scientist.net
 Cc: make-...@gnu.org, bug-make@gnu.org
 Date: Sat, 27 Apr 2013 12:54:10 -0400
 
 On Sat, 2013-04-27 at 19:17 +0300, Eli Zaretskii wrote:
  The .ONESHELL feature is now supported on MS-Windows, for the default
  Windows shell (cmd.exe) or compatible replacements, in the development
  version (commit e56aad4).
 
 Nice!

I see you followed this up with a commit (30843de) which moved code
around that deals with the one_shell use case.  What was the reason
for that change?  I think it breaks the use case where a Unixy shell
is used on MS-Windows under .ONESHELL; this used to work before.

The code block that you moved is needed on MS-Windows as well, when
the shell passes the is_bourne_compatible_shell test.

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: .ONESEHLL not working as expected in 3.82

[Paul Smith]

On Sun, 2013-04-28 at 20:19 +0300, Eli Zaretskii wrote:
  From: Paul Smith psm...@gnu.org
  Cc: bug-make@gnu.org
  Date: Sat, 27 Apr 2013 16:58:54 -0400
  
  On Sat, 2013-04-27 at 23:00 +0300, Eli Zaretskii wrote:
   That would be nice, indeed.
  
  OK, pushed.
 
 Thanks!  But I see you kept global_dl and the call to dlopen with the
 1st argument NULL.  What is the purpose of these now?

Basically it's there to handle Guile being already compiled into make,
via direct linking at build time, in a generic way.  If it was linked
then the global symbols would be found without needing to load anything.
However this particular issue could just be handled by the #define that
links it.

  You should be able to simply write a new load_objects() function and
  drop it in.  Or put it into a w32 file or whatever.
 
 My plan was to write dlopen and dlsym, and add them to
 w32/compat/posixfcn.c.  But I need to understand the semantics of
 global_dl in order to do that correctly.

It's up to you how you think it best to implement, whether it makes more
sense to try to reimplement POSIX functions, or do it at a higher level.
Whatever is simpler.


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: .ONESEHLL not working as expected in 3.82

[Paul Smith]

On Sun, 2013-04-28 at 21:14 +0300, Eli Zaretskii wrote:
  From: Paul Smith p...@mad-scientist.net
  Cc: make-...@gnu.org, bug-make@gnu.org
  Date: Sat, 27 Apr 2013 12:54:10 -0400
  
  On Sat, 2013-04-27 at 19:17 +0300, Eli Zaretskii wrote:
   The .ONESHELL feature is now supported on MS-Windows, for the default
   Windows shell (cmd.exe) or compatible replacements, in the development
   version (commit e56aad4).
  
  Nice!
 
 I see you followed this up with a commit (30843de) which moved code
 around that deals with the one_shell use case.  What was the reason
 for that change?  I think it breaks the use case where a Unixy shell
 is used on MS-Windows under .ONESHELL; this used to work before.

I moved it because the way you had it caused one of the test cases to
fail: you had changed that block of code to be inside the if-statement,
when before it was outside/after the if-statement.

 The code block that you moved is needed on MS-Windows as well, when
 the shell passes the is_bourne_compatible_shell test.

I think you're right, sorry.  I thought that code was inside a unix-only
section but I see now it wasn't.

The code used to look like this:

  if (is_bourne_compatible_shell())
{
   ... modify the script to remove @-+ ...
   *t = '\0';
}

  /* create an argv list ... */
  {
...
new_argv[n++] = NULL;
  }
  return new_argv;

So, the setup of the new_argv[] was AFTER and outside the if-statement.
In the change you made, it was moved to be INSIDE the if-statement.
That caused a test case to fail because in the situation where we do
have one-shell and we do not have a POSIX shell, new_argv[] was empty
and no command was invoked.

I moved it back, but accidentally made it not work for Windows.

The goal of this code in the if-statement is to implement a special case
allowing ONESHELL to be easier to add in the case where you DO have a
standard shell.  In that case, and ONLY in that case, we remove the
internal @-+ characters.  This allows you to have something like:

  foo:
  @echo hi
  @echo there
  @echo how are you

And have it continue to work if you add ONESHELL (for performance
reasons) without rewriting all the recipes.

However, if you do NOT have a POSIX shell, then we do NOT remove these
internal characters: we simply provide the script as-is and only the
first line is checked for special characters.  This lets you use
something like Perl, where @ is a special character, for example:

  SHELL = /usr/bin/perl
  foo:
 @print hi;
 @array = qw(there how are you);
 print @array\n;

I think the implementation you have is not quite right.  I think the
parsing of the @-+ stuff is common across all platforms if we have a
shell, so you don't need the else /* non-posix shell */.

I think it pseudo-code it would look something like this:

  if (posix-shell)
{
  ...strip out @-+ from LINE...
}
#ifdef WINDOWS32
  if (need a batch file)
{
  ...write LINE to the batch file  setup new_argv for batch...
}
  else
#endif
{
  ...chop LINE up into new_argv...
}
  return new_argv;

Or something.  Also, I'm not sure about adding things like @echo off to
the batch file.  That assumes that we'll always be using command.com to
run the batch file, but what if the user specified C:/perl/bin/perl.exe
or something as their SHELL?

I'm probably missing something about the implementation though.


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: .ONESEHLL not working as expected in 3.82

[Eli Zaretskii]

 From: Paul Smith psm...@gnu.org
 Cc: bug-make@gnu.org
 Date: Sun, 28 Apr 2013 14:37:29 -0400
 
 On Sun, 2013-04-28 at 20:19 +0300, Eli Zaretskii wrote:
   From: Paul Smith psm...@gnu.org
   Cc: bug-make@gnu.org
   Date: Sat, 27 Apr 2013 16:58:54 -0400
   
   On Sat, 2013-04-27 at 23:00 +0300, Eli Zaretskii wrote:
That would be nice, indeed.
   
   OK, pushed.
  
  Thanks!  But I see you kept global_dl and the call to dlopen with the
  1st argument NULL.  What is the purpose of these now?
 
 Basically it's there to handle Guile being already compiled into make,
 via direct linking at build time, in a generic way.

If this is only for stuff linked into Make at build time, then I can
do that on Windows.

  My plan was to write dlopen and dlsym, and add them to
  w32/compat/posixfcn.c.  But I need to understand the semantics of
  global_dl in order to do that correctly.
 
 It's up to you how you think it best to implement, whether it makes more
 sense to try to reimplement POSIX functions, or do it at a higher level.
 Whatever is simpler.

Emulating Posix functions is simpler, because I already wrote that for
Gawk.  I just need a simple extension to handle global_dl in the above
sense.

Thanks.

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: .ONESEHLL not working as expected in 3.82

[Eli Zaretskii]

 From: Paul Smith psm...@gnu.org
 Cc: bug-make@gnu.org
 Date: Sun, 28 Apr 2013 15:15:09 -0400
 
 The goal of this code in the if-statement is to implement a special case
 allowing ONESHELL to be easier to add in the case where you DO have a
 standard shell.  In that case, and ONLY in that case, we remove the
 internal @-+ characters.  This allows you to have something like:
 
   foo:
   @echo hi
   @echo there
   @echo how are you
 
 And have it continue to work if you add ONESHELL (for performance
 reasons) without rewriting all the recipes.

I understand that much.

 However, if you do NOT have a POSIX shell, then we do NOT remove these
 internal characters: we simply provide the script as-is and only the
 first line is checked for special characters.  This lets you use
 something like Perl, where @ is a special character, for example:
 
   SHELL = /usr/bin/perl
   foo:
  @print hi;
  @array = qw(there how are you);
  print @array\n;

This is not yet supported on MS-Windows.  We currently only support
either a Bourne-compatible shell or the stock Windows shells,
command.com and cmd.exe.  And the Windows shells don't need these
characters, so it is OK to remove them as in the case of a Posix
shell.

 I think the implementation you have is not quite right.  I think the
 parsing of the @-+ stuff is common across all platforms if we have a
 shell, so you don't need the else /* non-posix shell */.

I do need a separate code, because it doesn't just remove the @-+
stuff, it also removes escaped newlines, so that this:

foo  \
 bar  \
 baz

is transformed into a single line

foo  bar  baz

That's because stock Windows shells don't know about escaped
newlines.  I also remove leading whitespace from each logical line,
while at that, because I don't want to rely on Windows shells too much
(some of their internal commands are quite weird).

 I think it pseudo-code it would look something like this:
 
   if (posix-shell)
 {
   ...strip out @-+ from LINE...
 }
 #ifdef WINDOWS32
   if (need a batch file)
 {
   ...write LINE to the batch file  setup new_argv for batch...
 }
   else
 #endif
 {
   ...chop LINE up into new_argv...
 }
   return new_argv;
 
 Or something.

I will take a look.

 Also, I'm not sure about adding things like @echo off to the batch
 file.  That assumes that we'll always be using command.com to run
 the batch file, but what if the user specified C:/perl/bin/perl.exe
 or something as their SHELL?

This is not supported yet; if the user tries that, @echo off will be
the least of their problems ;-)

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: .ONESEHLL not working as expected in 3.82

[Paul Smith]

On Sun, 2013-04-28 at 22:41 +0300, Eli Zaretskii wrote:
  I think the implementation you have is not quite right.  I think the
  parsing of the @-+ stuff is common across all platforms if we have a
  shell, so you don't need the else /* non-posix shell */.
 
 I do need a separate code, because it doesn't just remove the @-+
 stuff, it also removes escaped newlines, so that this:
 
   foo  \
  bar  \
  baz
 
 is transformed into a single line
 
 foo  bar  baz
 
 That's because stock Windows shells don't know about escaped
 newlines.  I also remove leading whitespace from each logical line,
 while at that, because I don't want to rely on Windows shells too much
 (some of their internal commands are quite weird).

Ah, OK.

I feel like we probably do this parsing more than once.  The entirety of
job.c needs a good cleaning.  But that's for another day.

  Also, I'm not sure about adding things like @echo off to the batch
  file.  That assumes that we'll always be using command.com to run
  the batch file, but what if the user specified C:/perl/bin/perl.exe
  or something as their SHELL?
 
 This is not supported yet; if the user tries that, @echo off will be
 the least of their problems ;-)

Oh, OK.  Sounds fine.  I guess I thought you were writing a batch file,
then invoking the shell with the batch file name as the command to run.
E.g., command.com batchfile vs. perl batchfile etc.  I am naive
but it seems like that should work OK even in Windows :-).

I guess there are some tricky bits if you sometimes use the command line
and sometimes a batch file (different shell options might be needed for
example).


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: .ONESEHLL not working as expected in 3.82

[Eli Zaretskii]

 From: Paul Smith psm...@gnu.org
 Cc: bug-make@gnu.org
 Date: Sun, 28 Apr 2013 16:01:05 -0400
 
 I guess I thought you were writing a batch file,
 then invoking the shell with the batch file name as the command to run.
 E.g., command.com batchfile vs. perl batchfile etc.  I am naive
 but it seems like that should work OK even in Windows :-).

It does work, but there's no need to invoke the shell explicitly in
this case.  We just invoke the batch file itself, and Windows invokes
the shell for us.  That way, we save ourselves some trouble, like
formatting the shell switches, quoting the command (could be quite
tricky with Windows shells), etc.

 I guess there are some tricky bits if you sometimes use the command line
 and sometimes a batch file (different shell options might be needed for
 example).

There's no way I know of to pass an arbitrary series of command lines
to a Windows shell, except through a batch file.

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: .ONESEHLL not working as expected in 3.82

[Eli Zaretskii]

 Date: Mon, 30 Aug 2010 17:09:51 +0100
 From: Anjum Naseer a.nas...@resilientplc.com
 
 I have built the 3.82 version of GNU Make using the Microsoft Visual C++
 compiler and it seems to work fine.
 However, I cannot get it to work correctly with the .ONESHELL option.
 I created a dummy makefile (dummy.mak) with this content:
 
 .ONESHELL:
 
 .PHONY: dummy
 
 dummy:
   set xyz=abc
   @echo xyz=%xyz%
 
 
 If I invoke this with make -d -r -f dummy.mak I get:
 Vvvv
 GNU Make 3.82
 Built for Windows32
 Copyright (C) 2010  Free Software Foundation, Inc.
 License GPLv3+: GNU GPL version 3 or later
 http://gnu.org/licenses/gpl.html
 This is free software: you are free to change and redistribute it.
 There is NO WARRANTY, to the extent permitted by law.
 Reading makefiles...
 Reading makefile `dummy.mak'...
 Updating makefiles
  Considering target file `dummy.mak'.
   Looking for an implicit rule for `dummy.mak'.
   No implicit rule found for `dummy.mak'.
   Finished prerequisites of target file `dummy.mak'.
  No need to remake target `dummy.mak'.
 Updating goal targets
 Considering target file `dummy'.
  File `dummy' does not exist.
  Finished prerequisites of target file `dummy'.
 Must remake target `dummy'.
 Invoking recipe from dummy.mak:6 to update target `dummy'.
 Creating temporary batch file
 C:\Users\ADB14~1.NAS\AppData\Local\Temp\make5868-1.bat
 Batch file contents:
 @echo off
 set xyz=abc
 set xyz=abc
 CreateProcess(C:\Users\ADB14~1.NAS\AppData\Local\Temp\make5868-1.bat,C:\
 Users\ADB14~1.NAS\AppData\Local\Temp\make5868-1.bat,...)
 Putting child 0094AFB8 (dummy) PID 9620224 on the chain.
 Live child 0094AFB8 (dummy) PID 9620224
 Main thread handle = 0054
 Reaping winning child 0094AFB8 PID 9620224
 Cleaning up temp batch file
 C:\Users\ADB14~1.NAS\AppData\Local\Temp\make5868-1.bat
 Creating temporary batch file
 C:\Users\ADB14~1.NAS\AppData\Local\Temp\make5868-1.bat
 Batch file contents:
 @echo off
 echo xyz=%xyz%
 CreateProcess(C:\Users\ADB14~1.NAS\AppData\Local\Temp\make5868-1.bat,C:\
 Users\ADB14~1.NAS\AppData\Local\Temp\make5868-1.bat,...)
 Live child 0094AFB8 (dummy) PID 9620224
 xyz=
 Reaping winning child 0094AFB8 PID 9620224
 Cleaning up temp batch file
 C:\Users\ADB14~1.NAS\AppData\Local\Temp\make5868-1.bat
 Removing child 0094AFB8 PID 9620224 from chain.
 Successfully remade target file `dummy'.
 
 
 As you can see from the debug trace above, it looks like it is still
 loading a separate SHELL for each line of the recipe. Have I
 misunderstood the .ONESHELL feature or is this a bug?

(Yes, this was almost 3 years ago.  Sorry for a long delay.)

The .ONESHELL feature is now supported on MS-Windows, for the default
Windows shell (cmd.exe) or compatible replacements, in the development
version (commit e56aad4).

I realize that one of the important use cases for .ONESHELL is to use
a shell that Make knows nothing about, but as such shells are not yet
supported by the Windows build, I didn't feel it was right to postpone
.ONESHELL any longer.  Volunteers are welcome to contribute support
for foreign shells.

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: .ONESEHLL not working as expected in 3.82

[Eli Zaretskii]

 From: Paul Smith p...@mad-scientist.net
 Cc: make-...@gnu.org, bug-make@gnu.org
 Date: Sat, 27 Apr 2013 12:54:10 -0400
 
 Also, I wonder if you have a few minutes to go through the open Windows
 bugs in Savannah and make a comment or whatever to those which are still
 waiting (some are waiting for other people, not us).  Looks like 18 bugs
 total, some pretty old.  Here's a link I hope will work for you:
 
 https://savannah.gnu.org/bugs/index.php?go_report=Applygroup=makefunc=browseset=custommsort=0report_id=141advsrch=0status_id=1platform_version_id=105fix_release_id=100

Thanks.  I went through that list and closed several bugs, either
because they were fixed or because they sound no longer relevant.
There are now only 11 open issues in that list.

Out of those 11, I will try to find time to work on about 2 or 3; the
rest are either enhancements (4 of them) that don't sound too
important to me (volunteers are welcome, of course), or await for
additional information without which I cannot advance in my
investigation of the issue.

Note: there's one more major feature in current git repo that needs to
be made available on Windows: dynamic loading of extensions.  That is
my highest priority for Make todo list.

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: .ONESEHLL not working as expected in 3.82

[Paul Smith]

On Sat, 2013-04-27 at 20:55 +0300, Eli Zaretskii wrote:
 Note: there's one more major feature in current git repo that needs to
 be made available on Windows: dynamic loading of extensions.  That is
 my highest priority for Make todo list.

Yes.  I wonder if there are features of gnulib which make this work in a
cross-platform way?  I've often wondered if we might get some win out of
utilizing gnulib more in GNU make code.

However, I think that investigation and reworking will need to wait
until after the next release.  I don't want to open that can of worms
yet... at least not widely.  But if you see something there that would
make your work for load simpler let me know and we'll look into it.


One other thing: I want to make a format cleanup commit at some point to
deal with a number of annoying issues related to TABs, EOL syntax, etc.,
as well as update copyright dates, etc.  I don't want to do that when it
will conflict with major work anyone else is doing, so let me know when
a good time is for you.


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: .ONESEHLL not working as expected in 3.82

[Eli Zaretskii]

 From: Paul Smith psm...@gnu.org
 Cc: make-...@gnu.org, bug-make@gnu.org
 Date: Sat, 27 Apr 2013 14:28:18 -0400
 
 On Sat, 2013-04-27 at 20:55 +0300, Eli Zaretskii wrote:
  Note: there's one more major feature in current git repo that needs to
  be made available on Windows: dynamic loading of extensions.  That is
  my highest priority for Make todo list.
 
 Yes.  I wonder if there are features of gnulib which make this work in a
 cross-platform way?  I've often wondered if we might get some win out of
 utilizing gnulib more in GNU make code.

AFAICS, gnulib does not offer any modules that support dynamic loading
of shared libraries.

 However, I think that investigation and reworking will need to wait
 until after the next release.  I don't want to open that can of worms
 yet... at least not widely.  But if you see something there that would
 make your work for load simpler let me know and we'll look into it.

I added a similar facility to Gawk, but there a problem was much
simpler, because Gawk itself was tracking the loaded extensions in
platform-independent code.  So my emulation of dlopen didn't need to
support NULL as its first argument, and didn't care about RTLD_GLOBAL.

By contrast, the way Make's code in load.c is written, it relies on
dlopen to track the shared libraries already loaded.  This is a PITA
on Windows, because there's no similar functionality built in, and the
emulation of dlopen will have to record each loaded extension in some
internal data structure, and search that when dlopen is called with
its 1st argument NULL.  Not rocket science, granted, but it does make
the job larger and the required testing more extensive.

If Make could behave like Gawk, I could have simply copied the code I
wrote for Gawk and reuse it almost verbatim.

 One other thing: I want to make a format cleanup commit at some point to
 deal with a number of annoying issues related to TABs, EOL syntax, etc.,
 as well as update copyright dates, etc.  I don't want to do that when it
 will conflict with major work anyone else is doing, so let me know when
 a good time is for you.

As far as I'm concerned, you can do it whenever you want.  I'd be
greatly surprised if git couldn't figure out how to merge stuff like
that cleanly.  CVS could have barfed, but not git (or any other modern
VCS that tracks the history DAG).

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: .ONESEHLL not working as expected in 3.82

[Paul Smith]

I took with make-w32 list off.

On Sat, 2013-04-27 at 22:18 +0300, Eli Zaretskii wrote:
 I added a similar facility to Gawk, but there a problem was much
 simpler, because Gawk itself was tracking the loaded extensions in
 platform-independent code.  So my emulation of dlopen didn't need to
 support NULL as its first argument, and didn't care about RTLD_GLOBAL.
 
 By contrast, the way Make's code in load.c is written, it relies on
 dlopen to track the shared libraries already loaded.  This is a PITA
 on Windows, because there's no similar functionality built in, and the
 emulation of dlopen will have to record each loaded extension in some
 internal data structure, and search that when dlopen is called with
 its 1st argument NULL.  Not rocket science, granted, but it does make
 the job larger and the required testing more extensive.

Well, we already maintain a list of modules that are loaded in
the .LOADED variable.  Although it's not written like that today, I have
no problem changing the code to check that variable to see whether the
module is loaded or not.  We already make that check, to ensure we don't
call the user's init function twice.


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: .ONESEHLL not working as expected in 3.82

[Eli Zaretskii]

 From: Paul Smith psm...@gnu.org
 Cc: bug-make@gnu.org
 Date: Sat, 27 Apr 2013 15:32:22 -0400
 
 Well, we already maintain a list of modules that are loaded in
 the .LOADED variable.  Although it's not written like that today, I have
 no problem changing the code to check that variable to see whether the
 module is loaded or not.

That would be nice, indeed.

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: .ONESEHLL not working as expected in 3.82

[Paul Smith]

On Sat, 2013-04-27 at 23:00 +0300, Eli Zaretskii wrote:
 That would be nice, indeed.

OK, pushed.  You should be able to simply write a new load_objects()
function and drop it in.  Or put it into a w32 file or whatever.



___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

-n option not working under selected circumstances

[gabriele balducci]

Hi there,

just stumbled on this while building openssl.

Usually I run `make -n install' to see where things will eventually
go. However, to my great surprise, I found that `make -n install' DID
ACTUALLY INSTALL everything!

After some work, it turns out that the problem can be reproduced (for
me) by the following Makefile:

t1 :
rm -f ./mom  touch ./mom  echo $(MAKE)

t2 :
rm -f ./mom ; \
touch ./mom ; \
echo $(MAKE)

t3 :
rm -f ./mom
touch ./mom
echo $(MAKE)


All works as if the `-n' option is not honored when the variable
$(MAKE) (and apparently only that) is referenced in a target's shell
line:

make -n t1 will create ./mom (while it should not)

make -n t2 ditto

make -n t3 will work as expected, i.e. no ./mom file created



I can add that a very similar misbehavior has been already recently
reported:

http://lists.gnu.org/archive/html/bug-make/2009-12/msg00019.html


The make version is:

  # make --version
  GNU Make 3.81
  Copyright (C) 2006  Free Software Foundation, Inc.
  This is free software; see the source for copying conditions.
  There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
  PARTICULAR PURPOSE.

  This program built for i686-pc-linux-gnu
  # 

Apologies if I am misunderstanding something.

Thanks for your work and for any information about this issue


ciao
gabriele


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: -n option not working under selected circumstances

[Paul Smith]

On Thu, 2010-01-21 at 18:17 +0100, gabriele balducci wrote:
 t1 :
   rm -f ./mom  touch ./mom  echo $(MAKE)
 
 All works as if the `-n' option is not honored when the variable
 $(MAKE) (and apparently only that) is referenced in a target's shell
 line:
 
 make -n t1 will create ./mom (while it should not)

This is not a bug in make, per se, it's an error in the makefile.  This
behavior is documented in the manual, where it says:

   The `-n', `-t', and `-q' options do not affect command lines
that
begin with `+' characters or contain the strings `$(MAKE)' or
`${MAKE}'.  Note that only the line containing the `+' character
or the strings `$(MAKE)' or `${MAKE}' is run regardless of these
options.

The makefile needs to not use the MAKE variable in a context where it
would do bad things given -n.




___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: -n option not working under selected circumstances

[Paul Smith]

[[ Please keep the mailing list on the CC line... ]]

On Thu, 2010-01-21 at 18:56 +0100, gabriele balducci wrote:
 If I can take advantage of your patience: so, `make -n install' is not
 100% safe? Well, actually, this is the first time I incurred in this
 problem in many years; yet... 

Whether it is safe or not depends on the whether that particular
makefile is written properly (with respect to this feature of GNU make).

Normally, when people create install rules they don't put references to
$(MAKE) in the same command line that also does other, side-effect
things like copy files around.  Instead they make sure that the $(MAKE)
reference is on its own line (as you see in your t3 example, make does
not run any line that doesn't contain $(MAKE)).

Regardless of whether the rule is install, clean, or anything else,
make always operates the same way (there's nothing special to make about
a target named install; that's just a convention that makefile writers
use).


Basically what I'm saying is this is a problem in the implementation of
the install rule(s) in the openssl makefile(s) and should be reported
to them.



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: -n option not working under selected circumstances

[gabriele balducci]

 
 On Thu, 2010-01-21 at 18:56 +0100, gabriele balducci wrote:
  If I can take advantage of your patience: so, `make -n install' is not
  100% safe? Well, actually, this is the first time I incurred in this
  problem in many years; yet... 
 
 Whether it is safe or not depends on the whether that particular
 makefile is written properly (with respect to this feature of GNU make).

This is clear to me, now.

 
 Normally, when people create install rules they don't put references to
 $(MAKE) in the same command line that also does other, side-effect
 things like copy files around.  Instead they make sure that the $(MAKE)
 reference is on its own line (as you see in your t3 example, make does
 not run any line that doesn't contain $(MAKE)).
 
 Regardless of whether the rule is install, clean, or anything else,
 make always operates the same way (there's nothing special to make about
 a target named install; that's just a convention that makefile writers
 use).
 
 
 Basically what I'm saying is this is a problem in the implementation of
 the install rule(s) in the openssl makefile(s) and should be reported
 to them.

I think I will do this


Again: thanks a lot for your work and patience



ciao
gabriele


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: -n option not working under selected circumstances

[gabriele balducci]

oops, I might have botched something with the email, so I resend the
last one: apologies for any noise.

 
 On Thu, 2010-01-21 at 18:56 +0100, gabriele balducci wrote:
  If I can take advantage of your patience: so, `make -n install' is not
  100% safe? Well, actually, this is the first time I incurred in this
  problem in many years; yet... 
 
 Whether it is safe or not depends on the whether that particular
 makefile is written properly (with respect to this feature of GNU make).
 

This is clear to me, now.

 Normally, when people create install rules they don't put references to
 $(MAKE) in the same command line that also does other, side-effect
 things like copy files around.  Instead they make sure that the $(MAKE)
 reference is on its own line (as you see in your t3 example, make does
 not run any line that doesn't contain $(MAKE)).
 
 Regardless of whether the rule is install, clean, or anything else,
 make always operates the same way (there's nothing special to make about
 a target named install; that's just a convention that makefile writers
 use).
 
 
 Basically what I'm saying is this is a problem in the implementation of
 the install rule(s) in the openssl makefile(s) and should be reported
 to them.

I think I will do it


Again: thanks a lot for your work and patience



ciao
gabriele


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: -n option not working under selected circumstances

[Paul Smith]

On Thu, 2010-01-21 at 19:18 +0100, gabriele balducci wrote:
 Again: thanks a lot for your work and patience

No problem.  Cheers!



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

conditionals not working for conditional variables in sub-make?

[Szekeres István]

Please see the makefile attached.
by running it it outputs:
VAR=foo VAR2=bar VAR3=foo

but I think VAR2 should be foo.

Bug or do I misunderstand something?

thanks,
Istvan



ifeq ($(VAR),foo)
VAR2=foo
else
VAR2=bar
endif

VAR3=$(VAR)

all: 
make var1 
make var2

var1: VAR=foo
var1: do-echo

var2: VAR=bar
var2: do-echo

do-echo:
@echo VAR=$(VAR) VAR2=$(VAR2) VAR3=$(VAR3)

___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

RE: conditionals not working for conditional variables in sub-make?

[Martin Dorey]

You misunderstand something.
 
 it outputs:
 VAR=foo VAR2=bar VAR3=foo
 
That's only a small fraction of what I see, with make-3.81.  This is what I see:
 
mart...@whitewater:~/tmp/bug-make-2009-05-07$ make
make var1 
make[1]: Entering directory `/home/martind/tmp/bug-make-2009-05-07'
VAR=foo VAR2=bar VAR3=foo
make[1]: Leaving directory `/home/martind/tmp/bug-make-2009-05-07'
make var2
make[1]: Entering directory `/home/martind/tmp/bug-make-2009-05-07'
VAR=bar VAR2=bar VAR3=bar
make[1]: Leaving directory `/home/martind/tmp/bug-make-2009-05-07'
mart...@whitewater:~/tmp/bug-make-2009-05-07$
 
Perhaps you want the all rule to say:
 
all: var1 var2
 
Then I see the desired output:
 
mart...@whitewater:~/tmp/bug-make-2009-05-07$ make
VAR=foo VAR2=bar VAR3=foo
mart...@whitewater:~/tmp/bug-make-2009-05-07$
 
-Original Message-
From: bug-make-bounces+mdorey=bluearc@gnu.org 
[mailto:bug-make-bounces+mdorey=bluearc@gnu.org] On Behalf Of Szekeres 
István
Sent: Thursday, May 07, 2009 02:57
To: bug-make@gnu.org
Subject: conditionals not working for conditional variables in sub-make?
 
Please see the makefile attached.
by running it it outputs:
VAR=foo VAR2=bar VAR3=foo
 
but I think VAR2 should be foo.
 
Bug or do I misunderstand something?
 
thanks,
Istvan
 
___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: conditionals not working for conditional variables in sub-make?

[Szekeres István]

Hi,

2009/5/7 Martin Dorey mdo...@bluearc.com:
 That's only a small fraction of what I see, with make-3.81.  This is what I
 see:
 [...]
 VAR=foo VAR2=bar VAR3=foo

But here VAR2 should be foo As VAR=foo, the ifeq then-branch
should set it to foo, but it goes into the else branch - which I think
it shouldn't do.

 Perhaps you want the all rule to say:

 all: var1 var2

No, it is different. I definitely want the sub-make because I want too
runs with VAR substituted to foo in the first run and to bar in the
second. As you can see the VAR variable picks up the right value
(do-echo outputs foo and then bar) but the ifeq does not pick up the
value, basically the ifeq(foo,foo) goes into the else branch.


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

RE: conditionals not working for conditional variables in sub-make?

[Martin Dorey]

 But here VAR2 should be foo!

No, it shouldn't, for exactly the same reason that VAR2 isn't foo here:

mart...@whitewater:~/tmp/bug-make-2009-05-07$ make var1
VAR=foo VAR2=bar VAR3=foo
mart...@whitewater:~/tmp/bug-make-2009-05-07$

Despite the number of exclamation marks, it's not clear why you think VAR2 
should be foo.  Do you think VAR was foo when make was started?  Or do you 
think that make reevaluates all the code at global scope in the context of 
every target?

-Original Message-
From: Szekeres István [mailto:szeke...@iii.hu] 
Sent: Thursday, May 07, 2009 12:58
To: Martin Dorey
Cc: bug-make@gnu.org
Subject: Re: conditionals not working for conditional variables in sub-make?

Hi,

2009/5/7 Martin Dorey mdo...@bluearc.com:
 That's only a small fraction of what I see, with make-3.81.  This is what I
 see:
 [...]
 VAR=foo VAR2=bar VAR3=foo

But here VAR2 should be foo As VAR=foo, the ifeq then-branch
should set it to foo, but it goes into the else branch - which I think
it shouldn't do.

 Perhaps you want the all rule to say:

 all: var1 var2

No, it is different. I definitely want the sub-make because I want too
runs with VAR substituted to foo in the first run and to bar in the
second. As you can see the VAR variable picks up the right value
(do-echo outputs foo and then bar) but the ifeq does not pick up the
value, basically the ifeq(foo,foo) goes into the else branch.


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

RE: conditionals not working for conditional variables in sub-make?

[Martin Dorey]

 VAR become foo when the var1 rule was executed.
 it reevaluates because of the explicit make commands in the all rule.

Think about the order in which those two things happen.

The second one happens before the first and hence doesn't see the first's 
effect.

A thought experiment might help you to see the light.  Imagine in the all 
rule, that instead of running make var1, you ran 
a-script-which-happens-to-invoke-make-var1.

-Original Message-
From: Szekeres István [mailto:szeke...@iii.hu] 
Sent: Thursday, May 07, 2009 14:40
To: Martin Dorey
Cc: bug-make@gnu.org
Subject: Re: conditionals not working for conditional variables in sub-make?

2009/5/7 Martin Dorey mdo...@bluearc.com:
 But here VAR2 should be foo!

 No, it shouldn't, for exactly the same reason that VAR2 isn't foo here:

 mart...@whitewater:~/tmp/bug-make-2009-05-07$ make var1
 VAR=foo VAR2=bar VAR3=foo
 mart...@whitewater:~/tmp/bug-make-2009-05-07$

 Despite the number of exclamation marks, it's not clear why you think VAR2 
 should be foo.

See Target specific variables in the make info. In my example the
var1 rule sets VAR to foo (correctly), the var2 rule sets it to
bar (correctly).

  Do you think VAR was foo when make was started?

No. VAR become foo when the var1 rule was executed.

 Or do you think that make reevaluates all the code at global scope in the 
 context of every target?

No, it reevaluates because of the explicit make commands in the all rule.

The var1 rule sets VAR to foo, and VAR3 is set to $(VAR) globally,
and this works correctly, you can see this even in your own output:


   mart...@whitewater:~/tmp/bug-make-2009-05-07$ make
   make var1
   make[1]: Entering directory `/home/martind/tmp/bug-make-2009-05-07'
   VAR=foo VAR2=bar VAR3=foo

VAR is foo and VAR3 is also foo, correct.

   make[1]: Leaving directory `/home/martind/tmp/bug-make-2009-05-07'
   make var2
   make[1]: Entering directory `/home/martind/tmp/bug-make-2009-05-07'
   VAR=bar VAR2=bar VAR3=bar

VAR is bar and VAR3 is also bar, correct.

The problem is the value of VAR2: in the first case it should be
foo, because the if statement
   ifeq ($(VAR),foo)
   VAR2=foo
   else
   VAR2=bar
   endif

should compare $(VAR) (which is foo in the first case) to foo -
they are the same  so the then-branch should be executed, setting VAR2
to foo. But in the output you can see that VAR2 is not set to foo, and
this is what I reported in my very first mail.


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

RE: conditionals not working for conditional variables in sub-make?

[Martin Dorey]

(Re-adding list.)
 
 First run
 Second run
 
Make is run three times, once by the human, twice by the makefile.  I'm not 
sure what you mean with this numbering.  I think you mean the first and second 
runs of the echo command in the do-echo rule but please correct me if I'm wrong.
 
 These can clearly be seen in your output.
 
I'll reproduce the two lines of echo output here for clarity:
 
VAR=foo VAR2=bar VAR3=foo
VAR=bar VAR2=bar VAR3=bar
 
 if in the first run VAR3 can pick up the value foo, indicating
 that VAR is also foo
 
In the first line that I quote above, which is produced by a child of the 
second make invocation - the one tasked with building var1 - VAR3 is evaluated 
during the invocation of the do-echo rule as a prerequisite of the var1 rule.  
Per:
 
   There is one more special feature of target-specific variables: when
 you define a target-specific variable that variable value is also in
 effect for all prerequisites of this target
 
This means that var1's target-specific assignment of foo to VAR is in effect.
 
VAR3 is defined using deferred evaluation - = rather than := - so the 
right-hand side of the assignment is deferred to evaluation-time.  At 
evaluation time, as we've seen, the right-hand side - $(VAR) - is foo.
 
 why does the statement ifeq($(VAR),foo) fail?
 
That statement is evaluated during an earlier phase of make's execution.  It's 
not reevaluated for every target.  At the time, and in the scope, when it was 
evaluated, $(VAR) was unset, hence empty.
 
-Original Message-
From: Szekeres István [mailto:szeke...@iii.hu] 
Sent: Thursday, May 07, 2009 14:50
To: Martin Dorey
Subject: Re: conditionals not working for conditional variables in sub-make?
 
2009/5/7 Martin Dorey mdo...@bluearc.com:
 VAR become foo when the var1 rule was executed.
 it reevaluates because of the explicit make commands in the all rule.
 
 Think about the order in which those two things happen.
 
 The second one happens before the first and hence doesn't see the first's 
 effect.
 
 A thought experiment might help you to see the light.  Imagine in the all 
 rule, that instead of running make var1, you ran 
 a-script-which-happens-to-invoke-make-var1.
 
Sorry I am still not convinced.
 
First run: VAR=foo, VAR3 picks up the value of VAR, becoming also foo, correct.
Second run: VAR=bar, VAR3 picks up the value of VAR, becoming also bar, correct.
 
Can we agree that these two statements are OK? These can clearly be
seen in your output.
 
BUT: if in the first run VAR3 can pick up the value foo, indicating
that VAR is also foo, then why does the statement ifeq($(VAR),foo)
fail???
___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: conditionals not working for conditional variables in sub-make?

[Szekeres István]

2009/5/7 Martin Dorey mdo...@bluearc.com:
 But here VAR2 should be foo!

 No, it shouldn't, for exactly the same reason that VAR2 isn't foo here:

 mart...@whitewater:~/tmp/bug-make-2009-05-07$ make var1
 VAR=foo VAR2=bar VAR3=foo
 mart...@whitewater:~/tmp/bug-make-2009-05-07$

 Despite the number of exclamation marks, it's not clear why you think VAR2 
 should be foo.

See Target specific variables in the make info. In my example the
var1 rule sets VAR to foo (correctly), the var2 rule sets it to
bar (correctly).

  Do you think VAR was foo when make was started?

No. VAR become foo when the var1 rule was executed.

 Or do you think that make reevaluates all the code at global scope in the 
 context of every target?

No, it reevaluates because of the explicit make commands in the all rule.

The var1 rule sets VAR to foo, and VAR3 is set to $(VAR) globally,
and this works correctly, you can see this even in your own output:


   mart...@whitewater:~/tmp/bug-make-2009-05-07$ make
   make var1
   make[1]: Entering directory `/home/martind/tmp/bug-make-2009-05-07'
   VAR=foo VAR2=bar VAR3=foo

VAR is foo and VAR3 is also foo, correct.

   make[1]: Leaving directory `/home/martind/tmp/bug-make-2009-05-07'
   make var2
   make[1]: Entering directory `/home/martind/tmp/bug-make-2009-05-07'
   VAR=bar VAR2=bar VAR3=bar

VAR is bar and VAR3 is also bar, correct.

The problem is the value of VAR2: in the first case it should be
foo, because the if statement
   ifeq ($(VAR),foo)
   VAR2=foo
   else
   VAR2=bar
   endif

should compare $(VAR) (which is foo in the first case) to foo -
they are the same  so the then-branch should be executed, setting VAR2
to foo. But in the output you can see that VAR2 is not set to foo, and
this is what I reported in my very first mail.


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

$(and) and $(or) not working

[Noel Yap]

I'm using the following:

yapn:[EMAIL PROTECTED]:~/proj/aoeu make --version
GNU Make 3.81beta4
Copyright (C) 2003  Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.

This program built for i486-pc-linux-gnu


And the $(and) and $(or) functions always return empty.  Has anyone
else experienced this?

Thanks,
Noel


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

RE: $(and) and $(or) not working

[Dave Korn]

On 16 May 2007 16:22, Noel Yap wrote:

 I'm using the following:
 
 yapn:[EMAIL PROTECTED]:~/proj/aoeu make --version
 GNU Make 3.81beta4

  Note the beta tag.

 And the $(and) and $(or) functions always return empty.  Has anyone
 else experienced this?

  Probably means they weren't yet implemented at the time the beta was
released.  To find out for sure, try using the --warn-undefined-variables
option; if the built-ins aren't implemented, those will just look like
variable references to empty vars.


cheers,
  DaveK
-- 
Can't think of a witty .sigline today



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: $(and) and $(or) not working

[Paul Smith]

On Wed, 2007-05-16 at 11:21 -0400, Noel Yap wrote:
 I'm using the following:
 
 yapn:[EMAIL PROTECTED]:~/proj/aoeu make --version
 GNU Make 3.81beta4

I've seen a number of messages stating that people are using 3.81beta4;
why are people still using a beta version over a year after the final
version was released (3.81 was released on 01 Apr 2006)?  Did it get
shipped with some distribution or software package?  If so you should
file a bug and request an update to the released version.

Anyway, as others have pointed out, the and and or functions weren't
implemented in beta4.


PS. Please choose one of bug-make or help-make, but not both.  Cheers!

-- 
---
 Paul D. Smith [EMAIL PROTECTED]  Find some GNU make tips at:
 http://www.gnu.org  http://make.paulandlesley.org
 Please remain calm...I may be mad, but I am a professional. --Mad Scientist


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #15913] Target-specific immediate append operator not working as expected

[Paul D. Smith]

Update of bug #15913 (project make):

  Status:None = Fixed  
 Open/Closed:Open = Closed 
   Fixed Release:None = CVS

___

Follow-up Comment #2:

OK, I've fixed this for the next release of GNU make.

___

Reply to this item at:

  http://savannah.gnu.org/bugs/?func=detailitemitem_id=15913

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #15913] Target-specific immediate append operator not working as expected

[Paul D. Smith]

Update of bug #15913 (project make):

 Assigned to:None = psmith 

___

Follow-up Comment #1:

Please see this reply I sent to the original message on the bug-make mailing
list:

http://www.mail-archive.com/bug-make%40gnu.org/msg03815.html

___

Reply to this item at:

  http://savannah.gnu.org/bugs/?func=detailitemitem_id=15913

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Target specific immediate append operator not working as expected

[lasse.makholm]

There is some weirdness going on with the append operator and
target-specific contexts.

The append operator should act immediately if the variable was
originally assigned with an immediate assignment but this does not
happen if the variable was globally assigned and the append is
target-specific, the append does variable expansion (as if the variable
had been deferred).

Here's a test case showing the problem:

colsw07m - cat Makefile

VAR := $$LOGNAME

bar: VAR += bar

foo bar:
echo $(VAR)

colsw07m - ~/src/make/make-3.81rc1/make foo
echo $LOGNAME
makholm
colsw07m - ~/src/make/make-3.81rc1/make bar
echo OGNAME bar
OGNAME bar

Making the assignment target-specific or making the append global both
work as expected.

It seems to be a thing introduced in 3.80 which makes sense since AFAIK
3.80 brought some fixes to target specific variables.
3.78.1 seems to work correctly.
3.79.1, as expected, breaks with target-specific variables.
3.80 works the same as 3.80rc1.

The documentation (chapter on target-specific vars) states that:

The variable-assignment can be any valid form of assignment; recursive
(`='), static (`:='), appending (`+='), or conditional (`?='). All
variables that appear within the variable-assignment are evaluated
within the context of the target: thus, any previously-defined
target-specific variable values will be in effect. Note that this
variable is actually distinct from any global value: the two variables
do not have to have the same flavor (recursive vs. static).

What basically happens though is that the target-specific append treats
the global instance of VAR as recursive.

I would consider this a bug especially since this:

bar: VAR := $(VAR) bar

...also works as expected...

On a slightly related side note, the manual seems to switch between the
terms immediate/deferred and static/recursive for describing the same
things; the two flavours of variables... Perhaps the two pairs of terms
should be unified into one?

/Lasse


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

escape \: not working properly

[Jason Sheu]

Hi,



I cannot seem to escape : from the name name.
Here is a test Makefile.



53 cat Makefile



all: testDirColon testFileColon



testDirColon: dir\:1/file1

 echo Dir
test passed: $?



testFileColon: dir2/file1\:1

 echo File
test passed: $?



31 gmake

gmake: *** No rule to make target `dir\:1/file1', needed by
`testDirColon'. Stop.








makeColonBug.tar.gz
Description: makeColonBug.tar.gz
___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: escape \: not working properly

[Paul D. Smith]

%% Jason Sheu [EMAIL PROTECTED] writes:

  js I cannot seem to escape : from the name name. Here is a test
  js Makefile.

Using colons in prerequisite names is not supported by make (same with
spaces in names).

There is an enhancement request on this in the Savannah bug database.

-- 
---
 Paul D. Smith [EMAIL PROTECTED]  Find some GNU make tips at:
 http://www.gnu.org  http://make.paulandlesley.org
 Please remain calm...I may be mad, but I am a professional. --Mad Scientist


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: [bug #13952] Remaking included makefile fails under Linux RedHat 7.3 while working under Solaris 2.6

[Paul D. Smith]

%% Thibaud Gaillard [EMAIL PROTECTED] writes:

  tg This is especially difficult in this case since remaking
  tg makefiles is somewhat a hidden process in GNU make and very
  tg difficult to catch.

It's not hidden at all; if you remove the @ then you'll see the
commands as they're executed, just as with rebuilding any other target.
The only part that isn't immediately obvious is when make re-execs
itself.  But, it's easy enough to see this, too, if you enable debugging
(-d option).

   In this case I believe there is not a bug here.  It _seems_ that
   you're rebuilding the same included file (Makefile.dep) multiple
   times with multiple re-execs in between.  However, note that make's
   out-of-date algorithm does not consider a target to have actually
   been updated unless its timestamp has CHANGED.  If make runs a
   command and after the command the timestamp on the target is the
   same as it was before the command, then make doesn't think the
   target changed.  If make doesn't think that the Makefile.dep file
   changed, it won't re-exec.  In the case of the Linux systems, the
   re-exec and update of the file happens within a second, so if
   you're using a filesystem that doesn't support sub-second
   timestamps make won't realize the target was updated.

  tg Yes, you are right: the same included file (Makefile.dep) is
  tg rebuilt many time thanks to GNU make's remake feature. In this
  tg case, 3 re-exec are needed to complete Makefile.dep (complete
  tg means that this file will not change its timestamp when two
  tg consecutive generations yield the same file, with respect to
  tg diff).

  tg Makefile.dep *changes* thanks to the
  tg '$(update-target-from-tmp-if-different-only)' macro, and this is
  tg confirmed under Linux when running make a second time on the
  tg test-case, as it will finalize Makefile.dep. Why was not that done
  tg during the first make run, then?

Because the first time, the timestamp DOES change.  Before, the file
doesn't exist.  After, it does exist.

  tg I agree the problem may be in the filesystem (ext3 on my machine,
  tg I guess it supports sub-second timestamps) in case it cannot track
  tg time differences as small as two consecutive make re-exec, but in
  tg that case, what can I do?

You have two choices that I can see: first, you can sleep 1 before
updating the file so that it will always have a newer timestamp.

Or, you could use 3 different files instead of updating the same file 3
times.

  tg This code was working on a (slower) Sparc Solaris 2.6, does it
  tg mean that GNU make will stop working on much faster machines
  tg because the filesystem resolution does not follow with higher
  tg precision?

Assuming I'm right about what's happening, then yes, that's what it
means.

-- 
---
 Paul D. Smith [EMAIL PROTECTED]  Find some GNU make tips at:
 http://www.gnu.org  http://make.paulandlesley.org
 Please remain calm...I may be mad, but I am a professional. --Mad Scientist


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

CURDIR not working properly on solaris

[Luu, Jose]

Hi



It seems that the variable CURDIR does not work on solaris,
making it impossible to use it as inside recursive makefiles (as it keeps the
same value even if make is invoked with -C



This is make-3.80 on solaris 8 , I have tried to
recompile with various compilers:

Sun 4.2

Sun 6U2

Gcc 2.95



The make package available on sunfreeware also
exhibits this behavior.



Thanks

Jose








___
Bug-make mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-make

Re: CURDIR not working properly on solaris

[Paul D. Smith]

%% Luu, Jose [EMAIL PROTECTED] writes:

  lj It seems that the variable CURDIR does not work on solaris, making
  lj it impossible to use it as inside recursive makefiles (as it keeps
  lj the same value even if make is invoked with -C

  lj This is make-3.80 on solaris 8 , I have tried to recompile with
  lj various compilers:

  lj Sun 4.2

  lj Sun 6U2

  lj Gcc 2.95

  lj The make package available on sunfreeware also exhibits this
  lj behavior.

Please always remember to include the version of GNU make you're using.


Curdir can't really fail: it just gets set to the working directory.  So
there must be something about your shell setup or environment or
makefiles that's causing the problem.

Please create a very small example makefile that still exhibits the
problem, then send it along with a sample invocation, the output you
got, and what you expected to get.

-- 
---
 Paul D. Smith [EMAIL PROTECTED]  Find some GNU make tips at:
 http://www.gnu.org  http://make.paulandlesley.org
 Please remain calm...I may be mad, but I am a professional. --Mad Scientist


___
Bug-make mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-make

make not working

[APSewell]

  I have been running the LINUX 7.0 operating system for over a year now developing FORTRAN codes. I have been successfully using MAKE to complie and link FORTRAN routines. Suddenly in the last few days MAKE doesn't work anymore, I get the message "Nothing to be done for xxx.mak " , even though I have made changes to one or more of the FORTRAN routines. What has changed, and can I fix the bug?
 I am writing this e-mail from my Windows operating system, if that makes a difference.
 Alan Sewell
 [EMAIL PROTECTED]