[bug #65739] Add warnings circular-dep and circular-extra-dep.

Follow-up Comment #3, bug #65739 (group make): I applied the first patch (with a few tweaks). Thanks! Let's discuss the second patch in bug #60736 instead ___ Reply to this item at:

[bug #65739] Add warnings circular-dep and circular-extra-dep.

Follow-up Comment #2, bug #65739 (group make): Here is an example $ cat makefile hello: hello $ make make: circular hello <- hello dependency dropped make: Nothing to be done for 'hello'. $ make --warn=circular-dep:ignore make: Nothing to be done for 'hello'. $ make --warn=circular-dep:error

[bug #65739] Add warnings circular-dep and circular-extra-dep.

Additional Item Attachment, bug #65739 (group make): File name: sv65739_circular_dep_warn_part1.diff Size: 6KiB File name: sv65739_circular_dep_warn_part2.diff Size: 6KiB

[bug #65739] Add warnings circular-dep and circular-extra-dep.

Follow-up Comment #1, bug #65739 (group make): Patch sv65739_circular_dep_warn_part1.diff adds warning circular-dep. This warning controls how makes handles circular dependencies. The behavior is to silently drop the dependency, print a message or print a message and exit with an error code. The

[bug #65739] Add warnings circular-dep and circular-extra-dep.

URL: <https://savannah.gnu.org/bugs/?65739> Summary: Add warnings circular-dep and circular-extra-dep. Group: make Submitter: dgoncharov Submitted: Tue 14 May 2024 01:40:55 AM UTC Severity: 3 -

Fix gcc SIZE_MAX redefined warnings.

When compiling GNU Make from git master I get warnings that SIZE_MAX is redefined. This patch fixes it. This macro is defined by glibc in stdint.h/inttypes.h but src/makeint.h checks for it after including limits.h. I've just placed these headers under limits.h before any *_MIN, *_MAX, etc

Re: Warnings on '$\\'

On Mon, Apr 17, 2023 at 3:39 PM Alejandro Colomar wrote: > Dmitry, why did $\\ work for you ($\ being my $(empty)), and not for me > (as $(empty)\)? ¿Cómo estás, Alex? When make parses a definition, first it performs line continuation business, then expands macros. In the case of $(empty)\,

Re: Warnings on '$\\'

Hi Dmitry, I've written some test to see what works and what doesn't: $ cat Makefile foo.h: FORCE $(file > $@,$(foo)) @: single:=\ double:=\\ empty:= space:= # define foo Aa \\ Ba \$(single) Bb \$(single)\ Bc $(single)\ Bd $(single)$(single) Ca \$(double) Cb \$(double)\ Cc

Re: Warnings on '$\\'

Dmitry Goncharov wrote: There are various techniques. example 1, define the variable \:= This was simple and elegant. Worked w/o any warnings. Thanks!

Re: Warnings on '$\\'

On Fri, Apr 14, 2023 at 5:38 AM Gisle Vanem wrote: > But with 'MAKEFLAGS += --warn-undefined-variables', I get a > bunch of warnings: >'reference to undefined variable '\'' > > How can I avoid that? There are various techniques. example 1, define the variable \:= define tra

Re: Warnings on '$\\'

Martin Dorey wrote: This seems to work: martind@sirius:~/tmp/vanem-2023-04-14$ cat Makefile g_trace.h: Makefile; $(file > $@,$(trace_h)) \ = \ define trace_h   #define G_TRACE(level, fmt, ...)                  $\\           do {                                      $\\             if

Re: Warnings on '$\\'

g-make Subject: Warnings on '$\\' * EXTERNAL EMAIL * In a makefile I have the need to generate a multi-line C-macro (for use in Glib): g_trace.h: Makefile $(file > $@,$(trace_h)) define trace_h #define G_TRACE(level, fmt, ...)

Warnings on '$\\'

vel() >= level) {$\\ _g_trace_color (TRACE_COLOUR_START); $\\ # endef Without the '$\\' syntax, I get everything on one line which I'd rather not want. With the '$\\' endings, g_trace.h is perfect. But with 'MAKEFLAGS += --warn-undefined-variables', I get a bunch of wa

The --warn / .WARNINGS feature

I pushed my changes to implement the --warn / .WARNINGS feature. I hope people find them useful. As of now there are only 3 possible warnings, but I will be looking through other warnings that might be useful to control. There is one major caveat to this: currently it's not possible to set

[bug #63686] implement a flag to promote make warnings to fatal errors

ge Status:None => Medium Effort ___ Follow-up Comment #14: I implemented both the --warn option and .WARNINGS variable. ___ Reply to this item a

[bug #63686] implement a flag to promote make warnings to fatal errors

Follow-up Comment #13, bug #63686 (project make): Hmm, this is a dizzying array of choices! Since 4.4.1 is gone and this feature will only be in the next full release which is presumably far off still, it seems there's no rush to decide. Maybe push it as is to let people play with it in beta

[bug #63686] implement a flag to promote make warnings to fatal errors

n effect. Is it possible to imagine a scenario where a particular warning must be tolerated while we still want "error" behavior in general? Demoing with the special target syntax: .WARNINGS: ignore .WARNINGS: error > There is an argument to be made that requiring every individual make

[bug #63686] implement a flag to promote make warnings to fatal errors

Follow-up Comment #12, bug #63686 (project make): > Paul, if you decide to do the special target, do you intend to let that special target have prerequisites, e.g. targets for which the feature is enabled? No, the prerequisites of the special target are the warning control options: .WARNI

[bug #63686] implement a flag to promote make warnings to fatal errors

Follow-up Comment #11, bug #63686 (project make): Paul, if you decide to do the special target, do you intend to let that special target have prerequisites, e.g. targets for which the feature is enabled? ___ Reply to this item at:

[bug #63686] implement a flag to promote make warnings to fatal errors

, you could miss warnings. ___ Reply to this item at: <https://savannah.gnu.org/bugs/?63686> ___ Message sent via Savannah https://savannah.gnu.org/

[bug #63686] implement a flag to promote make warnings to fatal errors

Follow-up Comment #8, bug #63686 (project make): I'm just trying to be clear about what is available, and the tradeoffs. Maybe some of these are not interesting to consider. There is an argument to be made that requiring every individual makefile to include its own .WARNINGS: special target

[bug #63686] implement a flag to promote make warnings to fatal errors

Follow-up Comment #7, bug #63686 (project make): It almost sounds like you're making the case against your own proposal now :-). Given what you say, what's the reasoning for doing this as a --warn... flag vs a special target? I trust your judgment but I don't quite understand it.

[bug #63686] implement a flag to promote make warnings to fatal errors

Follow-up Comment #5, bug #63686 (project make): Sorry, previous comment should read "I cannot think of an reason to prefer ...". ___ Reply to this item at:

[bug #63686] implement a flag to promote make warnings to fatal errors

Update of bug #63686 (project make): Fixed Release:None => SCM ___ Follow-up Comment #3: I have implemented a comprehensive method of controlling warnings in general, including sett

[bug #63686] implement a flag to promote make warnings to fatal errors

Update of bug #63686 (project make): Component Version: 4.4.1 => 4.0 ___ Reply to this item at: ___

[bug #63686] implement a flag to promote make warnings to fatal errors

Follow-up Comment #2, bug #63686 (project make): [comment #0 original submission:] > GCC has a -Werror option causing warnings to be promoted to fatal errors which I (and my organization) find very useful. As a matter of policy we always build with -Werror on and while this, obviously, is pain

[bug #63686] implement a flag to promote make warnings to fatal errors

Follow-up Comment #1, bug #63686 (project make): If this was going to be implemented, I suggest doing it as a special target e.g. .WERROR: which would allow maximum flexibility. A proprietary build system could embed this in their makefiles, and for open-source projects or other cases where it

[bug #63686] implement a flag to promote make warnings to fatal errors

URL: <https://savannah.gnu.org/bugs/?63686> Summary: implement a flag to promote make warnings to fatal errors Project: make Submitter: boyski Submitted: Fri 20 Jan 2023 09:12:57 PM UTC Severity: 3 -

Re: GNU make 4.3.90 release candidate available: Compiler warnings on macOS

Am 20.09.22 um 20:36 schrieb Paul Smith: > A new release candidate for GNU make 4.4 is available now for download: > > 0c3daaec8c81bf72f460677ccda32364 make-4.3.90.tar.lz > 54726144a7ae0465451f8ca0740f3d1f make-4.3.90.tar.gz On macOS, compiling "glob.c" gives the

Re: Warnings when running "bootstrap"

On Mon, 2022-09-05 at 00:16 +, Bjarni Ingi Gislason via Bug reports and discussion for GNU make wrote: >   The compilation failed because I had an unclean git repository. > >   My compilation creates a lot of warnings, which could be reduced if > the header files were fixed

Re: Warnings when running "bootstrap"

The compilation failed because I had an unclean git repository. My compilation creates a lot of warnings, which could be reduced if the header files were fixed 131 [-Walloca] 7 [-Wformat=] 5 [-Wformat-nonliteral] 3 [-Wimplicit-fallthrough=] 2 [-Wmaybe

Re: Warnings when running "bootstrap"

On Sun, 2022-09-04 at 01:54 +, Bjarni Ingi Gislason via Bug reports and discussion for GNU make wrote: >   This causes failure when compiling. What is the failure? I don't get any failures. I do see the output here, but they are are just notes / warnings. Everything still works. If

Warnings when running "bootstrap"

This causes failure when compiling. Using bootstrap 2022-07-24.15 Using latest gnulib (Sep 04 2022 01:40 UTC) autoconf (GNU Autoconf) 2.71 automake (GNU automake) 1.16.5 Parts of output: [...] Notice from module fdl: Don't use this module! Instead, copy the referenced license file

[bug #56895] Cannot build make due to compiler warnings/failures

Follow-up Comment #4, bug #56895 (project make): Excellent, I will check it out (literally). Thank you! ___ Reply to this item at: ___ Message sent

[bug #56895] Cannot build make due to compiler warnings/failures

Update of bug #56895 (project make): Status:None => Fixed Assigned to:None => psmith Open/Closed:Open => Closed Fixed Release:

Re: [bug #56895] Cannot build make due to compiler warnings/failures

Ah, ok, I had assumed the fallthrough was intentional. Looks like the warning found a real bug. As far as the other changes go, dealing with them some other way would be great. I just needed to be able to compile the code. --- David A.Wheeler___

[bug #56895] Cannot build make due to compiler warnings/failures

Follow-up Comment #2, bug #56895 (project make): I think the fall through in read.c is incorrect. I think this code is broken when HAVE_DOS_PATHS is set. I can't see any justification for falling through into the variable case if we find a ":" in a drive spec. If we detect a ":" in a drive

[bug #56895] Cannot build make due to compiler warnings/failures

Follow-up Comment #1, bug #56895 (project make): The failure for find_in_given_path() is because one version of that function was pushed to gnulib, then I pushed my changes to use it to GNU make, then another version of that function with a different calling signature was pushed to gnulib so if

[bug #56895] Cannot build make due to compiler warnings/failures

Additional Item Attachment, bug #56895 (project make): File name: ,trivial-compile-fixes Size:2 KB ___ Reply to this item at:

[bug #56895] Cannot build make due to compiler warnings/failures

URL: <https://savannah.gnu.org/bugs/?56895> Summary: Cannot build make due to compiler warnings/failures Project: make Submitted by: dwheeler Submitted on: Sun 15 Sep 2019 03:32:15 AM UTC Severity: 3 -

Re: Idea: MAKE_SILENCEWARNINGS variable silences make warnings

Wouldn't it be safer to disable specific warnings for specific target(s), or specific sections of a makefile? On Tue, 11 Jun 2019 at 19:42, Paul Smith wrote: > On Tue, 2019-06-11 at 14:37 -0400, David A. Wheeler wrote: > > Create a new make special variable "MAKE_SILENCEWARNING

Idea: MAKE_SILENCEWARNINGS variable silences make warnings

Problem: Make warnings are generally useful, but in special cases they can be spurious. It'd be nice to be able to control them. Solution: Create a new make special variable "MAKE_SILENCEWARNINGS". By default it is not set (empty). If it's non-empty (true), then make does not

Re: Idea: MAKE_SILENCEWARNINGS variable silences make warnings

-W... options, allowing -Wno-... to disable them, and also a -Werror / -Wno-error option to turn them into fatal errors instead of warnings. I was just thinking to use MAKEFLAGS += -W... rather than creating a new variable. However maybe there are reasons that's less desirable (passing these options

RE: [PATCH] Silence some compiler warnings

Great, thanks. They both seem to be fixed in gnulib. From: Paul Smith Sent: 31 May 2016 16:23 To: Luke Allardyce; bug-make@gnu.org Subject: Re: [PATCH] Silence some compiler warnings On Tue, 2016-05-31 at 11:14 +0900, Luke Allardyce wrote: > GCC complains about unused parameters and an ambigu

Re: [PATCH] Silence some compiler warnings

files. For the next non-patch release I'll look into updating to newer versions of gnulib etc. code which will hopefully fix some of these warnings. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make

Re: include warnings vs -include ignore errors

On Wed, 2016-05-25 at 09:19 -0700, Raymond Dubler wrote: > What I need is: >   1. no warning that blah.d is missing >   2. same functionality as include blah.d, ie display error and > terminate of failure > > Unless I am missing something in the manual, this is not provided with > make. > > What

include warnings vs -include ignore errors

functionality as include blah.d, ie display error and terminate of failure Unless I am missing something in the manual, this is not provided with make. What are my options here? -- View this message in context: http://gnu-make.2324884.n4.nabble.com/include-warnings-vs-include-ignore-errors-tp17136.html

Re: mingw-w64 build breaks and warnings

On Mon, 2013-11-25 at 19:39 -0800, Stephan T. Lavavej wrote: #1: OSN (fatal, NILF, ^ Fixed, thanks. #2: w32err.c: In function 'map_windows32_error_to_string': w32err.c:70:3: warning: passing argument 2 of 'fatal' makes integer from pointer without a cast [enabled by

Re: mingw-w64 build breaks and warnings

On Tue, 2013-11-26 at 12:21 +, Ray Donnelly wrote: Instead of adding the MS-specific %Ix, could you not add (in the batch file) the define of __MINGW_USE_ANSI_STDIO=1, otherwise I suspect you'd be breaking people who prefer the stdio a bit more ansi (mingw-builds for example). I went with

RE: mingw-w64 build breaks and warnings

[Paul Smith] Fixed, thanks. Awesome - I've verified that a4937bc successfully builds and runs for mingw-w64, emitting only the innocuous warnings. Now I don't need local patches, yay! I didn't change anything for this one. I'll look at it later. Note that all of the stuff is unused

Re: mingw-w64 build breaks and warnings

wrote: Hi, make's HEAD is currently broken for mingw-w64, and is also emitting several warnings. I'm building http://git.savannah.gnu.org/cgit/make.git/commit/?id=f5f5adb with build_w32.bat gcc. The attached make-mingw-w64.patch fixes all errors and warnings, and shouldn't affect other

Re: mingw-w64 build breaks and warnings

Date: Tue, 26 Nov 2013 12:21:10 + From: Ray Donnelly mingw.andr...@gmail.com Cc: bug-make@gnu.org Instead of adding the MS-specific %Ix, could you not add (in the batch file) the define of __MINGW_USE_ANSI_STDIO=1, otherwise I suspect you'd be breaking people who prefer the stdio a bit

RE: mingw-w64 build breaks and warnings

for how the errors and warnings are fixed - I would just like to be able to build make without local patches. Thanks, STL ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make

mingw-w64 build breaks and warnings

Hi, make's HEAD is currently broken for mingw-w64, and is also emitting several warnings. I'm building http://git.savannah.gnu.org/cgit/make.git/commit/?id=f5f5adb with build_w32.bat gcc. The attached make-mingw-w64.patch fixes all errors and warnings, and shouldn't affect other platforms

Suspicious compiler warnings

FYI: when compiling git head of a few days ago, I see several warnings. They are mostly harmless, but these two look real, especially the first one: implicit.c: In function 'pattern_search': implicit.c:225:15: warning: variable 'deps' set but not used [-Wunused-but-set-variable] job.c

[bug #30517] Enable the user to ignore clock skew warnings partly/completely

URL: http://savannah.gnu.org/bugs/?30517 Summary: Enable the user to ignore clock skew warnings partly/completely Project: make Submitted by: ken1 Submitted on: Thu 22 Jul 2010 09:03:54 AM GMT Severity: 3 - Normal

Re: Build warnings in CVS make 3.81.90

Hi, Paul Smith wrote on 11/05/07 20:15: On Sat, 2007-04-28 at 15:26 +0100, Jon Grant wrote: A wider query relating to these warnings is that since make 3.81 is released now, could we change make to use const's instead of #define'd values, and inline functions instead of #define macro

Re: Build warnings in CVS make 3.81.90

From: Paul Smith [EMAIL PROTECTED] Date: Fri, 11 May 2007 15:15:34 -0400 Cc: GNU Make bug-make@gnu.org function.c: In function 'func_shell': function.c:1597: warning: variable 'error_prefix' might be clobbered by 'longjmp' or 'vfork' function.c:1589: warning: argument 'o' might be

Re: Build warnings in CVS make 3.81.90

On Sat, 2007-04-28 at 15:26 +0100, Jon Grant wrote: A wider query relating to these warnings is that since make 3.81 is released now, could we change make to use const's instead of #define'd values, and inline functions instead of #define macro expressions? No... well, at least not inline

Build warnings in CVS make 3.81.90

Hello, I noticed a few build warnings in CVS at present. Difficult to spot a lot of the causes as there are many pre-processor macros in use. A wider query relating to these warnings is that since make 3.81 is released now, could we change make to use const's instead of #define'd values

[bug #13479] Compile errors and warnings - Microsoft compiler 13.10 (.NET 7.1)

to fix up the ports (Windows/Amiga/VMS/etc.) As a part of that work, or separately, you can send in fixes for these types of warnings or else file new bugs about them. ___ Reply to this item at: http://savannah.gnu.org/bugs/?func

[bug #13479] Compile errors and warnings - Microsoft compiler 13.10 (.NET 7.1)

Follow-up Comment #4, bug #13479 (project make): Paul, can we close this one also? The strerror bug is fixed and there's no point to have an old compile report active. My intent was merely to give you a chance to clean up the code from all this warnings. The majority is of type casting warnings

compile-time warnings on Solaris 8 64-bit sparc (gcc 4.1.0)

Hey, congratulations on the new version! On Solaris 8 (sparc) with GCC 4.1.0 installed, I built GNU make 3.81 as follows: ./configure --prefix=/r/share1/src/make CC='gcc -m64' make and got some worrisome warnings as shown below. Spot-checking some of the generated machine code, it appears

Re: compile-time warnings on Solaris 8 64-bit sparc (gcc 4.1.0)

another concern: many implementations have unreliable 'alloca' implementations, that can result in unchecked buffer overruns when you allocate buffers that are too large. This is partly why I was concerned about those warnings. The gnulib allocsa module attempts to address this problem; I'm

[bug #16170] make 3.81rc2: compile warnings on AIX

URL: http://savannah.gnu.org/bugs/?func=detailitemitem_id=16170 Summary: make 3.81rc2: compile warnings on AIX Project: make Submitted by: afrink Submitted on: Do 23.03.2006 um 12:37 Severity: 3 - Normal

[bug #16170] make 3.81rc2: compile warnings on AIX

Update of bug #16170 (project make): Status:None = Fixed Assigned to:None = psmith Open/Closed:Open = Closed Fixed Release:

Re: Latest CVS make compile warnings fix

On 24/07/05 18:04, Paul D. Smith wrote: %% J. Grant [EMAIL PROTECTED] writes: jg Perhaps there could be a way to force setting of config.h macro's jg for those circumstances. I was thinking of something like that too. I have to go back and examine that code again deeply enough to

Re: Latest CVS make compile warnings fix

%% J. Grant [EMAIL PROTECTED] writes: jg It it would not do any harm, perhaps we could consider filling in jg the missing entries with 0? I've already done this; the change was checked in a week or two ago. Cheers! --

Re: Latest CVS make compile warnings fix

%% J. Grant [EMAIL PROTECTED] writes: jg Perhaps there could be a way to force setting of config.h macro's jg for those circumstances. I was thinking of something like that too. I have to go back and examine that code again deeply enough to understand it: I can't remember enough about the

Re: Latest CVS make compile warnings fix

Hi Paul, [...] jg I expect those macros were intended to be used with signed values, jg and now they are being used with unsigned values as well, which is jg bad. No, I don't think so. I don't remember the details but my recollection is that they were specifically designed to work with

Re: Latest CVS make compile warnings fix

Hi Paul, [...] jg main.c:420: warning: missing initializer jg main.c:420: warning: (near initialization for `switches[30].type') This one, IMO, could be a bug in GCC. As far as I can tell the initializer is correct. The only way to avoid the warning seems to be to put a full suite of 0

Re: Latest CVS make compile warnings fix

%% J. Grant [EMAIL PROTECTED] writes: jg Ulrich Drepper's recent Dictatorship of the Minorities springs jg to mind: jg http://www.livejournal.com/users/udrepper/7326.html Heh. Since one of Ulrich's main points is we shouldn't bother supporting Windows I'm not sure you want to bring this

Re: Latest CVS make compile warnings fix

%% J. Grant [EMAIL PROTECTED] writes: jg If I submit fixes for these would they be reviewed for inclusion ? I'm happy to look at them, but they will not be easy to fix. jg main.c:420: warning: missing initializer jg main.c:420: warning: (near initialization for `switches[30].type') This

Re: Latest CVS make compile warnings fix

Hi Paul, [...] jg If I submit fixes for these would they be reviewed for inclusion ? I'm happy to look at them, but they will not be easy to fix. I'm happy to assist if needed. I hope the 3.81 release can have as few warnings as possible. jg main.c:420: warning: missing initializer

Re: Latest CVS make compile warnings fix

that was that the code the warnings warned about were essential to the way the macros worked. jg I did cvs update -d after your last commit, and also just now. My jg code still gives me that warning. I am using gcc (GCC) 3.3.5 jg (Debian 1:3.3.5-8) on on an i586. Huh. Oh, I see; it only

Re: a question to warnings from make

%% Helmut Dipper [EMAIL PROTECTED] writes: hd What can I do to avoid those warnings? You need to synchronize your clocks better. hd The clocks of both machines are synchronized daily with a hd difference lower than one minute. One minute is a _huge_ amount of time, to make. You need