Usefulness of make -t

[Alejandro Colomar]

Hi Paul,

Yesterday I found another use of make's -t flag: It helps make sure
that the logic in the Makefile is correct.  You could run the target
without -t, but then you risk seeing warnings and errors from the
commands run by the target before make's own ones, which would hide
Makefile problems.

If you run `make -kstj [target(s)]` after modifying a Makefile, it
will show only and all^Wmost problems in the Makefile itself.  It
could be especially useful with 4.4's --shuffle, although I don't
have it yet in Debian Sid :(.  I should build from source and try it.

I'll start using that as a rule to check changes to Makefiles, and
hopefully will avoid introducing bugs that I need to fix in the next
commit :)



Cheers,
Alex


-- 

GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5


OpenPGP_signature
Description: OpenPGP digital signature

`make check -j` fails when building GNU Make from source

[Alejandro Colomar]

Hi,

If I build make from source and run the checks in parallel, some fail.
Is this expected, or is it a bug in the Makefile?

Cheers,
Alex

-- 

GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5

makeerror-4.4.1-x86_64-pc-linux-gnu-t3wj.tar.gz
Description: application/gzip


OpenPGP_signature
Description: OpenPGP digital signature

Re: Usefulness of make -t

[Alejandro Colomar]

On 4/2/23 14:20, Alejandro Colomar wrote:
> Hi Paul,
> 
> Yesterday I found another use of make's -t flag: It helps make sure
> that the logic in the Makefile is correct.  You could run the target
> without -t, but then you risk seeing warnings and errors from the
> commands run by the target before make's own ones, which would hide
> Makefile problems.
> 
> If you run `make -kstj [target(s)]` after modifying a Makefile, it
> will show only and all^Wmost problems in the Makefile itself.  It
> could be especially useful with 4.4's --shuffle, although I don't
> have it yet in Debian Sid :(.  I should build from source and try it.
> 
> I'll start using that as a rule to check changes to Makefiles, and
> hopefully will avoid introducing bugs that I need to fix in the next
> commit :)
> 
> 

Running this a few times works like a charm:

$ make -kstj --shuffle >/dev/null; make clean >/dev/null

Very recommended :)

> 
> Cheers,
> Alex
> 
> 

-- 

GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5


OpenPGP_signature
Description: OpenPGP digital signature

Re: `make check -j` fails when building GNU Make from source

[Paul Smith]

On Sun, 2023-04-02 at 14:52 +0200, Alejandro Colomar wrote:
> If I build make from source and run the checks in parallel, some
> fail.  Is this expected, or is it a bug in the Makefile?

The test suite is invoked as a single target, so there's no way that
enabling parallelism could impact it.  Also the test suite tries to be
careful about shielding the internal invocations of make from
environmental factors like user settings of MAKEFLAGS and GNUMAKEFLAGS
etc.

Indeed I tried "make check -j" and got no failures.

Based on the diffs it appears make was able to find files like "foo"
and "bar" when it didn't expect them to exist.  I'm not really sure how
that would happen but if you can figure it out I would be interested to
know.  If you run:

  cd tests
  ./run_make_tests -make ../make features/escape

does it fail?

[bug #63867] Port to older versions of gnu tar.

[Paul D. Smith]

Update of bug #63867 (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 #4:

Pushed a fix for this, thanks for the note.


___

Reply to this item at:

  

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

Re: `make check -j` fails when building GNU Make from source

[Alejandro Colomar]

Hi Paul,

On 4/2/23 16:04, Paul Smith wrote:
> On Sun, 2023-04-02 at 14:52 +0200, Alejandro Colomar wrote:
>> If I build make from source and run the checks in parallel, some
>> fail.  Is this expected, or is it a bug in the Makefile?
> 
> The test suite is invoked as a single target, so there's no way that
> enabling parallelism could impact it.  Also the test suite tries to be
> careful about shielding the internal invocations of make from
> environmental factors like user settings of MAKEFLAGS and GNUMAKEFLAGS
> etc.
> 
> Indeed I tried "make check -j" and got no failures.
> 
> Based on the diffs it appears make was able to find files like "foo"
> and "bar" when it didn't expect them to exist.

Ahhh, then it was probably because I started with `make check`,
and when I saw it was lasting more than a couple of seconds, I
killed (^C) it and rerun with -j.

>  I'm not really sure how
> that would happen but if you can figure it out I would be interested to
> know.

I can reproduce it by running `make check`, interrupting it
at this specific point, and then running again `make check`
(no -j needed):

[...]
features/mult_targets ... ok (2 passed)
features/order_only . ok (10 passed)
features/output-sync  ^Cmake[2]: *** 
[Makefile:1550: check-regression] Interrupt
make[1]: *** [Makefile:1283: check-am] Interrupt
make: *** [Makefile:985: check-recursive] Interrupt


Maybe other interruption points also reproduce it; some others
don't.


>  If you run:
> 
>   cd tests
>   ./run_make_tests -make ../make features/escape
> 
> does it fail?

Nope.  And not with some other tests I tried.

Cheers,
Alex

-- 

GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5


OpenPGP_signature
Description: OpenPGP digital signature

Re: `make check -j` fails when building GNU Make from source

[Paul Smith]

On Sun, 2023-04-02 at 16:13 +0200, Alejandro Colomar wrote:
> I can reproduce it by running `make check`, interrupting it
> at this specific point, and then running again `make check`
> (no -j needed):

This is a known limitation with the test suite.

[bug #63981] suppress "-jN forced in submake" warning with -j1

[Paul D. Smith]

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

I made this change because of the manual although I'm not exactly sure it's
the best idea.

Note that there are better ways to force a makefile to be not parallel; for
example you can use:


all:
$(MAKE) --eval '.NOTPARALLEL:' -f one.mk


which should be enough and is (IMO) clearer.


___

Reply to this item at:

  

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

Re: `make check -j` fails when building GNU Make from source

[Alejandro Colomar]

On 4/2/23 16:15, Paul Smith wrote:
> On Sun, 2023-04-02 at 16:13 +0200, Alejandro Colomar wrote:
>> I can reproduce it by running `make check`, interrupting it
>> at this specific point, and then running again `make check`
>> (no -j needed):
> 
> This is a known limitation with the test suite.

I wonder if you could use the Makefile to run the tests, rather
than calling a script from a .PHONY target that runs them all the
time.  Why not run them only once?  You can touch empty files
when a test succeeds to make make(1) happy (I usually call them
*.touch files).


-- 

GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5


OpenPGP_signature
Description: OpenPGP digital signature

[bug #63981] suppress "-jN forced in submake" warning with -j1

[Paul D. Smith]

Update of bug #63981 (project make):

  Status:None => Fixed  
 Assigned to:None => psmith 
 Open/Closed:Open => Closed 
   Component Version:None => 4.4.1  
Operating System:None => Any
   Fixed Release:None => SCM
   Triage Status:None => Small Effort   


___

Reply to this item at:

  

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

[bug #63856] .WAIT does not work as special target on command line.

[Paul D. Smith]

Update of bug #63856 (project make):

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

___

Follow-up Comment #3:

This is great, thanks Dmitry!


___

Reply to this item at:

  

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

[bug #63990] Fix a buffer overflow in warning.c.

[Dmitry Goncharov]

URL:
  

 Summary: Fix a buffer overflow in warning.c.
   Group: make
   Submitter: dgoncharov
   Submitted: Sun 02 Apr 2023 06:38:21 PM UTC
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: SCM
Operating System: Any
   Fixed Release: None
   Triage Status: None


___

Follow-up Comments:


---
Date: Sun 02 Apr 2023 06:38:21 PM UTC By: Dmitry Goncharov 
.







___

Reply to this item at:

  

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

[bug #63990] Fix a buffer overflow in warning.c.

[Dmitry Goncharov]

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

File name: sv63990.fixSize:1 KB




___

Reply to this item at:

  

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

[bug #63990] Fix a buffer overflow in warning.c.

[Dmitry Goncharov]

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

Settings like .WARNINGS = bogus causes decode_warn_name to return wt_max.
decode_warn_actions then stores wt_max in type and the action at
data->actions[type] and touches beyond the size of data->actions.


___

Reply to this item at:

  

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

[bug #63990] Fix a buffer overflow in warning.c.

[Dmitry Goncharov]

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

There is already a test which tests this use case.


___

Reply to this item at:

  

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