[bug #38420] $(realpath ...) doesn't recover from signals
Follow-up Comment #3, bug #38420 (project make): Paul, You're spot on. It is Solaris / NFS 3. In the interim I'm using a build with the fix I suggested. Do you know of a workaround for this that wouldn't require deploying a modified version of make? ___ Reply to this item at: http://savannah.gnu.org/bugs/?38420 ___ 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 #38420] $(realpath ...) doesn't recover from signals
Follow-up Comment #4, bug #38420 (project make): The only option I can think of is using $(shell ...) to determine the real path rather than the built-in realpath function. This will be slower, but more reliable (as far as I'm aware all the EINTR issues with shell have long since been solved). Maybe something like: $(shell cd $(dir $) pwd) Or, if you don't really need the full power of realpath you could switch to abspath. That is just a string manipulation function so it doesn't do any system calls that might be interrupted with EINTR. It really depends on your situation. But there's no way I know of to fix the problem with realpath, without a code change. ___ Reply to this item at: http://savannah.gnu.org/bugs/?38420 ___ 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 #38420] $(realpath ...) doesn't recover from signals
On Wed, Feb 27, 2013 at 9:44 AM, Brian Vandenberg invalid.nore...@gnu.org wrote: Follow-up Comment #3, bug #38420 (project make): You're spot on. It is Solaris / NFS 3. In the interim I'm using a build with the fix I suggested. Do you know of a workaround for this that wouldn't require deploying a modified version of make? Doesn't this problem only occur if the NFS mount has the 'intr' flag? (The intr flag basically means violate the historical UNIX behavior because I don't trust my NFS server to recover quickly and reliably and need a way to bail out, regardless of the consequences...) Philip Guenther ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
[bug #38432] Optional parameter to tag all output lines with unique text to improve logging capabilities
URL: http://savannah.gnu.org/bugs/?38432 Summary: Optional parameter to tag all output lines with unique text to improve logging capabilities Project: make Submitted by: phantal Submitted on: Wed 27 Feb 2013 07:13:05 PM GMT Severity: 3 - Normal Item Group: Build/Install Status: None Privacy: Public Assigned to: None Open/Closed: Open Discussion Lock: Any Component Version: 3.82 Operating System: None Fixed Release: None Triage Status: None ___ Details: When building in parallel it can be rather difficult to pair up errors with the thing being built or the command executed that induced the error in the first place. The solution proposed here: tag all output text with something that makes it possible to group re-order the output of make after-the-fact to clear things up. For example: * Give each target a non-random numeric designation unique to the target (eg, a hash of the target name); for the sake of brevity I'll refer to this as a UUID in spite of the fact that typically refers to a very specific implementation/concept. * Prefix every line with a timestamp and a UUID. * Any output generated from inside a target (stdout/stderr, $(info), $(warning), $(error), etc) while evaluating the target uses the UUID for the target * Any output generated during the first pass when parsing, or otherwise generated outside a target uses a 'global' UUID. Some possible issues: * What timestamp should be used? Accurate to the moment the text was generated? Accurate to the moment the recipe command was initiated? One based on when the target's build was initiated (before any recipe lines are evaluated)? ... * How to handle sub-make processes ... they'd need to communicate with the top-tier processes and negogiate UUIDs in some fashion; however, there's a `configure` option to disable parent/child communication ... though I suppose in that case the parent could pass in a seed to sub-make processes. ___ Reply to this item at: http://savannah.gnu.org/bugs/?38432 ___ 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 #38433] Example for eval in documentation contains error with define
URL: http://savannah.gnu.org/bugs/?38433 Summary: Example for eval in documentation contains error with define Project: make Submitted by: wagenaar Submitted on: Wed 27 Feb 2013 07:25:20 PM GMT Severity: 3 - Normal Item Group: Documentation Status: None Privacy: Public Assigned to: None Open/Closed: Open Discussion Lock: Any Component Version: None Operating System: Any Fixed Release: None Triage Status: None ___ Details: The example for the eval function in the documentation at http://www.gnu.org/software/make/manual/html_node/Eval-Function.html contains a syntax error that causes the example to fail quietly. The problem is in the line define PROGRAM_template = This line should not have = at the end. ___ Reply to this item at: http://savannah.gnu.org/bugs/?38433 ___ 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 #38420] $(realpath ...) doesn't recover from signals
Follow-up Comment #5, bug #38420 (project make):
Paul,
I'm using `realpath` for defensive coding purposes. I'm using a pattern
rule of the form:
%.so :
$(if $(realpath $(filter %.o,${^})),,$(warning No dependencies specified for
${@})@false)
recipe goes here
... where the dependencies are specified elsewhere. Three basic things
[can/should] trigger this:
* Mis-spelled library names
* Forgetting to specify dependencies
* The dependency's recipe may be screwed up but may not cause the build to
fail immediately; consequently the file may not actually exist.
$(shell) would work; but I've managed to cut out all uses of $(shell) inside
recipes, which has improved the build times significantly. Given the choice,
it sounds like a modified version of gmake would be preferable.
___
Reply to this item at:
http://savannah.gnu.org/bugs/?38420
___
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 #38433] Example for eval in documentation contains error with define
On Wed, Feb 27, 2013 at 11:25 AM, Daniel Wagenaar invalid.nore...@gnu.org wrote: The example for the eval function in the documentation at http://www.gnu.org/software/make/manual/html_node/Eval-Function.html contains a syntax error that causes the example to fail quietly. The problem is in the line define PROGRAM_template = This line should not have = at the end. No, that line is perfectly correct. The problem is that you're still running version 3.81, which was obsoleted almost 3 years ago. Upgrade to 3.82. Or use info make to read the documentation that's installed on your system and therefore matches the version you're running. Philip Guenther ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
[bug #38433] Example for eval in documentation contains error with define
Update of bug #38433 (project make): Status:None = Not A Bug Open/Closed:Open = Closed ___ Follow-up Comment #1: That's a valid statement in version GNU make 3.82. You must be using an older version of GNU make. Note that the online documentation always refers to the latest released version of GNU make. You should be referring to the documentation that came with your version of GNU make, if you're not using the latest release. ___ Reply to this item at: http://savannah.gnu.org/bugs/?38433 ___ 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 #38420] $(realpath ...) doesn't recover from signals
On Wed, Feb 27, 2013 at 11:36 AM, Philip Guenther guent...@gmail.com wrote: On Wed, Feb 27, 2013 at 9:44 AM, Brian Vandenberg invalid.nore...@gnu.org wrote: Follow-up Comment #3, bug #38420 (project make): You're spot on. It is Solaris / NFS 3. In the interim I'm using a build with the fix I suggested. Do you know of a workaround for this that wouldn't require deploying a modified version of make? Doesn't this problem only occur if the NFS mount has the 'intr' flag? (The intr flag basically means violate the historical UNIX behavior because I don't trust my NFS server to recover quickly and reliably and need a way to bail out, regardless of the consequences...) Philip Guenther hm ... The documentation for NFS recommends configuring with 'hard' and 'intr' so it'll allow signals to interrupt (causing some platforms to set errno = EINTR and fail) ... and it looks like 'hard' is the default. The mount point isn't configured explicitly with 'hard', but if the documentation I'm reading is accurate then it should be set to 'hard' by default. What it doesn't make clear is, if it's configured with 'nointr' will that just cause the system function to block? That seems the most plausible. Anyway, thanks for that; it gives me something else to pursue. -Brian ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [bug #38420] $(realpath ...) doesn't recover from signals
On Wed, 2013-02-27 at 12:47 -0700, Brian Vandenberg wrote: What it doesn't make clear is, if it's configured with 'nointr' will that just cause the system function to block? That seems the most plausible. Correct. With nointr, you won't be able to (for example) ^C a program that is hung waiting for the NFS server to respond. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [bug #38433] Example for eval in documentation contains error with define
On 02/27/2013 11:30 AM, Philip Guenther wrote: On Wed, Feb 27, 2013 at 11:25 AM, Daniel Wagenaar invalid.nore...@gnu.org wrote: The example for the eval function in the documentation at http://www.gnu.org/software/make/manual/html_node/Eval-Function.html contains a syntax error that causes the example to fail quietly. The problem is in the line define PROGRAM_template = This line should not have = at the end. No, that line is perfectly correct. The problem is that you're still running version 3.81, which was obsoleted almost 3 years ago. Upgrade to 3.82. Or use info make to read the documentation that's installed on your system and therefore matches the version you're running. Philip Guenther I appreciate your correction, but I still feel that the documentation on the website would be more helpful if it at least mentioned that older versions of make fail quietly when there is a = at the end of the line. The reason is that make v. 3.81 is still in very wide use. For instance, it is part of Ubuntu 12.04-LTS as well as Mint 14. - Daniel Wagenaar ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [bug #38433] Example for eval in documentation contains error with define
On Wed, Feb 27, 2013 at 1:56 PM, Daniel Wagenaar d...@caltech.edu wrote: I appreciate your correction, but I still feel that the documentation on the website would be more helpful if it at least mentioned that older versions of make fail quietly when there is a = at the end of the line. The reason is that make v. 3.81 is still in very wide use. For instance, it is part of Ubuntu 12.04-LTS as well as Mint 14. That sounds like a bug in Ubuntu. Or maybe it's just a consequence of the choice of selecting a Long Term Support release. Meanwhile, other people complain that the docs are too long; adding this feature was added in 3.8x throughout the guide just makes it longer and harder to read. It's not a costless addition. The documentation for the program on your box is on your box. WTP? Philip ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [bug #38433] Example for eval in documentation contains error with define
On 02/27/2013 02:07 PM, Philip Guenther wrote: On Wed, Feb 27, 2013 at 1:56 PM, Daniel Wagenaar d...@caltech.edu wrote: I appreciate your correction, but I still feel that the documentation on the website would be more helpful if it at least mentioned that older versions of make fail quietly when there is a = at the end of the line. The reason is that make v. 3.81 is still in very wide use. For instance, it is part of Ubuntu 12.04-LTS as well as Mint 14. That sounds like a bug in Ubuntu. Or maybe it's just a consequence of the choice of selecting a Long Term Support release. Meanwhile, other people complain that the docs are too long; adding this feature was added in 3.8x throughout the guide just makes it longer and harder to read. It's not a costless addition. The documentation for the program on your box is on your box. WTP? Philip I suppose the fundamental problem is make silently failing on illegal input. - Daniel ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
[bug #38433] Example for eval in documentation contains error with define
Follow-up Comment #2, bug #38433 (project make): Paul and Philipp, Daniel has a valid point here. You could be a lot more welcoming on this case, why so hard on him? I hit the very same thing myself some time ago, just forgot to speak up myself. That documentation bug is the reason meta programming in GNU make took my too starts, rather than one. While I appreciate progress in GNU make, version 3.82 has produced costs over 3.81 to many parities, see the list of bugs related to 3.82-caused breakage in Gentoo Linux alone: https://bugs.gentoo.org/show_bug.cgi?id=331977. To summarize: people need all the support with the transition and with understanding the differences betwen 3.81 and 3.82 they can get. Daniel could have prepared a patch for the docs by now and be motivated to do more later, if you had instructed him about it. The good part about it: you may have a second chance. Don't let it pass. Best, Sebastian ___ Reply to this item at: http://savannah.gnu.org/bugs/?38433 ___ 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 #38433] Example for eval in documentation contains error with define
On Wed, Feb 27, 2013 at 2:42 PM, Sebastian Pipping invalid.nore...@gnu.org wrote: Paul and Philipp, Side note: I should make clear that I am not committer to GNU make and do not speak for the project. I'm just a contributer to the lists, answering questions where I can. Daniel has a valid point here. You could be a lot more welcoming on this case, why so hard on him? I hit the very same thing myself some time ago, just forgot to speak up myself. That documentation bug is the reason meta programming in GNU make took my too starts, rather than one. IMO, the suggestion that was proposed would reduce the overall usability of the manual and increase the confusion. I seen it tried in multiple ways** in other open source projects (and at my day job) and the results were never complete (there were nuances left out), took a large amount of effort, and always made a small set of people happy and a much larger set of people unhappy. I'll note that glibc, which has a much larger development group including commercial funding for several, doesn't describe when something was added or changed in its manual. gcc's manual only mentions inter-version changes for the -fabi-version option (whose whole purpose is inter-version support) and for a single specific removed feature, with no comment when describing the multiple new options and extensions. (Did the manual to your car or bike or computer include comments throughout it describing how this year's model is different from the previous years?) If you have an example of a manual that does that and does it *well*, without compromising readability, I would be glad to be wrong and interested it seeing it so that I can see how they pulled it off. If the GNU website were to require you to select the version of make you wanted to see the documentation for, I think that would be a reasonable 'solution'. Perhaps a layout like http://gcc.gnu.org/onlinedocs/ could be done without too much complexity. While I appreciate progress in GNU make, version 3.82 has produced costs over 3.81 to many parities, see the list of bugs related to 3.82-caused breakage in Gentoo Linux alone: https://bugs.gentoo.org/show_bug.cgi?id=331977. That was 2 years ago. When does it end? When the last Linux distributor's Long Term Support version is off it? They get to choose how long that cost is imposed on this project? To summarize: people need all the support with the transition and with understanding the differences betwen 3.81 and 3.82 they can get. That information is provided in the form of the NEWS file. Perhaps those should be more easily obtainable via the website, but spreading it throughout the manual is not, IMNSHO, a solution. Daniel could have prepared a patch for the docs by now and be motivated to do more later, if you had instructed him about it. The good part about it: you may have a second chance. Don't let it pass. Or you could try doing that yourself. No one needs my approval to do it, or to put it on Daniel, and Paul could easily decide that your patch is an improvement and check it in. (Oops, guess I screwed up my second chance.) Philip Guenther ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [bug #38433] Example for eval in documentation contains error with define
On Wed, Feb 27, 2013 at 5:02 PM, Philip Guenther guent...@gmail.com wrote: Side note: I should make clear that I am not committer to GNU make and do not speak for the project. I'm just a contributer to the lists, answering questions where I can. Likewise. IMO, the suggestion that was proposed would reduce the overall usability of the manual and increase the confusion. I think you and the others in the nay camp may be being a bit unfair. As far as I can see, nobody has proposed (in this thread) that the entire manual be reworked to note the version in which each feature appeared. You're absolutely right that that would stink but it's a straw man. The proposal, as I understand it, is to add a note about this particular incompatibility because of the mysterious, silent way it fails. I think any of us who've been reading this list for a long time can attest that it's one of the more common problems that people stumble over. It's a golden oldie, so I don't know why it would be so bad to add a sentence for it. There may even be a couple of other cases that could get similar treatment. It doesn't have to become a slippery slope. If the GNU website were to require you to select the version of make you wanted to see the documentation for, I think that would be a reasonable 'solution'. Perhaps a layout like http://gcc.gnu.org/onlinedocs/ could be done without too much complexity. Another nice example is the Python docs ( http://docs.python.org/2/index.html). Notice the dropdown at the top left where you get to pick the version you care about. David Boyce ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [bug #38437] cannot find the include file
On Wed, Feb 27, 2013 at 8:55 PM, Jian invalid.nore...@gnu.org wrote:
...
Supposing 2 makefiles in dir A: 1.mak, 2.mak, and 1.mak include 2.mak.
Now in dir B, 3.mak includes 'A/1.mak' (will auto include 2.mak). But error
shows that 2.mak cannot be found.
The make option -I can be the workaround like:
cd B
make -f 3.mak -IA
But it's not acceptable to tell user to uses -I to make every time. make
shall be able to find 2.mak.
So have 1.mak look for 2.mak in the same directory, by doing something like:
# Get the directory part of the path by which 1.mak was included
# This should be before any other includes in 1.mak
dir_of_1 = $(dir $(lastword $(MAKEFILE_LIST)))
...and then later:
# pull in 2.mak in the same directory as this file
include ${dir_of_1}2.mak
Philip Guenther
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
[bug #38437] cannot find the include file
Update of bug #38437 (project make): Status:None = Not A Bug Open/Closed:Open = Closed ___ Follow-up Comment #1: This is how GNU make has always worked: the include file reference is always relative to the current working directory of the GNU make program, regardless of what directory the current makefile is in. There are far too many makefiles out there relying on this behavior, to change it now. Suggestions have been made to allow use of VPATH to find included makefiles; see bug #15224 ___ Reply to this item at: http://savannah.gnu.org/bugs/?38437 ___ 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 #38420] $(realpath ...) doesn't recover from signals
Update of bug #38420 (project make): Item Group:None = Bug Status:None = Fixed Assigned to:None = psmith Open/Closed:Open = Closed Component Version:None = 3.82 Operating System:None = POSIX-Based Fixed Release:None = SCM Triage Status:None = Small Effort ___ Reply to this item at: http://savannah.gnu.org/bugs/?38420 ___ 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
