[bug #65448] $(intcmp) problems with negative integers

Update of bug #65448 (group make): Status:None => Fixed Assigned to:None => psmith Open/Closed:Open => Closed Operating System:

[bug #65448] $(intcmp) problems with negative integers

Follow-up Comment #1, bug #65448 (group make): Indeed, it seems we currently compare magnitudes instead of values. I've attached a fix and regression tests. (file #55826) ___ Additional Item Attachment: File name: 0001-SV-65448-Compare-va

[bug #65448] $(intcmp) problems with negative integers

URL: <https://savannah.gnu.org/bugs/?65448> Summary: $(intcmp) problems with negative integers Group: make Submitter: bobbogo Submitted: Mon 11 Mar 2024 02:23:24 PM UTC Severity: 3 - Normal

Re: Regression on Cygwin: Problems with parallel make in 4.4

th seem to have problems emulating POSIX-style FIFOs. Did that change not work for you, or did you by-hand force the jobserver to use FIFOs for these tests? We forced it to use FIFOs by configuring with -DJOBSERVER_USE_FIFO=1. Ken

Re: Regression on Cygwin: Problems with parallel make in 4.4

> problem. > > Never mind.  My speculation is leading nowhere.  I just had 5 > successful builds followed by a hang in the 6th attempt.  I guess I > just have to continue using a pipe for my TeX Live builds. The latest release (GNU Make 4.4.1) uses pipes for jobserver on both Cyg

Re: Regression on Cygwin: Problems with parallel make in 4.4

On 3/11/2023 12:51 PM, Ken Brown wrote: Update: The hang occurred again.  It appears to be caused by an infinite loop starting with a call to pselect[*]. [...] If I'm right, the solution would seem to be to disable the use of pselect on Cygwin when the jobserver is using a fifo.  I'll try tha

Re: Regression on Cygwin: Problems with parallel make in 4.4

On 3/2/2023 5:39 PM, Ken Brown wrote: I'm returning to this thread because a surprising thing happened.  I decided to try to debug the fifo problem I reported at the beginning of the thread (a hang building TeX Live on Cygwin when the jobserver used a fifo).  So I installed make 4.4.1 built wit

Re: Regression on Cygwin: Problems with parallel make in 4.4

I'm returning to this thread because a surprising thing happened. I decided to try to debug the fifo problem I reported at the beginning of the thread (a hang building TeX Live on Cygwin when the jobserver used a fifo). So I installed make 4.4.1 built with fifos enabled (by setting CPPFLAGS=-

Re: Regression on Cygwin: Problems with parallel make in 4.4

On 2/24/2023 11:29 AM, Paul Smith wrote: On Thu, 2023-02-23 at 16:17 -0500, Ken Brown wrote: Sorry, I spoke too soon.  I just went back to my original use case, in which I used the TeX Live "Build" script instead of directly invoking make, and I again got the jobserver warning. Thanks for the

Re: Regression on Cygwin: Problems with parallel make in 4.4

On Thu, 2023-02-23 at 16:17 -0500, Ken Brown wrote: > Sorry, I spoke too soon.  I just went back to my original use case, > in which I used the TeX Live "Build" script instead of directly > invoking make, and I again got the jobserver warning. Thanks for the info. TL;DR: this is not an error in m

Re: Regression on Cygwin: Problems with parallel make in 4.4

On 2/24/2023 9:54 AM, Paul Smith wrote: On Thu, 2023-02-23 at 16:17 -0500, Ken Brown wrote: I'm attaching that script so you can see exactly how "make" is invoked in a subshell.  I'm also attaching my build log up to the point of the warning and the Makefile in the ft-build directory in which th

Re: Regression on Cygwin: Problems with parallel make in 4.4

On Thu, 2023-02-23 at 16:17 -0500, Ken Brown wrote: > I'm attaching that script so you can see exactly how "make" is > invoked in a subshell.  I'm also attaching my build log up to the > point of the warning and the Makefile in the ft-build directory in > which the warning occurred.  I've previousl

Re: Regression on Cygwin: Problems with parallel make in 4.4

On 2/21/2023 5:59 PM, Ken Brown wrote: On 2/21/2023 1:26 PM, Paul Smith wrote: On Tue, 2023-02-21 at 13:11 -0500, Ken Brown wrote: I think you're on the right track.  I got through 'make -j13 check' without the jobserver warning. w00t!  Thanks for the help.  A full fix should be in 4.4.1 whic

Re: Regression on Cygwin: Problems with parallel make in 4.4

On 2/21/2023 1:26 PM, Paul Smith wrote: On Tue, 2023-02-21 at 13:11 -0500, Ken Brown wrote: I think you're on the right track.  I got through 'make -j13 check' without the jobserver warning. w00t! Thanks for the help. A full fix should be in 4.4.1 which I hope to release this week or weekend

Re: Regression on Cygwin: Problems with parallel make in 4.4

On Tue, 2023-02-21 at 13:11 -0500, Ken Brown wrote: > I think you're on the right track.  I got through 'make -j13 check' > without the jobserver warning. w00t! Thanks for the help. A full fix should be in 4.4.1 which I hope to release this week or weekend.

Re: Regression on Cygwin: Problems with parallel make in 4.4

On 2/21/2023 11:34 AM, Paul Smith wrote: On Tue, 2023-02-21 at 10:36 -0500, Paul Smith wrote: But, I think I might have found the bug.  If I'm right, it's a doozy! But, as you mentioned it's not widespread because it only affects pipe jobservers.  I'm glad 4.4.1 is almost ready to go.  I'll try

Re: Regression on Cygwin: Problems with parallel make in 4.4

On Tue, 2023-02-21 at 10:36 -0500, Paul Smith wrote: > But, I think I might have found the bug.  If I'm right, it's a doozy! > But, as you mentioned it's not widespread because it only affects > pipe jobservers.  I'm glad 4.4.1 is almost ready to go.  I'll try to > write a test case for it to see i

Re: Regression on Cygwin: Problems with parallel make in 4.4

On Tue, 2023-02-21 at 10:12 -0500, Ken Brown wrote: > > There will likely be a lot of output. > > Here it is. Oops I got the rule wrong for the set -x. But, I think I might have found the bug. If I'm right, it's a doozy! But, as you mentioned it's not widespread because it only affects pipe jo

Re: Regression on Cygwin: Problems with parallel make in 4.4

On 2/21/2023 9:39 AM, Paul Smith wrote: On Tue, 2023-02-21 at 08:35 -0500, Ken Brown wrote: make  check-TESTS make[4]: Entering directory '/home/kbrown/src/texlive/test.x86_64/Work/texk/kpathsea' make[5]: Entering directory '/home/kbrown/src/texlive/test.x86_64/Work/texk/kpathsea' OK, I see th

Re: Regression on Cygwin: Problems with parallel make in 4.4

On Tue, 2023-02-21 at 08:35 -0500, Ken Brown wrote: > make  check-TESTS > make[4]: Entering directory > '/home/kbrown/src/texlive/test.x86_64/Work/texk/kpathsea' > make[5]: Entering directory > '/home/kbrown/src/texlive/test.x86_64/Work/texk/kpathsea' OK, I see the rule that generates the [5] re

Re: Regression on Cygwin: Problems with parallel make in 4.4

hat there is no testing at all with "pipe", anymore. Agreed that the regression tests are not completely sufficient to find all problems. > make[5]: not recursive -2,-2 > make[5]: warning: jobserver unavailable: using -j1.  Add '+' to > parent make rule. Perfect, t

Re: Regression on Cygwin: Problems with parallel make in 4.4

On 2/21/2023 12:27 AM, Paul Smith wrote: On Mon, 2023-02-20 at 20:21 -0500, Ken Brown wrote: Parallel make is still not working reliably.  I've just discovered that my TeX Live build logs have several occurrences of the following warning:    jobserver unavailable: using -j1.  Add '+' to parent

Re: Regression on Cygwin: Problems with parallel make in 4.4

On Mon, 2023-02-20 at 20:21 -0500, Ken Brown wrote: > Parallel make is still not working reliably.  I've just discovered > that my TeX Live build logs have several occurrences of the following > warning: > >    jobserver unavailable: using -j1.  Add '+' to parent make rule. > > This has been goin

Re: Regression on Cygwin: Problems with parallel make in 4.4

On 2/19/2023 9:29 AM, Paul Smith wrote: I will change the default setting of the jobserver to use "pipe" on Cygwin, at least for now. Parallel make is still not working reliably. I've just discovered that my TeX Live build logs have several occurrences of the following warning: jobserver

Re: Regression on Cygwin: Problems with parallel make in 4.4

On 2/19/2023 9:29 AM, Paul Smith wrote: On Sun, 2023-02-19 at 09:17 -0500, Ken Brown wrote: So I'm not sure where to go from here on Cygwin.  Should I force Cygwin builds to use the "pipe" jobserver, as I've done for GNU/Hurd? My preference would be for you to provide a configure option, which

Re: Regression on Cygwin: Problems with parallel make in 4.4

On Sun, 2023-02-19 at 09:17 -0500, Ken Brown wrote: > > So I'm not sure where to go from here on Cygwin.  Should I force > > Cygwin builds to use the "pipe" jobserver, as I've done for > > GNU/Hurd? > > My preference would be for you to provide a configure option, which > defaults to "pipe" on Cy

Re: Regression on Cygwin: Problems with parallel make in 4.4

On 2/19/2023 8:49 AM, Paul Smith wrote: On Wed, 2023-02-15 at 13:57 -0500, Ken Brown wrote: One thing to keep in mind here is that your tests on Cygwin were done on Cygwin 2.9.0, in which FIFOs were very poorly supported.  For example, a FIFO couldn't have multiple readers or writers.  If GNU/Hu

Re: Regression on Cygwin: Problems with parallel make in 4.4

On Wed, 2023-02-15 at 13:57 -0500, Ken Brown wrote: > One thing to keep in mind here is that your tests on Cygwin were done > on Cygwin 2.9.0, in which FIFOs were very poorly supported.  For > example, a FIFO couldn't have multiple readers or writers.  If > GNU/Hurd has similar limitations, that co

Re: Regression on Cygwin: Problems with parallel make in 4.4

On Sun, 2023-02-19 at 12:44 +0100, Bruno Haible wrote: >   - 4 failures in category 'features/jobserver' >   - 2 failure in category 'functions/shell' I looked at the error logging you sent, and I think these are just a result of an incomplete/incorrect setting of the default value to "pipe". Hop

Re: Regression on Cygwin: Problems with parallel make in 4.4

Paul Smith wrote: > I've made a change that causes GNU/Hurd to not use the mkfifo()-based > jobserver, and go back to using pipe(). That's nice, because compared to the previous results - 4 failures in category 'features/archives', due to "cc: not found". - 5 failures in category 'features/jo

Re: Regression on Cygwin: Problems with parallel make in 4.4

On Wed, 2023-02-15 at 13:57 -0500, Ken Brown wrote: > If I simply run 'make -j13 world' without using the Build script, it > doesn't hang.  I don't know if this provides any clue as to where the > problem is. Speaking for myself, it doesn't give me any clues. I don't see why it should matter. Bu

Re: Regression on Cygwin: Problems with parallel make in 4.4

On Wed, 2023-02-15 at 19:34 +0100, Bruno Haible wrote: > > I may be misremembering but I thought that you had tried forcing > > the pipe jobserver option on GNU/Hurd and it didn't help. > > This must be a misunderstanding. I never said that. I don't even know > how to do this, within the framework

Re: Regression on Cygwin: Problems with parallel make in 4.4

27;m seeing. I cited https://tug.org/pipermail/tlbuild/2023q1/005290.html , in which I reported problems with the build of TeX Live. I said I had a hang in 'make -j13 world'. This was an oversimplification. What really happens is that the hang occurs when I run the 'Build'

Re: Regression on Cygwin: Problems with parallel make in 4.4

Paul Smith wrote: > > And possibly also on GNU/Hurd. Cf. > > https://lists.gnu.org/archive/html/bug-make/2023-01/msg00107.html > > I may be misremembering but I thought that you had tried forcing the > pipe jobserver option on GNU/Hurd and it didn't help. This must be a misunderstanding. I never

Re: Regression on Cygwin: Problems with parallel make in 4.4

On Tue, 2023-02-14 at 01:04 +0100, Bruno Haible wrote: > And possibly also on GNU/Hurd. Cf. > https://lists.gnu.org/archive/html/bug-make/2023-01/msg00107.html I may be misremembering but I thought that you had tried forcing the pipe jobserver option on GNU/Hurd and it didn't help.

Regression on Cygwin: Problems with parallel make in 4.4

Several packages that used to build fine on Cygwin with parallel make now fail to build. I either get strange errors or a hang. The problems started with version 4.4 and seem to stem from the fact that make now uses a FIFO by default instead of a pipe. If I use the flag '--jobserver-

Re: Regression on Cygwin: Problems with parallel make in 4.4

Ken Brown wrote: > I suggest > that you provide a configure option to set the jobserver style at the > time make is built, and set it to 'pipe' by default on Cygwin. And possibly also on GNU/Hurd. Cf. https://lists.gnu.org/archive/html/bug-make/2023-01/msg00107.html Bruno

Re: .SECONDEXPANSION problems

On Sun, 2021-12-12 at 20:35 -0500, Dmitry Goncharov wrote: > On Sun, Dec 12, 2021 at 2:15 PM Paul Smith wrote: > > Did something happen when it stopped working, like you updated to a > > different version of GNU make? > > i bet this make is built from the current git. Thanks Dmitry. I was foole

Re: .SECONDEXPANSION problems

Dmitry Goncharov wrote: On Sun, Dec 12, 2021 at 2:15 PM Paul Smith wrote: Did something happen when it stopped working, like you updated to a different version of GNU make? i bet this make is built from the current git. Correct. Thanks for your report. If you need make from git you shoul

Re: .SECONDEXPANSION problems

On Sun, Dec 12, 2021 at 2:15 PM Paul Smith wrote: > Did something happen when it stopped working, like you updated to a > different version of GNU make? i bet this make is built from the current git. > Can you create a small, self-contained example that shows the problem you're > seeing? i don

Re: .SECONDEXPANSION problems

On Thu, 2021-12-09 at 12:25 +0100, Gisle Vanem wrote: > Since some time the cool '.SECONDEXPANSION' feature has stopped > working for me. Did something happen when it stopped working, like you updated to a different version of GNU make? > In a Makefile, I have many rules to link module .DLLs: >

.SECONDEXPANSION problems

Hello list. Since some time the cool '.SECONDEXPANSION' feature has stopped working for me. In a Makefile, I have many rules to link module .DLLs: mod_airspy_source_OBJ = $(OBJ_DIR)/airspy_source_main.obj mod_airspyhf_source_OBJ = $(OBJ_DIR)/airspyhf_source_main.obj mod_bladerf_source_OB

Problems with rstata when installation

Thank you! > install_github("wwbrannon/rstata") Downloading GitHub repo wwbrannon/rstata@master from URL https://api.github.com/repos/wwbrannon/rstata/zipball/master Installing rstata "C:... \ --no-site-file --no-environ --no-save --no-restore CMD INSTALL \ "C:..." \ --library="..." \ -

Re: Problems

c subroutine name. [ETIME] >INTRINSIC ETIME > -^ > compilation aborted for second_INT_ETIME.f (code 1) Hello Carlos. This list is for errors in or problems with GNU make or makefiles. As can be seen from the above message, your problem is

Problems

To whom may it concern: I have been having troubles with lapack 3.5.0 by compiling with ifort 2013 I get errors. In the next lines, you will find the output I get and below the make.inc I used. I hope you can help me out with this. With kindest regards, Carlos $ make make: Warning: File `make

Re: GNU Make 3.80 : Problems and Bugs

On Wed, 2014-05-28 at 14:29 +0530, chandrababu nallani wrote: > Hi, > > Could you send me the link to get the known bugs and issues for GNU > Make 3.80. Sorry, but we don't spend the effort to keep detailed information on this. You can look at the bugs that were listed as fixed in the GNU make

GNU Make 3.80 : Problems and Bugs

Hi, Could you send me the link to get the known bugs and issues for GNU Make 3.80. Thanks in advance, Chandrababu. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make

[bug #34167] Spurious systax errors, Purify detects memory access problems.

Update of bug #34167 (project make): Status:None => Works for me Open/Closed:Open => Closed ___ Follow-up Comment #6: No further info is ava

[bug #34167] Spurious systax errors, Purify detects memory access problems.

Update of bug #34167 (project make): Triage Status:None => Need Info ___ Follow-up Comment #5: Well, I don't have Purify available to me and I have no way to parse/read a .pv file (I tried to lo

[bug #34167] Spurious systax errors, Purify detects memory access problems.

Follow-up Comment #4, bug #34167 (project make): I run the same make on a large LSF farm. The error appears intermittently even on the same host. I was able to reliably reproduce it on my development linux box. The error message is commands commence before first target. It is not possible for m

[bug #34167] Spurious systax errors, Purify detects memory access problems.

Follow-up Comment #3, bug #34167 (project make): It's not clear to me that this is due to a bug in make. Offhand it looks like a configuration or environment problem, not a bug in make. Are you still seeing Purify errors when you try to run this version of make? If you are please attach the out

Re: Problems installing gmake

On Thu, 2011-09-08 at 15:54 -0500, Dennis Sonifer wrote: > I have an HPUX 11.23 PA-RISC machine. Downloaded the make file from > your site, make-3.82.tar.gz. I am hoping there is just a setting or > two away from perfection but I am generally unfamiliar with installing > packages. Looks like the

Problems installing gmake

SUMMARY Encountered several errors running ./config with directions to contact you. BACKGROUND I have an HPUX 11.23 PA-RISC machine. Downloaded the make file from your site, make-3.82.tar.gz. I am hoping there is just a setting or two away from perfection but I am generally unfamiliar with insta

[bug #34167] Spurious systax errors, Purify detects memory access problems.

Follow-up Comment #2, bug #34167 (project make): I tried 3.82 with the same result. I could not build from CVS: autoreconf -i cvs [init aborted]: Cannot initialize repository under existing CVSROOT: `/home/yshtil' cvs [checkout aborted]: /home/yshtil/gnumake_latest/tmpcvs30700/CVSROOT: No such fi

[bug #34167] Spurious systax errors, Purify detects memory access problems.

Follow-up Comment #1, bug #34167 (project make): GNU make 3.81 was released almost 5 1/2 years ago. Many bugs, including memory bugs, have been resolved since then. Please try with the latest version (3.82) or even the latest version available from CVS and see if you still have memory errors.

[bug #34167] Spurious systax errors, Purify detects memory access problems.

URL: <http://savannah.gnu.org/bugs/?34167> Summary: Spurious systax errors, Purify detects memory access problems. Project: make Submitted by: yshtil Submitted on: Mon 29 Aug 2011 08:15:11 PM GMT Severity: 3 -

[bug #27437] Problems with make in a directory with present Makefiles. make does not function.

Follow-up Comment #5, bug #27437 (project make): As Philip suggested on the mailing list (which, as I already mentioned, is the RIGHT place to ask these questions and NOT in the bug tracker), you should read the README and/or INSTALL files that come with your software package. Apparently the sno

Re: [bug #27437] Problems with make in a directory with present Makefiles. make does not function.

On Mon, Sep 14, 2009 at 1:24 PM, anonymous wrote: > Follow-up Comment #2, bug #27437 (project make): > > aetixin...@aetixintro-desktop:/usr/src/snort-2.8.4$ ls Read doc/INSTALL for directions. In fact, scan most of the files in the doc directory for help. (I don't know why the snort people hide

[bug #27437] Problems with make in a directory with present Makefiles. make does not function.

Follow-up Comment #4, bug #27437 (project make): Aarrrggghhh what am I doing wrong??? How do I get the proper Makefile? ___ Reply to this item at: __

[bug #27437] Problems with make in a directory with present Makefiles. make does not function.

Follow-up Comment #3, bug #27437 (project make): Neither makefile.am nor Makefile.in are usually makefiles. makefile.am is, as I understand it from eg the first google match for that file's name, used to generate Makefile.in. Makefile.in is used, as I understand it from eg the second google mat

[bug #27437] Problems with make in a directory with present Makefiles. make does not function.

Follow-up Comment #2, bug #27437 (project make): aetixin...@aetixintro-desktop:/usr/src/snort-2.8.4$ ls aclocal.m4configure.in LICENSE missingsnort-2.8.4 ChangeLog contrib ltmain.shmkinstalldirs snort.8 config.guess COPYING m4 preproc_rules src c

[bug #27437] Problems with make in a directory with present Makefiles. make does not function.

Update of bug #27437 (project make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Follow-up Comment #1: There is little we ca

[bug #27437] Problems with make in a directory with present Makefiles. make does not function.

URL: <http://savannah.gnu.org/bugs/?27437> Summary: Problems with make in a directory with present Makefiles. make does not function. Project: make Submitted by: None Submitted on: Sun 13 Sep 2009 08:23:40

RE: Problems with gmake and pipefail. make doesn't give up.

win Waterlander From: Erwin Waterlander Sent: Thu 6/21/2007 9:46 To: [EMAIL PROTECTED] Cc: bug-make@gnu.org; Erwin Waterlander Subject: RE: Problems with gmake and pipefail. make doesn't give up. Hi, /bin/ksh is not a Korn shell on our system. It is AT&T sh (version 1993-12-28

RE: Problems with gmake and pipefail. make doesn't give up.

our /bin/ksh. If we add ; exit $$? at the end of the line in the makefile it works. -- Erwin Waterlander From: Paul Smith [mailto:[EMAIL PROTECTED] Sent: Thu 6/21/2007 4:42 To: Erwin Waterlander Cc: bug-make@gnu.org Subject: RE: Problems with gmake and pipefail

RE: Problems with gmake and pipefail. make doesn't give up.

On Wed, 2007-06-20 at 17:32 +0200, Erwin Waterlander wrote: > I compiled bash 3.2 locally. When I set > SHELL=/home/waterlan/src/bash-3.2/bash -e -o pipefail everything > works as expected. So the problem must be in the AT&T sh. As far as I know, ksh doesn't support pipefail. If so, it's not a

RE: Problems with gmake and pipefail. make doesn't give up.

make@gnu.org Subject: Problems with gmake and pipefail. make doesn't give up. Hi, I have a problem that gnu make doesn't give up after an error in a command in a pipe. I have attached a simple example. I run a command (ls) and the output is piped to command 'tee' to send the

Problems with gmake and pipefail. make doesn't give up.

Hi, I have a problem that gnu make doesn't give up after an error in a command in a pipe. I have attached a simple example. I run a command (ls) and the output is piped to command 'tee' to send the output of 'ls' to a file and stdout. Normally the shell returns the exit code of the last comm

Re: make problems

Hi, Turbo-parts elucidated on 01/03/07 22:03: Hello, allways no targets specified and no makefile found. stop. how can i change ? Sounds like you have a problem with your project + build, check if there is a "Makefile" in the directory; or explain the problem to the person who provided yo

Re: make problems

> From: "Turbo-parts" <[EMAIL PROTECTED]> > Date: Thu, 1 Mar 2007 23:03:56 +0100 > > Hello, allways no targets specified and no makefile found. stop. This usually means that you don't have a file called Makefile in the current directory. ___ Bug-make

make problems

Hello, allways no targets specified and no makefile found. stop. how can i change ? br___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make

Re: problems with Net-PCap

al symbol' cuando se hace un objeto > compartido; recompile con -fPIC > /usr/local/lib/libpcap.a: no se puede leer símbolos: Valor erróneo > collect2: ld returned 1 exit status > make: *** [blib/arch/auto/Net/Pcap/Pcap.so] Error 1 > Could you please answer me?? Hi Sofía; Thi

RE: problems with Net-PCap

On 04 December 2006 23:35, sofia wrote: > Hello, > > I'm trying to install the packages Net-Pcap0.14 but it's impossible to > do "make",it reports: > > /usr/bin/ld: /usr/local/lib/libpcap.a(pcap-linux.o): no se puede usar la > reubicación R_X86_64_32 contra `a local symbol' cuando se hace un obj

problems with Net-PCap

ve also installed tcpdump ,version 3.9.4-4 ,and this libraries: libpcap: dpkg -l "*libpcap*" Desired=Unknown/Install/Remove/Purge/Hold | Estado=No/Instalado/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: mayúsc.=malo) ||

RE: make management problems

rather than in makefiles. - Martin's Outlook, BlueArc Engineering From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andrey Scatchakov Sent: Sunday, January 29, 2006 5:41 To: bug-make@gnu.org Subject: make management problems Dear GNU team,

make management problems

Dear GNU team, I use CodeWrite 6.5 and http://www.gnu.org/software/make/manual/html_mono/make.html#SEC_Top. Unfortunately I didn't succeed to find (  ) the way to make the MAKE to stop after the predefined number of errors has occurred. ( or after the some file has failed to compile ). The

Problems and Bugs: gnu-make 3.80 for windows bug report

Hi, I find a bug for creating  make.exe  in windowns, It can't get make.exe when compiling in windowns. I have resolved this bug as followed: edit the NMakefile , add "$(OUTDIR)/hash.obj" in the file, for example OBJS = \         $(OUTDIR)/ar.obj \         $(OUTDIR)/arscan.obj \         $(

Re: automatic prerequisite problems

%% Mike Shal <[EMAIL PROTECTED]> writes: >> No fundamentally better way. You can be a bit more restrictive of what >> you match on by using filter/filter-out for pattern matching instead of >> findstring, but that's about it. ms> One other possible solution is to remove the rule to gener

RE: automatic prerequisite problems

Mike Shal wrote: > Unfortunately, what gcc actually does with the .d file (as in, which > directory it gets stored, what it lists as the target, etc) has > changed somewhat drastically between gcc versions (IIRC, between 3.0 > -> 3.3 is pretty wacky). So if you know what gcc version you're > build

Re: automatic prerequisite problems

On 11/11/05, Paul D. Smith <[EMAIL PROTECTED]> wrote: > %% "Marty Leisner" <[EMAIL PROTECTED]> writes: > > ml> ifneq (,$(findstring clean,$(MAKECMDGOALS))) > ml> NO_DEPENDS=1 > ml> endif > > ml> ifndef NO_DEPENDS > ml> -include $(DEPS) > ml> endif > > ml> I've seen this annoying behav

Re: automatic prerequisite problems

%% "Marty Leisner" <[EMAIL PROTECTED]> writes: ml> ifneq (,$(findstring clean,$(MAKECMDGOALS))) ml> NO_DEPENDS=1 ml> endif ml> ifndef NO_DEPENDS ml> -include $(DEPS) ml> endif ml> I've seen this annoying behavior for years...is there a better ml> wah t handle this? No fundamenta

automatic prerequisite problems

I've been using automatic prerequisites for years (I noticed the current documentation puts a set -e in front so command failures will be treated as errors... One of the problems is make clean or make -n will start making the prerequisites... What I've done

Re: problems with $(eval include...)

Exactly. For the way make is conceived now, once it starts building a target it doesn't check for any other rule which have that save target. In other words, once make goes to build foo.o, and then it executes a rule which imports some other rules for foo.o, those rules are just ignored. This I t

Re: problems with $(eval include...)

On Mon, 30 Jun 2003, Peter A. Kerzum wrote: > Yeah, Fabio's way seem quite clean and pretty. I agree that eval should > support include. > > > Sure. You specify that the other prerequisites also depend on exe-deps: > > > > foo: exe-deps foo.o bar.o baz.o > > foo.o bar.o baz.o: exe-deps > > >

Re: problems with $(eval include...)

n't work now. There are all kinds of potential problems; for example it often happens that more than one prerequisite depends on the same target: what if the target that you're modifying (by adding prerequisites) is already built? Should make somehow figure that out and reconsider

Re: problems with $(eval include...)

Yeah, Fabio's way seem quite clean and pretty. I agree that eval should support include. Sure. You specify that the other prerequisites also depend on exe-deps: foo: exe-deps foo.o bar.o baz.o foo.o bar.o baz.o: exe-deps But as far as I understand make this will cause troubles if exe-deps

Re: problems with $(eval include...)

%% Fabio Alemagna <[EMAIL PROTECTED]> writes: fa> On Fri, 27 Jun 2003, Paul D. Smith wrote: fa> automake uses recursive makefiles, which is something I want to fa> avoid. >> I wasn't suggesting automake in total, I was suggesting their dependency >> generation style only... this is basi

Re: problems with $(eval include...)

On Fri, 27 Jun 2003, Paul D. Smith wrote: > fa> automake uses recursive makefiles, which is something I want to > fa> avoid. > > I wasn't suggesting automake in total, I was suggesting their dependency > generation style only... this is basically what's described on my > website. hum... I must

Re: problems with $(eval include...)

On Sat, 28 Jun 2003, Paul D. Smith wrote: > %% Fabio Alemagna <[EMAIL PROTECTED]> writes: > > fa> so this might be used as fall-back solution in case the make's bug > fa> doesn't get solved. > > In an earlier email from you you said you were using the CVS code and > "it worked" (or words to tha

Re: problems with $(eval include...)

%% Fabio Alemagna <[EMAIL PROTECTED]> writes: fa> so this might be used as fall-back solution in case the make's bug fa> doesn't get solved. In an earlier email from you you said you were using the CVS code and "it worked" (or words to that effect, I don't have the email any longer). Can you

Re: problems with $(eval include...)

On Sat, 28 Jun 2003, Fabio Alemagna wrote: > This is the code: > > define getdeplist_1 > $(eval __ALLDEPS__ += $(1)) $(foreach m,$(1),$(foreach d,$($(m)/DEPS),$(if \ > $(findstring $(d),$(__ALLDEPS__)),,$(call getdeplist_1,$(d) > endef This one is simpler and more correct (in that it doesn't a

Re: problems with $(eval include...)

On Fri, 27 Jun 2003, Fabio Alemagna wrote: > Yes, that's what I thought too, however You'd agree that it would take > time for make to accomplish that job, and perhaps there could be other > issues, like dependency loops, which would be impossible to solve, or very > very difficult. It seems only p

Re: problems with $(eval include...)

%% Fabio Alemagna <[EMAIL PROTECTED]> writes: fa> On Fri, 27 Jun 2003, Paul D. Smith wrote: >> As pointed out before, if you do the dependency generation the way >> automake does it (as described on my web site) you won't have any >> of these problems

Re: problems with $(eval include...)

On Fri, 27 Jun 2003, Paul D. Smith wrote: > As pointed out before, if you do the dependency generation the way > automake does it (as described on my web site) you won't have any of > these problems. automake uses recursive makefiles, which is something I want to avoid. > fa

Re: problems with $(eval include...)

On Fri, 27 Jun 2003, Paul D. Smith wrote: > I suggest you first either build the latest CVS code or, if you don't > have the infrastructure for that (building from CVS requires that you > have autoconf, automake, etc. installed already--if you don't have a > Linux box, where these things are packag

Re: problems with $(eval include...)

bed on my web site) you won't have any of these problems. fa> My solution (if only it worked) is to include the .d files for a fa> given module ONLY when that module is about to be built, which is fa> right after the module's rule is run, and right before the .o fa> ru

Re: problems with $(eval include...)

%% Fabio Alemagna <[EMAIL PROTECTED]> writes: fa> I know that, I've thought of it myself, but it just doesn't work fa> for autogenerated header files: say foo.o depends on foo.h, but fa> foo.h is autogenerated; now, make won't know about foo.h until fa> next time it's invoked, because the

Re: problems with $(eval include...)

There are a couple of bugs in the $(eval ...) memory handling which might be related to this. I suggest you first either build the latest CVS code or, if you don't have the infrastructure for that (building from CVS requires that you have autoconf, automake, etc. installed already--if you don't ha

Re: problems with $(eval include...)

On Thu, 26 Jun 2003, Ted Stern wrote: > Ah, you have autogenerated headers! Not necessarily, but it may happen. I'm working on a complete and generic build system, which understands "modules types", and on the basis of thos types it takes some actions. It uses only make and the $(eval) function t

Re: problems with $(eval include...)

On Thu, 26 Jun 2003, Ted Stern wrote: > Hi Fabio, > > Use the "-" prefix with your include statements, it's much simpler: > > -include $(DEPS) > > This will ignore the errors caused by a file not being found. > > More generally, you can make your dependency generation a lot simpler. See > Paul

  1   2   >