[bug #61885] How do I contribute to make? The submit new Patch link is crossed out?

[igor.todorovski]

URL:
  

 Summary: How do I contribute to make?  The submit new Patch
link is crossed out?
 Project: make
Submitted by: igortodorovski
Submitted on: Thu 20 Jan 2022 11:01:37 PM UTC
Severity: 3 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: None
Operating System: None
   Fixed Release: None
   Triage Status: None

___

Details:

How do I contribute to make?  The submit new Patch link is crossed out? 

We want to make contributions for z/OS.




___

Reply to this item at:

  

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

[bug #61885] How do I contribute to make? The submit new Patch link is crossed out?

[Paul D. Smith]

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

It got too confusing to have multiple places for people to be supplying
changes so I reduced them down to one: the bug tracker, and turned off the
other features like patches.

If you have changes you'd like to see please create patches and either (a)
email them (as attachments) to the bug-make@gnu.org mailing list, or (b)
attach them to a Savannah bug (like this one).  Don't do both as items filed
in Savannah are automatically forwarded to the mailing list as well.

There is no CI/CD pipeline for GNU projects that I know of, although it would
be nice to have one.

___

Reply to this item at:

  

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

Re: $(info xxx) output interleaved with other $(info) output

[Dmitry Goncharov]

On Thu, Jan 20, 2022 at 5:41 PM Paul Eggert  wrote:
> I suggested working around the problem in the GNU Emacs Makefiles by
> installing the attached patch. It's a bit of a hack but I couldn't think
> of anything better, other than outputting the information with the shell
> rather than with $(info).

Will $(warning) suit your needs?

regards, Dmitry

[bug #61885] How do I contribute to make? The submit new Patch link is crossed out?

[igor.todorovski]

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

Also, is there a CI/CD pipeline for regression testing and if so, how does one
add their own machine to it?

___

Reply to this item at:

  

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

Re: $(info xxx) output interleaved with other $(info) output

[Paul Eggert]

On 1/19/22 23:11, Paul Smith wrote:

I rewrote this function and applied this change:


Oh, that's much nicer than what I sent! Thanks.

I suggested working around the problem in the GNU Emacs Makefiles by 
installing the attached patch. It's a bit of a hack but I couldn't think 
of anything better, other than outputting the information with the shell 
rather than with $(info). I'm mentioning this here in case anyone else 
needs a workaround for current and older GNU Make.From 153f3d9af2b3d021d9ba8eb17d979c772a7c09cd Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Thu, 20 Jan 2022 10:11:39 -0800
Subject: [PATCH] Work around GNU Make $(info) bug

Problem reported by Lars Ingebrigtsen (Bug#53358).
* src/verbose.mk.in (newline, info-trailing-newline): New macros.
(AM_V_AR, AM_V_CC, AM_V_CXX, AM_V_CCLD, AM_V_CXXLD, AM_V_ELC)
(AM_V_ELN, AM_V_GEN, AM_V_RC): Use them.
---
 src/verbose.mk.in | 42 +++---
 1 file changed, 31 insertions(+), 11 deletions(-)

diff --git a/src/verbose.mk.in b/src/verbose.mk.in
index e3f5678303..4a3bbcb9de 100644
--- a/src/verbose.mk.in
+++ b/src/verbose.mk.in
@@ -17,6 +17,26 @@
 ## You should have received a copy of the GNU General Public License
 ## along with GNU Emacs.  If not, see .
 
+# Use two empty lines to define a macro containing a newline.
+define newline
+
+
+endef
+
+# Work around a bug in GNU Make 4.3 and earlier, which implements $(info MSG)
+# via two system calls { write (..., "MSG", 3); write (..., "\n", 1); }
+# which looks bad when make -j interleaves two of these at about the same time.
+# Later versions of GNU Make have the 'notintermediate' feature,
+# so assume that $(info ...) has the bug if this feature is absent.
+# The workaround arranges for 'MSG' itself to end in newline;
+# although this follows every message by an empty line,
+# that's better than the interleaved output.
+ifeq (,$(filter notintermediate,$(value .FEATURES)))
+info-trailing-newline = $(newline)
+else
+info-trailing-newline =
+endif
+
 # 'make' verbosity.
 V = @AM_DEFAULT_VERBOSITY@
 ifeq (${V},1)
@@ -33,26 +53,26 @@ AM_V_GLOBALS =
 AM_V_NO_PD =
 AM_V_RC =
 else
-AM_V_AR  = @$(info $   AR   $@)
+AM_V_AR  = @$(info $   AR   $@$(info-trailing-newline))
 AM_V_at = @
-AM_V_CC  = @$(info $   CC   $@)
-AM_V_CXX = @$(info $   CXX  $@)
-AM_V_CCLD= @$(info $   CCLD $@)
-AM_V_CXXLD   = @$(info $   CXXLD$@)
+AM_V_CC  = @$(info $   CC   $@$(info-trailing-newline))
+AM_V_CXX = @$(info $   CXX  $@$(info-trailing-newline))
+AM_V_CCLD= @$(info $   CCLD $@$(info-trailing-newline))
+AM_V_CXXLD   = @$(info $   CXXLD$@$(info-trailing-newline))
 ifeq ($(HAVE_NATIVE_COMP),yes)
 ifeq ($(NATIVE_DISABLED),1)
-AM_V_ELC = @$(info $   ELC  $@)
+AM_V_ELC = @$(info $   ELC  $@$(info-trailing-newline))
 AM_V_ELN =
 else
-AM_V_ELC = @$(info $   ELC+ELN  $@)
-AM_V_ELN = @$(info $   ELN  $@)
+AM_V_ELC = @$(info $   ELC+ELN  $@$(info-trailing-newline))
+AM_V_ELN = @$(info $   ELN  $@$(info-trailing-newline))
 endif
 else
-AM_V_ELC = @$(info $   ELC  $@)
+AM_V_ELC = @$(info $   ELC  $@$(info-trailing-newline))
 AM_V_ELN =
 endif
-AM_V_GEN = @$(info $   GEN  $@)
+AM_V_GEN = @$(info $   GEN  $@$(info-trailing-newline))
 AM_V_GLOBALS = @$(info $   GEN  globals.h)
 AM_V_NO_PD = --no-print-directory
-AM_V_RC  = @$(info $   RC   $@)
+AM_V_RC  = @$(info $   RC   $@$(info-trailing-newline))
 endif
-- 
2.32.0

[bug #48643] Irrelevant targets can confuse make on which pattern rule to select.

[Dmitry Goncharov]

Follow-up Comment #35, bug #48643 (project make):

> Do you mean that if I apply the test patch mentioned there, some of those
tests would fail?

All tests should pass.
in the case of example 6 make fails to set pat->is_explicit for 'hello.x'.
This used to fail example 6 until commit 6682fb. My concern is that
pat->is_explicit still has incorrect value and that will manifest itself
someday.



> Regarding your question in comment #33, the current behavior is correct.

glad to hear that.

___

Reply to this item at:

  

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

[bug #48643] Irrelevant targets can confuse make on which pattern rule to select.

[Paul D. Smith]

Follow-up Comment #34, bug #48643 (project make):

I didn't fully grasp the impact of the issue you raised in comment #31.  Do
you mean that if I apply the test patch mentioned there, some of those tests
would fail?  I will try to look at this more this evening.

Regarding your question in comment #33, the current behavior is correct.  It
has always been the case that any mention of a target in the makefile is
sufficient to remove the "intermediate-ness" of a file.  In fact, this is a
very common, and very often recommended, way to remove intermediate status of
a file; we suggest adding a separate target like:


build-intermediates: 


and even if that target is never invoked, it's sufficient to mark those
targets as "mentioned in" the makefile and thus remove their intermediate
status.

Changing this would break a lot of things.

___

Reply to this item at:

  

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

[bug #48643] Irrelevant targets can confuse make on which pattern rule to select.

[Dmitry Goncharov]

Follow-up Comment #33, bug #48643 (project make):

This fix turned out to be difficult. i'll be surprised if we don't miss
anything.

i wanted to bring to your attention a couple of leftovers.
One is that pat->is_explicit that is described in update 31.

For the other let's consider example 8.


all: hello.tsk
%.tsk: %.o; touch $@
%.o: %.c; $(info $@)
#unrelated: hello.o


Here, 'hello.o' is intermediate and 'hello.o' and 'hello.tsk' are not rebuild
when 'hello.o' is missing.
If we uncomment rule 'unrelated: hello.o', then 'hello.o' is explicit and
'hello.o' and 'hello.tsk' are rebuild when 'hello.o' is missing.

So, even though rule 'unrelated: hello.o' is unrelated and no longer
participates in overload resolution, presence of this rule affects make's
behavior.

The tests in sv48643_exp_preqreq_is_not_interm_tests.diff all test that such
prerequisite explicitly mentioned on an unrelated rule is not intermediate.
i'd like to solicit your opinion on this.


___

Reply to this item at:

  

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