Re: Missing [/usr/local]/var/lib and [/usr/local]/tmp
> I think the first question is to understand what a "library state > directory" is? Whate are you storing under it? Seems like something > architecture independent? Are the files shareable between > installations? I'm talking about NGINX Unit, which stores the running configuration (kind of what /etc/nginx/nginx.conf was to NGINX, but Unit uses a runtime defined JSON file). It also stores a few other files, but that's the main one. If the process is restarted, it picks up that configuration, so it needs to be kept after reboot (so not /run) That sounds like a cache file, so why not /var/cache? I don't understand why /var/lib though ... It is arch independent. And it doesn't make sense to share it, as it represents the state of the running instance of unitd. Sharing it would probably break other instances of the process when one of the instances modifies it. Ok, then something under /var would make sense.
Re: Missing [/usr/local]/var/lib and [/usr/local]/tmp
I'm improving a Makefile for a project which uses [/usr/local]/var/lib and [/usr/local]/tmp. I see there's no standard in the GNU coding standards for directory variables. I used the following: tmpdir := $(prefix)/tmp libstatedir := $(localstatedir)/lib I developed the name $libstatedir for symmetry with $runstatedir, which is also a child of $localstatedir, with the first part of the name as the name of the child dir. Would you mind adding those to your directory variables? I think the first question is to understand what a "library state directory" is? Whate are you storing under it? Seems like something architecture independent? Are the files shareable between installations? For /tmp, the only thing that should realy be used is /tmp (or /var/tmp). /usr/tmp would be strange, and very non-standard.
Re: [BUG] inconsistency in $localstatedir and $runstatedir
So you're saying that "should normally be" doesn't mean the "the default value should normally be", but rather that "commonly, people use". Right, the _default_ value depends on _your_ system. On some systems, it is one thing, and on other it is something else. Which is why "you" (you in the sense, you or your distribution) should have a config.site that specifies the correct thing for your system. So maybe you would like to change it to something like: [ This should normally be /var/run, but the default value should be /usr/local/var/run, but write it as $(localstatedir)/run ] Or even omit any reference to /var/run, which is just misleading, and say: [ This should normally be /usr/local/var/run, but write it as $(localstatedir)/run ] Makes sense? Not at all, since we really want it to be /var/run not something else, but the default is different. So we want it to be /var/run, but it is set to localstatedir/run for "special" reasons. I don't see why we would like to mention /var/run here if we don't mention for example /etc (we mention /usr/local/etc). Because for "locally" installed software, the location is /usr/local/etc -- not /etc. /var/run is special.
Re: [BUG] inconsistency in $localstatedir and $runstatedir
Hi Alejandro, I think the source of the confusion is that "Should normally be" and how you should write a default value don't match up because it is normal to use non-default values. So systems are commonly set up with localstatedir=/usr/var and runstatedir=/var/run, despite the fact that their defaults are $prefix/var and the result of appending /run to it. The reason to give the defaults in this form is so that, when someone sets prefix to /usr/local, they (by default) get /usr/local/var and /usr/local/var/run and thus conform to "how your non-system GNU install should work" rather than stomping on where things would have been if you'd hard-coded what many folk do in fact set up. This way, if someone sets things up differently, you play nicely with their choices, rather than hard-coding what "everyone" else does. It's about whoever administers a particular box being at liberty to do what they want, so if you're writing software to offer to others to install on their systems, your defaults should be "polite" and not impose on them any particular set-up. Well written.
Re: [BUG] inconsistency in $localstatedir and $runstatedir
Oh, there _is_ a bug. Compare what the documentation says, with a bit of variable expansion that I did to show the bug (between parentheses): Documentation says: $prefix Should normally be */usr/local* $localstatedir Should normally be */usr/local/var* But write it as *$prefix/var* (= /usr/local/var; OK) $runstatedir Should normally be */var/run* But write it as *$localstatedir/run* (= $prefix/var/run) (= /usr/local/var/run) (!= /var/run; NOK) Do you realize the bug now? This is intended and not a bug, "should normally" doesn't mean that it is, or must be. *You* are _supposed_ to pass the right thing for your system, the defaults are (i.e. localstatedir = runstatedir) is to make it easy for people just doing a "default" install, but if your system has someting else, you need to modify it (i,e., the 'should be'). So not a bug, but intended behaivour.
Re: [BUG] inconsistency in $localstatedir and $runstatedir
How can $localstatedir be $prefix/var and at the same time $runstatedir be /var/run (notice no prefix) if it is defined as $localstatedir/run. Because prefix is normally /usr, and it was/is common to use /usr/var for exactly that purpose. Where as runstatedir was in /var/run and not /usr. Since the FHS doesn't define /usr/local/var, and my Debian system lacks it, and I don't think people are going to start symlinking /usr/local/var to /var, I guess the coding standard really intended to define $localstatedir as /var. Yes, and no. On GNU/Linux, it was meant to be /usr/var (prefix = "/usr"), on GNU systems it was meant to be /var (prefix = "") If you want to do this on other systems, the best way is to setup a config.site file where you specify the locations explisltly. The bug is also present in the GNU Make documentation, which seems to be just a copy of the GNU coding standards. This isn't a bug, it works as intended.
Re: detecting if a Makefile is GNU make-ish
> Is there some way of detecting or specifying that a Makefile is GNU > make specific? Name the file GNUmakefile? Hard to rename other peoples stuff.
detecting if a Makefile is GNU make-ish
Is there some way of detecting or specifying that a Makefile is GNU make specific? I'm kinda thinking of something similar to the .POSIX directive. I'm in a situation where got a bunch of Makefiles, some BSD makefile, some GNU, some POSIX and to somehow handle this without having to remeber if one is to type make, gmake, nmake, I want to create a small wrapper that can sorta figure it out by itself. Other ideas are welcome too ...
order of evaluation for target specific variables
What are the intended semantics of the following snippet, target: foo=zork target: ifeq ($(foo),zork) @echo "zork zork" else @echo "bork bork" endif I'm thinking that it should print "zork zork" -- target specific variables are supposed to have the same priority as if any other make variable. But if foo=zork is defined as a non-target specific variable, the behaviour changes (printing "zork zork"). But then, the current behaviour (printing "bork bork") kinda makes sense as well. Is this a subtle "feature" in how target specific variables are handled? ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: GNU make distribution with proprietary products
I'm interested in finding some examples of proprietary software products (ie, non-GPL licensed) that distribute a copy of GNU make (preferably a binary, with or without changes to the GNU make source code) with the product. If you are aware of such a product, I would appreciate a reply with the product name and vendor. Thank you in advance. There are free software license that are not GPL, for example the modified BSD license. Pointing you to non-free software would be wrong, since such software subjugates your rights as a computer user. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: Why *** extraneous `endef'. Stop.?
define starts a macro. Everything from the start of the macro to endef is just text and is not evaluated. So your inner define is not recognised - it's just treated as text. That means that the dirst endef matches the first define and all the other endefs seem to have no corresponding define statement. In other words, you cannot nest defines like that. Sure you can, it is a documented feature. From the GNU make manual, (make) Defining: |You may nest `define' directives: `make' will keep track of | nested directives and report an error if they are not all properly | closed with `endef'. Note that lines beginning with tab characters | are considered part of a command script, so any `define' or `endef' | strings appearing on such a line will not be considered `make' | operators. This is more a bug than anything. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: gnu make patch
Hey Martin, sorry for the delay when it came to posting this patch.
Here is a small patch that adds a new option to make that causes make
to abort after N failures. Martin suggest that -k should take an
extra argument where the user can tell make to abort after N failures,
quite useful if you want are running a build robot, or similar.
The patch is a bit rough, but does anyone object to the idea of
getting something like this into GNU make? If not, I'll happily clean
up the patch and submit a ChangeLog and anything else that might be
required.
Cheers, Alfred
diff --git a/job.c b/job.c
index a81cd81..200f754 100644
--- a/job.c
+++ b/job.c
@@ -379,9 +379,19 @@ static void
child_error (char *target_name, int exit_code, int exit_sig, int coredump,
int ignored)
{
+ if (max_keep_going_count = keep_going_count)
+{
+ error (NILF, _(*** [%s] Error (aborted after %d failures) %d),
+target_name, keep_going_count, exit_code);
+ die (2);
+}
+
if (ignored silent_flag)
return;
+ /* Only increase KEEP_GOING_COUNT if the job _really_ failed. */
+ keep_going_count++;
+
#ifdef VMS
if (!(exit_code 1))
error (NILF,
diff --git a/main.c b/main.c
index 483babf..47e79ba 100644
--- a/main.c
+++ b/main.c
@@ -189,9 +189,13 @@ int no_builtin_variables_flag = 0;
/* Nonzero means keep going even if remaking some file fails (-k). */
-int keep_going_flag;
+int keep_going_flag = 0;
int default_keep_going_flag = 0;
+int keep_going_count = 0;
+unsigned int max_keep_going_count = -1;
+static unsigned int inf_keep_going_count = 0;
+
/* Nonzero means check symlink mtimes. */
int check_symlink_flag = 0;
@@ -318,6 +322,8 @@ static const char *const usage[] =
N_(\
-k, --keep-goingKeep going when some targets can't be made.\n),
N_(\
+ --keep-going-count[=N] Keep going when N targets can't be made.\n),
+N_(\
-l [N], --load-average[=N], --max-load[=N]\n\
Don't start multiple jobs unless load is below
N.\n),
N_(\
@@ -416,6 +422,14 @@ static const struct command_switch switches[] =
{ 'W', string, (char *) new_files, 0, 0, 0, 0, 0, what-if },
{ CHAR_MAX+4, flag, (char *) warn_undefined_variables_flag, 1, 1, 0, 0, 0,
warn-undefined-variables },
+/* BUG: There is a bug in the argument parser where if you have a
+ long-optin, but no corresponding short option in the ASCII
+ range, the output will produce a charachter that can corrupt
+ the terminal.
+*/
+{ CHAR_MAX+5, positive_int, (char *) max_keep_going_count, 1, 1, 0,
+ (char *) inf_keep_going_count,
+ (char *) max_keep_going_count, keep-going-count },
{ 0, 0, 0, 0, 0, 0, 0, 0, 0 }
};
diff --git a/make.h b/make.h
index 994f4f2..43f9677 100644
--- a/make.h
+++ b/make.h
@@ -499,6 +499,9 @@ extern char *getwd ();
extern const struct floc *reading_file;
extern const struct floc **expanding_var;
+extern int keep_going_count;
+extern unsigned int max_keep_going_count;
+
extern char **environ;
extern int just_print_flag, silent_flag, ignore_errors_flag, keep_going_flag;
diff --git a/remake.c b/remake.c
index a752734..b774dbd 100644
--- a/remake.c
+++ b/remake.c
@@ -311,7 +311,7 @@ update_file (struct file *file, unsigned int depth)
alloca (0);
/* If we got an error, don't bother with double_colon etc. */
- if (status != 0 !keep_going_flag)
+ if (status != 0 keep_going_flag == 1)
return status;
if (f-command_state == cs_running
@@ -350,7 +350,7 @@ complain (const struct file *file)
const char *msg_parent
= _(%sNo rule to make target `%s', needed by `%s'%s);
- if (!keep_going_flag)
+ if (keep_going_flag == 0)
{
if (file-parent == 0)
fatal (NILF, msg_noparent, , file-name, );
@@ -529,7 +529,7 @@ update_file_1 (struct file *file, unsigned int depth)
while (f != 0);
}
- if (dep_status != 0 !keep_going_flag)
+ if (dep_status != 0 keep_going_flag == 0)
break;
if (!running)
@@ -587,7 +587,7 @@ update_file_1 (struct file *file, unsigned int depth)
while (f != 0);
}
- if (dep_status != 0 !keep_going_flag)
+ if (dep_status != 0 keep_going_flag == 0)
break;
if (!running)
@@ -619,7 +619,7 @@ update_file_1 (struct file *file, unsigned int depth)
DBF (DB_VERBOSE, _(Giving up on target file `%s'.\n));
- if (depth == 0 keep_going_flag
+ if (depth == 0 keep_going_flag == 1
!just_print_flag !question_flag)
error (NILF,
_(Target `%s' not remade because of errors.), file-name);
@@ -1017,7 +1017,7 @@ check_dep (struct file *file, unsigned int depth,
if (! d-ignore_mtime)
*must_make_ptr = maybe_make;
check_renamed (d-file);
- if (dep_status != 0 !keep_going_flag)
+
Re: build breaks
#include stdio.h
#include string.h
#include time.h
#include sys/stat.h
#include linux/ext2_fs.h
#include fcntl.h
int main()
{
return 0;
}
I really believe what you guys do is a crap.
PEBKAC. This for example has nothing to do with GNU Make, and is
completely related to your broken code. You have forgotten to include
an extra header that is needed by linux/ext2_fs.h, namley
asm/types.h which defines BITS_FOR_LONG among other things.
Next time, please use a politer tone.
___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make
Re: plzzzzzzzzzz help
These days, spam is a huge percentage of all email and the open source mailing lists are no exception. In order to allow anyone to report problems and ask for help many OSS mailing lists don't require you to subscribe before posting... that means that someone has to go through and look through the spam to find the messages that should be forwarded to the list. In the GNU Project, we advocate free software, not open source. Open source is the slogan of a movement that was formed specifically to reject (and hush up) our philosophy, so we never use that term here except to explain the difference between the two movements. See http://www.gnu.org/philosophy/free-software-for-freedom.html. As representatives of the GNU project it makes it even more important that we clearly state that we and the work we do is not part of a movement that was created to silence us. Cheers. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: make and backslash-newline's
I still believe the change is localized and not widespread enough to justify supporting both behaviors... hopefully I'm not whistling past the graveyard. I don't know if I should take your word for it, or if I should compile lots of things (old and new) with the beta make and report what breaks. I'm still a bit bummed out after trying to figure out this crap that the moronic Debian maintainer caused (sorry, I have _NO_ flattering words for him right now, maybe in a year or so when I forget about this). Either of these methods will behave identically to the old way, and also will behave identically in both old and new versions of GNU make (and other versions of make, if that's important to anyone). And, I don't think readability or maintainability suffers much using either of these methods (of course these things are in the eye of the beholder... Dan Jacobson for one seems to feel otherwise). Could have been prettier, could have been uglier; nothing to wet your pants for. I'll think about it some more maybe compile a bunch of stuff with the make from alpha, still a bit pissed at the fool who added a beta make to Debian since the old Makefile do make sense IMHO. Do you have any date for a proper release of 3.81? For what it is worth (I don't want you to rewrite it so it works with 3.81 and = 3.80, I know make quite well thank you very much and can do it myself :-), here is the fragment that libc broke on (note the break in the regexp): $(patsubst %,$(objpfx)%.udeps,$(user-interfaces)): $(objpfx)%.udeps: $(..)mach/Machrules $(make-target-directory) # We must use $(CFLAGS) to get -O flags that affect #if's in header files. $(include-%.defs) | \ $(CC) $(CFLAGS) $(CPPFLAGS) -M -x c - | \ sed -e 's,- *:,$@ $(@:.udeps=.ustamp) $(@:.udeps=.uh) $(@:.udeps=.__h)\ $(@:.udeps=_server.c) $(@:.udeps=_server.h):,' \ $(sed-remove-objpfx) [EMAIL PROTECTED] mv -f [EMAIL PROTECTED] $@ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: make and backslash-newline's
I have some surprisingly good statistics. In ALT Linux Sisyphus (repository with 5000+ source packages) percentage of packages You have fallen for the trap that Linux is a operating system, which it is not; it is simply a kernel. The operating system you are actually refering to is an variant of the GNU system, called GNU/Linux. Would you please call the system you are using for GNU/Linux? Simply calling it for Linux, only hurts the GNU project, calling it by its proper name doesn't hurt anyone. which build was broken by make update is about 10 (0.2%). Did this test include recent softawre only? Or old? Do you have a list of those 10 packages that broken? If the number is that small, then I'll shutup about this; and send a patch to libc to fix the little annoyance. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: make and backslash-newline's
It's not clear to me what the problem is with having a late beta of GNU make installed into Debian unstable. If these changes are going to be in the next release would it really have made much difference to wait for that? The problem is that you don't get the chance to read the NEWS file. :( Often when you update Debian, you get a bazillion packages to update, and simply don't have the time to read through all the new blurbs. If 3.81 had been released, I atleast, would have read the NEWS file that you'd post to info-gnu (and I would have sent a bug report if you didn't :-); and would have noticed such a change. ams Do you have any date for a proper release of 3.81? Yes: imminently. Okie, I'll just fix the Makefile in glibc then, easier that way. As you say, you don't need my help... but I'll just mention that if it were me and I was already committed to GNU make (as it seems you are here) I'd consider creating a variable that held all the possible suffixes (depsuffix = ustamp uh __h _server.c _server.h), then replace this list with a $(foreach ...) loop. This lets you add new suffixes very easily by updating that variable. Without seeing the entire makefile I can't tell, of course, but it might be that this suffix variable could be used in similar contexts in other places in the makefile. Well, libc's Makefiles are freaky for one, and this target in question hasn't been touched since 1996; and most of the Makefile hasn't been touched since 1992. :-) Thanks for the tips though. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
make and backslash-newline's
Hey, Please revert the POSIX_ME_HARDER change of backslash-newline sequences are handled. There is absolutley no reason to break this. Lots of old Makefile use it, and so do many new ones. If one wishes to follow POSIX, one can make this the default setting when POSIX_ME_HARDER (usually known as POSIXLY_CORRECT) is set or a extra option, --posix. GNU Make is after all not POSIX make. I wrote the following a while ago before having read the archives (I canceled the message that was in queue since I wasn't subscribed, then subscribed, and now resending this new one): --- Hi, This bug report is a bit inproper to post here, it is a GNU Make included in Debian GNU/Linux (unstable), the Debian package is called make 3.80+3.81.b4-1. Which is basically make 3.81-beta4. Anyway, I suspect that this happens with the normal tarball too (I haven't checked yet, it is late, and I wasted several hours figuring this crap out, and would like to do some nasty things with the $%#^%$ who included a beta make into Debian without doing proper testing of it). When compiling the GNU C library with this (Debian's 3.81-beta4) make one gets the following error: [...] echo '#include mach/mach.defs' | \ i586-pc-gnu-gcc -std=gnu99 -O2 -Wall -Winline -Wwrite-strings -fmerge-all-constants -g -Wno-parentheses -Wstrict-prototypes -mpreferred-stack-boundary=2 -I../include -I/home/update/ams/slask/cross/src/glibc.obj/mach -I/home/update/ams/slask/cross/src/glibc.obj -I../sysdeps/i386/elf -I../sysdeps/mach/hurd/i386 -I../sysdeps/mach/hurd -I../sysdeps/gnu -I../sysdeps/unix/bsd/bsd4.4 -I../sysdeps/unix/mman -I../sysdeps/mach/i386 -I../sysdeps/mach -I../sysdeps/i386/i586 -I../sysdeps/i386/i486 -I../sysdeps/i386/fpu -I../sysdeps/i386 -I../sysdeps/wordsize-32 -I../sysdeps/ieee754/ldbl-96 -I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754/flt-32 -I../sysdeps/unix/bsd -I../sysdeps/unix/common -I../sysdeps/unix/inet -I../sysdeps/unix -I../sysdeps/posix -I../sysdeps/ieee754 -I../sysdeps/generic/elf -I../sysdeps/generic -I.. -I../libio -I../hurd -I/home/update/ams/slask/cross/src/glibc.obj/hurd/ -I../mach -I/home/update/ams/slask/cross/src/glibc.obj/mach/ -I. -nostdinc -isystem /slask/psi lo1/ams/cross/bin/../lib/gcc/i586-pc-gnu/4.0.3/include -isystem /home/update/ams/slask/cross/sys_root/include -D_LIBC_REENTRANT -include ../include/libc-symbols.h -M -x c - | \ sed -e 's,- *:,/home/update/ams/slask/cross/src/glibc.obj/mach/mach/mach_interface.udeps /home/update/ams/slask/cross/src/glibc.obj/mach/mach/mach_interface.ustamp /home/update/ams/slask/cross/src/glibc.obj/mach/mach/mach_interface.uh /home/update/ams/slask/cross/src/glibc.obj/mach/mach/mach_interface.__h\ /home/update/ams/slask/cross/src/glibc.obj/mach/mach/mach_interface_server.c /home/update/ams/slask/cross/src/glibc.obj/mach/mach/mach_interface_server.h:,' \ -e 's@ /home/update/ams/slask/cross/src/glibc\.obj/@ $(common-objpfx)@g' -e '[EMAIL PROTECTED]/home/update/ams/slask/cross/src/glibc\.obj/@$(common-objpfx)@g' /home/update/ams/slask/cross/src/glibc.obj/mach/mach/mach_interface.udeps.new mv -f /home/update/ams/slask/cross/src/glibc.obj/mach/mach/mach_interface.udeps.new /home/update/ams/slask/cross/src/glibc.obj/mach/mach/mach_interface.udeps make[2]: Leaving directory `/slask/psilo1/ams/cross/src/glibc/mach' make[2]: Entering directory `/slask/psilo1/ams/cross/src/glibc/mach' /home/update/ams/slask/cross/src/glibc.obj/mach/mach/mach_interface.udeps:1: *** missing separator. Stop. make[2]: Leaving directory `/slask/psilo1/ams/cross/src/glibc/mach' make[1]: *** [mach/subdir_lib] Error 2 make[1]: Leaving directory `/slask/psilo1/ams/cross/src/glibc' make: *** [all] Error 2 .../glibc.obj/mach/mach/mach_interface.udeps lacks a backslash here and there. The latest release of make, 3.80, works just dandy with the same setup. Sadly, the build process for glibc is a bit magical, but this makes it an ideal candidate for testing make on! :-) I haven't had a chance to look at the thing to get a clean test case. Cheers, and happy hacking. --- ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: make chokes on rules with colons in it
jm I've been trying to build GNU mailutils for Debian inside
jm svn-buildpackage, which copies the source to a build area
jm using the debian version as the path. Debian version had been
jm until now 20031103-1, for example. Now, it's something like
jm 1:0.4+20031231-1, and make doesn't like this, due to the
jm colon in the path.
Correct. You can't include : as part of a target or prerequisite
name in GNU make (at least not reliably).
Then this should be documented in the manual. Here is a patch.
2004-01-03 Alfred M. Szmidt [EMAIL PROTECTED]
* doc/make.texi (Rule Syntax): Document that `:' aren't
allowed in target or prerequisite names.
--- doc/make.texi Sat Jan 3 16:05:52 2004
+++ doc/make.texi Sat Jan 3 16:19:19 2004
@@ -1629,6 +1629,13 @@
appear on the same line, with a semicolon. Either way, the effect is the
same. @xref{Commands, ,Writing the Commands in Rules}.
[EMAIL PROTECTED] colon (@code{:}), in target names
[EMAIL PROTECTED] @code{:}, in target names
[EMAIL PROTECTED] colon (@code{:}), in prerequisite names
[EMAIL PROTECTED] @code{:}, in prerequisite names
+Including a colon, @code{:}, as part of a target or prerequisite name
+is not supported by GNU make.
+
@cindex dollar sign (@code{$}), in rules
@cindex @code{$}, in rules
@cindex rule, and @code{$}
Cheers...
___
Bug-make mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-make
