Re: GNU make troubleshooting

[Philip Guenther]

I just put this at the very end of top makefile:

${MAKEFILE_LIST}: ;

Philip Guenther

On Sun, Jul 16, 2023 at 12:25 PM Torbjorn SVENSSON <
torbjorn.svens...@foss.st.com> wrote:

>
>
> On 2023-07-16 15:58, Alejandro Colomar wrote:
> > Wow!  That's a great help for debugging the Linux man-pages's makefiles,
> > which don't need to be remade.  It was very painful to me to ignore so
> > much make -d output.  I applied the following patch, and it works like
> > a charm.
> >
> > <
> https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/commit/?id=c98d237c22e9e898ae7d05ee7eac47791bd3
> >
>
> Why are you wasting time doing grep when you can have find return just
> those files that ends with .mk? Also, why need to sort the list when
> it's only for make to define a rule?
>
> I would have done something along these lines if I were in your shoes:
>
> MK := $(srcdir)/Makefile
> MK += $(shell $(FIND) $(MAKEFILEDIR) -type f -name '*.mk')
>
>
> Or, a more cleaner solution would have been to define the MK-array in
> the $(srcdir)/Makefile as you have it hard coded for the include
> statements now.
>
> MK :=   \
> $(MAKEFILEDIR)/check/_.mk   \
> $(MAKEFILEDIR)/check/catman.mk  \
> $(MAKEFILEDIR)/build/_.mk   \
> $(MAKEFILEDIR)/build/catman.mk  \
> $(MAKEFILEDIR)/build/html.mk\
> $(MAKEFILEDIR)/build/pdf.mk \
> $(MAKEFILEDIR)/build/pre.mk \
> $(MAKEFILEDIR)/build/ps.mk  \
> $(MAKEFILEDIR)/build/src.mk \
> $(MAKEFILEDIR)/dist.mk  \
> $(MAKEFILEDIR)/install/_.mk \
> $(MAKEFILEDIR)/install/html.mk  \
> $(MAKEFILEDIR)/install/man.mk   \
> $(MAKEFILEDIR)/lint/_.mk\
> $(MAKEFILEDIR)/lint/c.mk\
> $(MAKEFILEDIR)/lint/man/_.mk\
> $(MAKEFILEDIR)/lint/man/man.mk  \
> $(MAKEFILEDIR)/lint/man/mdoc.mk \
> $(MAKEFILEDIR)/make.mk  \
> $(MAKEFILEDIR)/verbose.mk
>
> include $(MK)
> $(srcdir)/Makefile $(MK):: ;
>
>
> Kind regards,
> Torbjörn
>
>

Re: [bug #63330] readdir() error in 4.4 on Solaris 8

[Philip Guenther]

Is make being built with -D_FILE_OFFSET_BITS=64 to use the large-file
APIs?  If not, then maybe the problem is an inode number that doesn't fit
in the old 32-bit ino_t that some struct dirent's were stuck with.  Check
the output of "ls -l -i" (note the -i option!) to see if there's an inode
number larger than 2billion in the output, like the '..' directory entry
from the NFS parent filesystem...

(You have less than 16 years of use on that Solaris 8 box, as it still has
a 32-bit time_t, which wraps in Jan 2038.  Type fast!)

Philip

On Mon, Nov 7, 2022 at 8:17 PM anonymous  wrote:

> Follow-up Comment #4, bug #63330 (project make):
>
> It looks like this is somehow related to NFS.  I was running the
> newly-generated make in the root of the source tree, and on an NFS mounted
> directory it fails immediately.  If I copy the tree to a local directory I
> have no problems.
>
>
> ___
>
> Reply to this item at:
>
>   
>
> ___
> Message sent via Savannah
> https://savannah.gnu.org/
>
>
>

Re: [bug #63307] make 4.4 passes ignored SIGPIPE on to children

[Philip Guenther]

On Sat, Nov 5, 2022 at 1:34 PM Dmitry Goncharov 
wrote:

> Follow-up Comment #6, bug #63307 (project make):
>
> > If SIGIGN was ignored before make was started though, it should remain
> ignored, even for make's children, see also
>  in
> reply
> to Andreas Schwab's first patch. Correct me if I am wrong, but I think your
> patch re-enables it in that case?
>
> My patch causes the disposition of sigpipe to be set to SIG_DFL in the new
> process. See https://pubs.opengroup.org/onlinepubs/9699919799/,
> specifically
> "Signals set to be caught by the calling process image shall be set to the
> default action in the new process image (see )."
>
> This desire to have the default disposition is intentional. Some of the
> reasons are explained in update 2. Other reasons are the desire to avoid
> complexity in make. Especially when there is no clear need for that
> complexity.
>

This is a change in behavior: previously, make didn't alter the disposition
of SIGPIPE and a build system could set it to SIG_IGN and have all the
invoked recipes inherit that.  As part of saying that make will ignore
SIGPIPE, you've decided to impose a rule that the rest of the build system
has to deal with it in the recipes instead of permitting a pass-through.
That's an unnecessary and user-unfriendly imposition.


In regards to the specific impl of Andreas's 2nd patch there are 2 points.
>
> 1. That patch fails to restore the disposition in the case of make
> re-executing itself (in order to read an updated makefile).
> This could be fixed by calling sigaction before execve, but that'd not be
> atomic.


> 2. That patch uses posix_spawnattr_setsigdefault to set the disposition
> for a
> child process (when make uses posix_spawn). This fails the purpose of the
> patch, if make was invoked with sigpipe disposition of SIG_HOLD.
>

(SIG_HOLD?  That's not a real disposition (in posix) but rather part of an
obsolete version of a mechanism standardized as sigprocmask() and
orthogonal to the disposition (ignore/default/catch).)



> Fixing those deficiencies is not that cheap. In the end, i didn't see any
> benefit for make to go through that trouble of restoring sigpipe
> disposition
> for its children and i proposed this simple fix.
>
> Unlike attempts to restore, one nice property of the sighandler patch is
> that,
> if more calls to exec are introduced to make, the patch will still work for
> all of them.
>

Setting the disposition of SIGPIPE to be caught with a do-nothing routine
is a good idea.  Can you just skip that if the disposition is SIG_IGN at
start?  Then a SIG_IGN will be inherited but the disposition will otherwise
be reset by execve.

Re: please keep up supporting AmigaOS

[Philip Guenther]

Well, the good news is that you have lots of volunteers to test new
versions where you refactor the code to reduce the intrusiveness of the
Amiga changes!

"Hi, you expressed interest in GNU make continuing to support your OS;
here's where you help us reduce the burden of that."  :)

Philip Guenther


On Thu, Nov 3, 2022 at 9:39 AM Paul Smith  wrote:

> On Thu, 2022-11-03 at 19:06 +0100, Henrik Carlqvist wrote:
> > Thank you for joining the group of Amiga users that now are spamming
> > all the subscribers of the GNU mailing list.
>
> It's unfortunate that I asked for responses to the bug-make list
> instead of to my private account: I sort of assumed that folks who
> built "AmigaOS distributions" (etc.) would send a reply if they wanted
> to take on responsibility.
>
> It appears that this info got posted on one or more Amiga news
> aggregators and hence the response from many Amiga users.
>
> I am replying to these messages privately but we'll just have to live
> with the onslaught: these folks don't realize there have already been
> many requests.
>
> Sorry about that!
>
>

Re: [PATCH] [SV 63307] Unignore SIGPIPE in spawned children

[Philip Guenther]

make should note whether SIGPIPE is ignored on entry and, if so, then it
should leave it ignored when it invokes other programs and not
unconditionally set SIGPIPE to SIGDFL.

Philip Guenther


On Wed, Nov 2, 2022 at 6:29 AM Andreas Schwab  wrote:

> * configure.ac: Check for posix_spawnattr_setsigdefault.
> * src/job.c (child_execute_job): Set SIGPIPE to default in the
> child process.
> ---
>  configure.ac |  2 +-
>  src/job.c| 18 ++
>  2 files changed, 19 insertions(+), 1 deletion(-)
>
> diff --git a/configure.ac b/configure.ac
> index 9f688971..30eb2d55 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -134,7 +134,7 @@ AC_CHECK_FUNCS([strtoll strdup strndup stpcpy memrchr
> mempcpy umask mkstemp \
>  getgroups seteuid setegid setlinebuf setreuid setregid \
>  mkfifo getrlimit setrlimit setvbuf pipe strerror
> strsignal \
>  lstat readlink atexit isatty ttyname pselect posix_spawn \
> -posix_spawnattr_setsigmask])
> +posix_spawnattr_setsigmask posix_spawnattr_setsigdefault])
>
>  # We need to check declarations, not just existence, because on Tru64 this
>  # function is not declared without special flags, which themselves cause
> diff --git a/src/job.c b/src/job.c
> index b78f279c..621ff899 100644
> --- a/src/job.c
> +++ b/src/job.c
> @@ -2305,6 +2305,11 @@ child_execute_job (struct childbase *child, int
> good_stdin, char **argv)
>/* We are the child.  */
>unblock_all_sigs ();
>
> +  /* Unignore SIPIPE.  */
> +#ifdef SIGPIPE
> +  bsd_signal (SIGPIPE, SIG_DFL);
> +#endif
> +
>  #ifdef SET_STACK_SIZE
>/* Reset limits, if necessary.  */
>if (stack_limit.rlim_cur)
> @@ -2347,6 +2352,19 @@ child_execute_job (struct childbase *child, int
> good_stdin, char **argv)
>}
>  #endif /* have posix_spawnattr_setsigmask() */
>
> +  /* Unignore SIGPIPE.  */
> +#ifdef HAVE_POSIX_SPAWNATTR_SETSIGDEFAULT
> +  {
> +sigset_t mask;
> +sigemptyset (&mask);
> +sigaddset (&mask, SIGPIPE);
> +r = posix_spawnattr_setsigdefault (&attr, &mask);
> +if (r != 0)
> +  goto cleanup;
> +flags |= POSIX_SPAWN_SETSIGDEF;
> +  }
> +#endif
> +
>/* USEVFORK can give significant speedup on systems where it's
> available.  */
>  #ifdef POSIX_SPAWN_USEVFORK
>flags |= POSIX_SPAWN_USEVFORK;
> --
> 2.38.1
>
>
> --
> Andreas Schwab, SUSE Labs, sch...@suse.de
> GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
> "And now for something completely different."
>
>

Re: Implicit rule for linking multiple object files

[Philip Guenther]

The first place to consult in understanding how to build your code is the
documentation of your compiler.  C++20 *module* support is very new in at
least gcc and they have not provided direct guidance on how to use modules
with 'make', at least I don't see any such guidance here:

https://gcc.gnu.org/onlinedocs/gcc-12.1.0/gcc/C_002b_002b-Modules.html#C_002b_002b-Modules

Instead they have a link to an outside whitepaper.  Ideally, the gcc
developers would work with the GNU make developers to provide rules and
documentation that would solve your problems.  They have not yet done so.
Your choices are:
 * to work it out
 * to wait until they provide that guidance
 * to find another compiler and/or build system

To be blunt, the questions you're asking about make behavior indicate that
it will require a dedicated effort for you to develop the correct rules
yourself.  While at least one workaround has already been proposed (declare
a.o, b.o, c.o, and d.o. as prerequisites of main.o) that is almost
certainly specific to the modules and classes involved here and if this
project grows a more complex module/class layout additional, possibly
conflicting rules will be required.  A solution which is robust to future
code/design changes really requires a broad view of the dependency
structure of the C++ module implementation...which is where guidance from
the C++ compiler developers would *really* be useful.

Good luck.

Philip Guenther


On Wed, Aug 10, 2022 at 9:19 PM ljh  wrote:

> Hi Paul,
>
> I don't know if this is related to gcc support of c++20.
> But mentioning target.o ("x.o") and recipe or not in my Makefile, does
> have different result. My test follows.
>
> Thanks
>
>
> ---
>
> 1. error: with target.o ("x.o"), without recipe
>
>
> $ ls
>  a.cpp   b.cpp   c.cpp   d.cpp   main.cpp   Makefile
> $
> $ cat Makefile
> CXXFLAGS = -Wall -Wextra -std=c++2a -fmodules-ts -g # -O3 -fPIC
> main : c.o b.o a.o d.o main.o
> #   $(CXX) $^ -o $@
> $ make
> g++ -Wall -Wextra -std=c++2a -fmodules-ts -g-c -o main.o main.cpp
> In module imported at main.cpp:1:1:
> A: error: failed to read compiled module: No such file or directory
> A: note: compiled module file is ‘gcm.cache/A.gcm’
> A: note: imports must be built before being imported
> A: fatal error: returning to the gate for a mechanical issue
> compilation terminated.
> make: *** [: main.o] Error 1
> $
>
>
> 2. ok: without target.o and recipe
>
>
> $ rm -fr *.o gcm.cache main
> $ cat Makefile
> CXXFLAGS = -Wall -Wextra -std=c++2a -fmodules-ts -g # -O3 -fPIC
> main : c.o b.o a.o d.o # main.o
> #   $(CXX) $^ -o $@
> $ make
> g++ -Wall -Wextra -std=c++2a -fmodules-ts -g-c -o c.o c.cpp
> g++ -Wall -Wextra -std=c++2a -fmodules-ts -g-c -o b.o b.cpp
> g++ -Wall -Wextra -std=c++2a -fmodules-ts -g-c -o a.o a.cpp
> g++ -Wall -Wextra -std=c++2a -fmodules-ts -g-c -o d.o d.cpp
> g++ -Wall -Wextra -std=c++2a -fmodules-ts -g main.cpp c.o b.o a.o d.o
>   -o main
> $
>
>
> 3. ok: with target.o and recipe
>
>
> $ rm -fr *.o gcm.cache main
> $ cat Makefile
> CXXFLAGS = -Wall -Wextra -std=c++2a -fmodules-ts -g # -O3 -fPIC
> main : c.o b.o a.o d.o main.o
> $(CXX) $^ -o $@
> $ make
> g++ -Wall -Wextra -std=c++2a -fmodules-ts -g-c -o c.o c.cpp
> g++ -Wall -Wextra -std=c++2a -fmodules-ts -g-c -o b.o b.cpp
> g++ -Wall -Wextra -std=c++2a -fmodules-ts -g-c -o a.o a.cpp
> g++ -Wall -Wextra -std=c++2a -fmodules-ts -g-c -o d.o d.cpp
> g++ -Wall -Wextra -std=c++2a -fmodules-ts -g-c -o main.o main.cpp
> g++ c.o b.o a.o d.o main.o -o main
> $
>
> $ make --version
> GNU Make 4.3
> Built for x86_64-pc-linux-gnu
> Copyright (C) 1988-2020 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <
> http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
> $
>
>
> -- 原始邮件 --
> *发件人:* "psmith";
> *发送时间:* 2022年8月11日(星期四) 凌晨2:31
> *收件人:* "ljh"; "bug-make";
> *主题:* Re: Implicit rule for linking multiple object files
>
> On Thu, 2022-08-11 at 01:58 +0800, ljh wrote:
> > I have three c source files: x.c, y.c, z.c and I name x as the target
> > on left. Can I put x.o in the prerequisites on the right too? Are
> > they the same, with or without x.o in the prerequisites on the right?
> >
> > x: y.o z.o x.o  # with x.o
>
> It is correct to do this.
>
> These two rules do not behave exactly the same:
>
>   x: y.o z.o
>
> versus
>
>   x: y.o z.o x.o
>
> (you can see the difference for yourself by running &quo

Re: Goodbye to GNU make's "build.sh" ... ?

[Philip Guenther]

On Sat, Jun 25, 2022 at 12:48 PM Paul Smith  wrote:

> I'm trying to decide what the future is for GNU make's "build.sh"
> bootstrapping script. As you may recall, this script is provided to
> allow GNU make to build on systems which don't already have an instance
> of make installed. Its goal is to build the first make binary, without
> of course all the fancy parts of avoiding rebuilds, generating
> dependency files, etc.
>

Can anyone contribute information about actual cases where build.sh was
used?

I've been using GNU make since 1992 or so, on only 9 or so different  UNIX
platforms, but they all had _some_ form of make available, however
crippled, that was sufficient to bootstrap GNU make.  So, I've avoided
being its target audience.  Who has been and can they speak to what they
would do without it?  "I have a native compiler, but not make" is kinda a
weird place to be; those bootstrapping a new OS typically cross-compile the
entire toolchain until they can self-host: make is just another small divot
in that bumpy road and using build.sh when they still have to cross-compile
the rest of the toolchain doesn't actually help.


This leaves me with two options:
>
>1. Stop using gnulib, or at least sharply limit the modules we will
>   include to those with trivial-enough configurations.
>2. Abandon the build.sh script and require an existing make program
>   in order to build a new version of GNU make.


Lacking a description of a case in the past where build.sh was actually the
only sane option, I would go with #2.


Philip Guenther

Re: sub makefile does not use correct value of CFLAGS from top make file,

[Philip Guenther]

Unlike variable assignments, rules--including overrides of built-in pattern
rules--are not inherited by recursively invoked instances of make.  They
have to be in a makefile read by the instance of make that needs them.

(GNU makes built-in rules and variables have TARGET_ARCH for basically all
types of compilation.  IMHO, if you have options that don't apply to, for
example, .S files, then why not put them in CFLAGS *directly* and not in
TARGET_ARCH?  Or just use your own variable name (e.g., "targ_arch")
instead of trying to give your own use/meaning to a variable which is
already in use.  Fighting the builtin rules is a bad use of your time.)


Philip Guenther

On Fri, Sep 3, 2021 at 12:58 PM Jeffrey.Fellin--- via Bug reports and
discussion for GNU make  wrote:

> I have a project that compiles .S and .c files, and the value of CFLAGS in
> the sub makefile is not the same for the compile lines
>
>
>
> The version of make is
>
> GNU Make 3.82
>
> Built for x86_64-redhat-linux-gnu
>
> Copyright (C) 2010  Free Software Foundation, Inc.
>
>
>
> I’m attaching a tarball containing the following files, for ease in
> reproducing the problem
>
> cflags_bug/make_top
>
> cflags_bug/base/sub_make
>
> cflags_bug/base/src/bug.S
>
> cflags_bug/base/src/hello.c
>
>
>
> The compile of bug.S succeeds, but doesn’t have the correct value of
> CFLAGS, as in the annotated output below. The compile of hello.c has the
> correct value of CFLAGS, but the compile fails due to the unsupported
> options to the cc. The extra options are for use by the project specific
> compiler.
>
>
>
> The top make undefines the default rules for %.o:%.c and %.o:%.S, has my
> understanding from these documents:
>
> Managing Projects with BNU Make, Third Edition,
>
> GNU Make pdf, Section 10.5.5 Match-Anything Pattern Rules
>
>
>
> The annotated execution of make -f make_top, supplied in the cflags_bug.tar
>
> $ make -ikf make_top;exit
>
> (cd base && make -f sub_make all)
>
> make[1]: Entering directory `/home/jfellin/cflags_bug/base'
>
> # This displays the value of CFLAGS that should be use in the
>
> # compilation of the .S and .c files
>
> # the compile errors are not important, but the different
>
> # value of CFLAGS, which are expected to be the same.
>
>
>
> # Also note the top make file removes the default rule for %.o:%.[Sc], but
>
> # the default rules are still being used.
>
>
>
> # Expected value in compile *.S and *.c
>
> check CFLAGS=-DTOP_MAKE -Wall -I base/inc -mlittle-endian
> --target=aarch64-arm-none-eabi -mcpu=cortex-a53+nocrypto+nofp+nosimd
> -mno-unaligned-access -mfpu=None-O  -MD -I
> /home/jfellin/cflags_bug/base/../base/inc  -D BASE_MAKE
>
>
>
>
>
> # Note this value of CFLAGS is not the one printed above
>
> cc-c -o /home/jfellin/cflags_bug/base/../base/src/bug.o
> /home/jfellin/cflags_bug/base/../base/src/bug.S
>
>
>
>
>
> # Note this value of CFLAGS is the one printed by the check_cflag rule
>
> # in the file, sub_make,
>
> cc -DTOP_MAKE -Wall -I base/inc -mlittle-endian
> --target=aarch64-arm-none-eabi -mcpu=cortex-a53+nocrypto+nofp+nosimd
> -mno-unaligned-access -mfpu=None-O  -MD -I
> /home/jfellin/cflags_bug/base/../base/inc  -D BASE_MAKE  -mlittle-endian
> --target=aarch64-arm-none-eabi -mcpu=cortex-a53+nocrypto+nofp+nosimd
> -mno-unaligned-access -mfpu=None -c -o
> /home/jfellin/cflags_bug/base/../base/src/hello.o
> /home/jfellin/cflags_bug/base/../base/src/hello.c
>
> cc: warning: \u2018-mcpu=\u2019 is deprecated; use \u2018-mtune=\u2019 or
> \u2018-march=\u2019 instead
>
> cc: warning: \u2018-mcpu=\u2019 is deprecated; use \u2018-mtune=\u2019 or
> \u2018-march=\u2019 instead
>
> cc: error: unrecognized command line option \u2018-mlittle-endian\u2019
>
> cc: error: unrecognized command line option
> \u2018-mno-unaligned-access\u2019
>
> cc: error: unrecognized command line option \u2018-mfpu=None\u2019
>
> cc: error: unrecognized command line option \u2018-mlittle-endian\u2019
>
> cc: error: unrecognized command line option
> \u2018-mno-unaligned-access\u2019
>
> cc: error: unrecognized command line option \u2018-mfpu=None\u2019
>
> make[1]: [/home/jfellin/cflags_bug/base/../base/src/hello.o] Error 1
> (ignored)
>
> make[1]: Leaving directory `/home/jfellin/cflags_bug/base'
>
>
>
> Jeff
>
>
>

Re: GNU make man page typo

[Philip Guenther]

On Thu, Sep 2, 2021 at 5:07 AM Zach Petch  wrote:

> This is minor in the grand scheme of things, but I noticed a typo in the
> man page for GNU make. In case it makes a difference, I was on a Mac
> running macOS Big Sur 11.5.2 when I came across the typo.
>
> The second paragraph under DESCRIPTION reads,
>
> > To prepare to use make, you must write a file called the makefile that
> describes the relationships among files in your program, and the states the
> commands for updating each file.
>
> It appears that the first use of "the" after the second comma should
> either be "then" or quite possibly should simply not exist at all. That
> portion of the sentence would then read either,
>
> > and then states the commands for updating each file
>
> or,
>
> > and states the commands for updating each file
>
> and would, at the very least, reduce the likelihood of people like myself
> (who need to read slowly and carefully to understand things like man pages)
> from getting temporarily tripped up by the wording of that line.
>
> I recognize that this is minor and somewhat pedantic, but I appreciate you
> taking the time to read this.
>

I'm pretty sure that it was a typo/thinko for "that states", making the
full sentence:

To prepare to use make, you must write a file called the makefile that
describes the relationships among files in your program and that states the
commands for updating each file.


I also think the second comma is incorrect ("comma splice") and suggest
removing it as seen above: even the 'Oxford comma' rule only applies to
lists of three or more items.

Philip Guenther

Re: [bug] Sibling submakes: wait for other submakes before failing

[Philip Guenther]

On Sun, Jun 13, 2021 at 6:29 PM David A. Wheeler 
wrote:

> > On Jun 13, 2021, at 5:44 PM, Alejandro Colomar (man-pages) <
> alx.manpa...@gmail.com> wrote:
> >
> > Let's say there's a project with a submake for each module.
>
> It’s counter-intuitive, but it is usually *MUCH* faster & more accurate to
> have a single make process
> figure things out in most cases than to use recursive makes.
>
> For more info, see “Recursive make considered harmful” by Peter Miller:
>
> https://web.archive.org/web/20200209034547/http://aegis.sourceforge.net/auug97.pdf


+1000

In October 2001 I applied the logic of that paper to a 1/2 million line
work project to cut its build time by a factor of 20 and make it reliably
build the Right Stuff.  Took less than a month to win back the entire time
I had spent reading the paper and working out the details of the new
Makefile setup.


Philip Guenther

Re: bug

[Philip Guenther]

The GNU make manual describes when it intentionally returns an exit status
of two.  If you think it returned that status when it shouldn't, you'll
need to fully describe the context (Makefile contents, what files were
present that the Makefile could have referenced) so that other people can
understand _why_ that exit status was incorrect.

Philip Guenther



On Mon, Mar 29, 2021 at 10:16 PM Prashant Upadhyay 
wrote:

> Process terminated with status 2 (0 minute(s), 0 second(s))
> 0 error(s), 0 warning(s) (0 minute(s), 0 second(s))
>
> regards
> --
>
> [image: Somaiya Logo] <https://kjsieit.somaiya.edu.in> 
> Prashant
> Upadhyay
> ASSISTANT PROFESSOR
> Follow us :   [image: Somaiya Logo]
> <https://www.facebook.com/kjsieitofficial> [image: Somaiya Logo]
> <https://www.instagram.com/kjsieit_22> [image: Somaiya Logo]
> <https://twitter.com/kjsieit1> [image: Somaiya Logo]
> <https://www.linkedin.com/in/kjsieit> [image: Somaiya Logo]
> <https://www.youtube.com/kjsieitofficial>
>
> <https://www.somaiya-ayurvihar.org/en>   <http://www.nareshwadi.org/en>
> <http://www.somaiya.org/>   <http://www.helpachild.org.in/>
> <http://www.nareshwadi.org/en>
>

Re: [bug #60281] Directory in directory in $PATH shadows binaries in $PATH

[Philip Guenther]

For the record, POSIX specifies that only normal files are considered when
searching $PATH, so even though the directory is executable (heh), ignoring
it is absolutely the correct thing.

Philip Guenther

On Tue, Mar 23, 2021 at 12:50 PM anonymous  wrote:

> URL:
>   <https://savannah.gnu.org/bugs/?60281>
>
>  Summary: Directory in directory in $PATH shadows binaries
> in
> $PATH
>  Project: make
> Submitted by: None
> Submitted on: Tue 23 Mar 2021 09:50:35 PM UTC
> Severity: 3 - Normal
>   Item Group: Bug
>   Status: None
>  Privacy: Public
>  Assigned to: None
>  Open/Closed: Open
>  Discussion Lock: Any
>Component Version: 4.3
> Operating System: POSIX-Based
>Fixed Release: None
>Triage Status: None
>
> ___
>
> Details:
>
> = What's happening =
>
> If you have a directory in a directory specified in the PATH environment
> variable which shares a name with a command you want to run, that directory
> will shadow the actual binary and you will get a permission denied error.
>
> Example setup:
>
> # prepend /home/user/bin to path
> export PATH=/home/user/bin:/usr/bin
> # create directory /home/user/bin/cat
> mkdir /home/user/bin/cat
> # create our testfile for cat
> touch ./temp.txt
>
>
> In Makefile
>
> .PHONY: myrule
> myrule:
> cat temp.txt
>
>
> Make now attempts to exec the directory /home/user/bin/cat instead of
> /usr/bin/cat:
>
> user@host:~$ make
> cat temp.txt
> make: cat: Permission denied
> make: *** [Makefile:2: myrule] Error 127
>
>
>
> = What should be happening =
>
> Make should exec /usr/bin/cat
>
>
>
>
>
> ___
>
> Reply to this item at:
>
>   <https://savannah.gnu.org/bugs/?60281>
>
> ___
>   Message sent via Savannah
>   https://savannah.gnu.org/
>
>
>

Re: bug report

[Philip Guenther]

On Wed, Mar 3, 2021 at 1:00 PM Goran V.  wrote:

> Am Mittwoch, den 03.03.2021, 15:41 -0500 schrieb Paul Smith:
> > If by "a feature like that" you mean a way to create multiple pattern
> > rules with a single rule definition in the makefile, then obviously
> > this would require some new syntax but assuming that syntax existed I
> > don't see why it would break anything.
>
> Yes, that is what I mean with "a feature like that". But I must say
> that I'm in no position to propose a patch as make is huge,
> http://git.savannah.gnu.org/cgit/make.git/tree/ .
>

This can be emulated in current GNU make via a function and a variable to
hold the commands.

To get the effect you wanted, you would define this function in one place,
before any use of it:

independent_patterns = $(foreach target, $1, $(eval ${target}: ${2};
$(value $(strip $3


Then, instead of writing what you tried:

$(BUILD)/$(FRONTEND)/%.html \
$(BUILD)/$(FRONTEND)/%.js   \
$(BUILD)/$(FRONTEND)/%.css  \
$(BUILD)/$(FRONTEND)/%.svg  \
$(BUILD)/$(FRONTEND)/%.ico:
@echo -n "$(FRONTEND) - building $@"
@$(MD) $(BUILD)/$(FRONTEND)
@cp $(FRONTEND)/$(@F) $@
@echo " ...done"

You would write this:

define cmds
@echo -n "$(FRONTEND) - building $@"
@$(MD) $(BUILD)/$(FRONTEND)
@cp $(FRONTEND)/$(@F) $@
@echo " ...done"
endef
$(call independent_patterns, \
$(BUILD)/$(FRONTEND)/%.html \
$(BUILD)/$(FRONTEND)/%.js   \
$(BUILD)/$(FRONTEND)/%.css  \
$(BUILD)/$(FRONTEND)/%.svg  \
$(BUILD)/$(FRONTEND)/%.ico, , cmds)


Not the most obvious, friendly syntax, but it appears to do what you're
trying to accomplish.


Philip Guenther

Re: [PATCH] Add the --nice argument to make

[Philip Guenther]

On Mon, Sep 16, 2019 at 4:17 PM Palmer Dabbelt  wrote:

> I call make quite regularly, and I almost always want to invoke it with
> at least a bit of nice to avoid it eating my whole machine.  Since I can
> stick "-j$(nproc)" in my shell's default MAKEFLAGS I frequently end up
> being lazy and just typing "make", which I then have to kill in order to
> re-run as "nice -n10 make".
>

This sounds like a perfect case to use a shell alias or function in your
shell's rcfile, or a shell script in your person bin directory.  i.e.,
something like
alias make='nice -n10 make'
or maybe
make() { nice -n10 /usr/bin/make "$@"; }


Philip Guenther
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: lex implicit rule chain is broken

[Philip Guenther]

On Sat, May 18, 2019 at 10:30 PM Mohamed Akram 
wrote:

> Thanks for the tip. I'm not sure why it doesn't just fail immediately
> then, instead of taking a few steps and stumbling on itself.
>

In order to fail early, make would have to assume it knows more than you
do, but it's just a dumb program and you might be doing something unusual
but perfectly legal.  How can make know whether the compiler/link on your
system does something special with .l files, beyond the normal
interpretation as lex files?

Just out of curiosity, I tested the same thing with FreeBSD make
> (`LDFLAGS=-ll make`) and it compiled `lang` as expected with this output:
>

The short answer is that FreeBSD make uses '$<' in the recipe of the
applicable .c: pattern rule, while GNU make use '$^' in the parallel rule.

Note that FreeBSD make doesn't actually require the dependency: you get the
same results when the makefile is just
   lang:

Philip Guenther
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: lex implicit rule chain is broken

[Philip Guenther]

On Sat, May 18, 2019 at 9:07 PM Mohamed Akram 
wrote:

> echo "lang: lang.l" > Makefile
>

This Makefile is incorrect, as it tells make that 'lang.l' is a *direct*
dependency of lang.  That's not true: lang.l has to be run through lex to
get a .c file that can compiled to get lang.



> It tries to link the .l file.
>

make doesn't need any special instructions to tell it how to generate an
executable from a .l file, but it'll do the Wrong Thing if you tell it the
wrong thing.  To achieve your apparent goal you can simply run it with *no*
Makefile and give it the name of the matching executable (ala "make lang"
in this case) or use a Makefile sets the default target ala
   echo ".DEFAULT_GOAL = lang" >Makefile
and it'll deduce the rest from its default pattern rules.


Philip Guenther
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: [bug #51311] Checking search retries for implicit make rules

[Philip Guenther]

On Sun, 25 Jun 2017, Mike Gran wrote:
> Follow-up Comment #1, bug #51311 (project make): You've opened this as a 
> bug. I believe it is not a bug.  Again. I'm not a maintainer.
> 
> Please note two things.
> 
> 1. while "MOTD%.log: MOTD%.txt" is a pattern rule, "MOTD%.log: MOTD%.txt
> MOTD%.in" is not a pattern rule, because it has two entries after the colon. 

This is incorrect.  To quote the make info pages, section 10.5.1
"Introduction to Pattern Rules":
-
A pattern rule contains the character `%' (exactly one of them) in the
target; otherwise, it looks exactly like an ordinary rule.  The target
is a pattern for matching file names; the `%' matches any nonempty
substring, while other characters match only themselves.  
-

There's no restriction in the documention on the number of prequisites on 
the rule and they may contain any mix of pattern and non-pattern names.  
See that page and the others in that section for further details.



> 2. The '%' (the stem) in a pattern rule doesn't, if I recall correctly, match
> a null string.  It needs to match at least a single character, so building
> MOTD.log won't work.

This is correct, as per the documentation quoted above.


Philip Guenther

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: Checking alternatives for a dynamic make rule construction

[Philip Guenther]

On Thu, 15 Jun 2017, SF Markus Elfring wrote:
> I have constructed the following small script to be executed by the program
> “GNU Make 4.2.1-1.7” on my openSUSE Tumbleweed system.
> 
> 
> define rule_pair =
> name::=$(1)

Using ::= in a makefile which is already dependent on GNU make is, IMO, 
pointless.  If you're using $(eval) and $(call) then you should rename 
this file to GNUmakefile and just use := because it's portable across 
practically all versions of GNU make.  It's free to you annd it'll make 
developers on non-Linux systems more happy since you'll have signalled the 
GNU make requirement directly.


> $$(name:.ml=.cmo): $$(name)
>   $$(OCAMLC_CMD) -c $$<
> 
> $$(name:.ml=.cmx): $$(name)
>   $$(OCAMLOPT_CMD) -c $$<
> endef
>
> $(foreach x,$(SRC_without_mli),$(eval $(call rule_pair,$(x
> 
> 
> I guess that the functionality from this approach is similar to the 
> usage of two specific suffix rules. But I would like to distinguish the 
> involved software dependencies better.
> 
> 
> I imagine that it would be nice to improve the shown implementation 
> details.
> 
> 1. I am using the extra variable “name” just for the reuse of the make
>functionality “substitution references”.

You can substitution references with ${1} directly, ala ${1:.ml=.cmo}


>I would prefer to append desired file name suffixes directly instead 
>of replacing a previous one. Can the passed text list become a bit 
>smaller eventually?

I *think* you're asking whether rule_pair could take just the bare 
basename (ala "commands" instead of "commands.ml").  If so, then sure: a 
substitution reference could have an empty replacement part:
${1:=.cmo}

will expand to "commands.cmo" if $1 is "commands"


> 2. The specification “$$(name)” is working. Would it make sense to avoid
>such a variable reference there? Unfortunately, the simple 
>specification “$(1)” does not work in the way I would expect for the 
>selection of a single file as a dependency. Would you like to explain 
>this software behaviour?

I started to write a long explanation of how $(eval) works but then 
realized it didn't explain when $(1) didn't work for you.

So: nope, can't explain the error message you saw, because it makes *no 
sense* to me why it didn't work based on what you wrote.

In case the theme of my replies isn't 100% clear: it would be a *lot* 
easier to assist you if you included the complete input you tried, the 
complete output you got, and *what you expected/desired*.

Or we can guess, and then give up and go away.


Philip

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: Checking application of dependencies from make rules without recipes

[Philip Guenther]

On Fri, 16 Jun 2017, SF Markus Elfring wrote:
> I got some special software development experiences by the usage of the 
> program “GNU Make 4.2.1-1.7” on my openSUSE Tumbleweed system. The 
> functionality “Generating prerequisites automatically” is desribed in 
> the manual. I would like to check again how good this works at the 
> moment.
> 
> I am trying also a software out where such build dependencies are 
> provided by the tool “ocamldep”. Unfortunately, I observe still broken 
> build tries because of missing files which should have been built 
> before. I started to “fix” this for my needs by the addition of small 
> make functions which construct extra rules. But it seems that such 
> special stuff should usually not be needed according to the 
> documentation.
> 
> I would appreciate further advice for this issue.

Could you provide examples of the Makefiles rules you tried?  It's very 
difficult to provide feedback without complete information.  Does ocamldep 
generate output suitable for inclusion by make?  What rule did you use to 
invoke it?


Philip Guenther

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: Checking software build tries for “commands.cmo”

[Philip Guenther]

On Thu, 15 Jun 2017, SF Markus Elfring wrote:
> > Did you tell make, then, to disable all of its default rules for 
> > creating commands.mli or, for that matter, commands.cmo, by checking 
> > them out of version control?
> 
> Not directly so far. - The source file “commands.mli” is not needed for 
> the generation of the object module “commands.cmo” in the final use 
> case.

I believe the point of Martin's rhetorical query is "why should make treat 
the failure of *this* pattern rule any different than the failure of the 
many other pattern rules that would have permitted this compilation to 
complete?"

If comands.ml,v had existed, then the make command you had invoked would 
have completed, because make would have invoked the
%:: %,v
rule and then the rule you supplied.  Alternatively, if commands.cmo,v 
have existed, then make could have used that to generate commands.cmo 
directly, so why shouldn't it say
The target “commands.cmo” could not be built because the specified
dependency “commands.cmo,v” did not exist.
?


You *looked at* the the "make -d" output and saw the long list of files 
that make considered as possible prerequisites for building command.cmo; 
if *any* of those existed then make would have been able to build the file 
and complete your request.

If you want to change the error messages that make generates, you have to 
look at that list coldly and without passion and say "is there a rule that 
improves the error output in this case?  Is that output at least as good 
for *other* makefiles?"  If the answers aren't both "yes", then you're 
suggesting a trade-off of your makefile for someone else's and have this 
consider and explain *why* their usage may be made worse to make yours 
better.


Philip Guenther

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: Checking software build tries for “commands.cmo”

[Philip Guenther]

On Thu, 15 Jun 2017, SF Markus Elfring wrote:
> > (I would guess that most of the people on the bug-make mailing list have 
> > never worked with ocaml and therefore don't know what needs to be done to 
> > build it.)
> 
> Yesterday I realised that one source source file needed a special handling
> in the mentioned subdirectory.
> 
> 
> > The snippet of Makefile you provided didn't include any rules for 
> > building "commands.ml", so I don't understand why you expect make to 
> > build it.
> 
> The suffix “ml” denotes a source file in this use case.
> 
> I needed another moment to become really aware that this software module
> is a bit special. It seems that it is intended that it will be compiled
> without a corresponding interface description file (suffix “mli”).

Well, I'm totally lost.  Here's why:

You told make ".cmo files can be built from *THE COMBINATION OF* the 
matching .cmi and .ml files, but *only* if both the files exist or can be 
built via some other rule".  That is what this rule says:

%.cmo: %.ml %.cmi
   $(OCAMLC_CMD) -c $<

Now you're saying that commands.cmo could be built from *just* 
commands.cmi without commands.ml!  If the real rule is that .cmo files can 
be built from .cmi files (and they _sometimes_ depend on .ml files) then 
the multi-dependency rule you used should be replaced with the single 
dependency rule:

%.cmo: %.cmi
   $(OCAMLC_CMD) -c $<

...and the additional dependency of whatever.cmo on whatever.ml should be 
expressed separately...or even automatically generated like what is done 
in modern C projects.

Indeed, do .cmo files sometimes depend on _other_ .ml files, such that 
"foo.cmo" might need to be rebuilt if "bar.ml" changes?  If so, then you 
might just have too many dependencies but all too few and should be 
looking at the direction make-for-C went to solve this.


Philip Guenther

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: Checking software build tries for “commands.cmo”

[Philip Guenther]

On Tue, 13 Jun 2017, SF Markus Elfring wrote:
> I am testing the following pattern rules with the program “GNU Make 4.2.1-1.7”
> on my openSUSE Tumbleweed system as I would like to adjust some areas
> in affected make scripts for another evolving software tool.
> 
> …
> %.cmi: %.mli
>   $(OCAMLC_CMD) -c $<
> 
> %.cmo: %.ml %.cmi
>   $(OCAMLC_CMD) -c $<
> 
> %.cmx: %.ml %.cmi
>   $(OCAMLOPT_CMD) -c $<
> …
> 
> I have tried a specific command out.
> 
> elfring@Sonne:~/Projekte/Coccinelle/20160205/commons> LANG=C make -d 
> common.cmo V=1 
...
> This test showed the expected results.

Two questions:
1) What files were present in the directory before you ran that command?
2) What _was_ that expected result?

(I would guess that most of the people on the bug-make mailing list have 
never worked with ocaml and therefore don't know what needs to be done to 
build it.)


> I have tried another command variant out.
> 
> elfring@Sonne:~/Projekte/Coccinelle/20160205/commons> LANG=C make -d 
> commands.cmo V=1
...
> Now I wonder why I do not get the desired software generation results for
> this test case. Why is the source file “commands.ml” not compiled again
> in the way as the other one?

The snippet of Makefile you provided didn't include any rules for building 
"commands.ml", so I don't understand why you expect make to build it.


Philip Guenther

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: Non existing target not marked as new

[Philip Guenther]

On Wed, Feb 8, 2017 at 5:48 AM, Raz Manor  wrote:
> I created a makefile using instructions for this post:
> http://make.mad-scientist.net/papers/advanced-auto-dependency-generation/
>
> To test it, I make all my files, then deleted one .d file and touched one of
> the header files present in that .d file.
>
> The target, however, was not rebuilt.
>
>
>
> Running with -d, I found that the empty rule to make %.d files, ran the
> first time the %.d file was needed, in the -include directive.
>
> Than the target was marked as built by make, so the second time it was
> needed, when building the .o file, the empty recipe was not re-run.
>
> However, since the .d file still didn’t exist, the .o file was not rebuilt.
>
>
>
> The author of the article was assuming that if a target is marked as built,
> all the target it's their prerequisite will also be rebuilt, regardless of
> the actual state of the target.
>
> Was he mistaken?
>
> If so, is this a bug, or the intended behavior?
>
> I this is the intended behavior, how can I achieve the same affect?

I started to try to guess at the problem, but that's a waste of time
when you could just copy your test Makefile in to email to the list.


Philip Guenther

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: exported vs command line variables

[Philip Guenther]

On Fri, Sep 23, 2016 at 4:09 PM, David Boyce  wrote:
> In that case there does seem to be at least one bug here. In reference to
> the sentence:
>
> "Macros defined by the MAKEFLAGS environment variable and macros defined in
> the makefile(s) shall not be added to the environment of make if they are
> not already in its environment."
>
> And building on Eddy Welbourne's example:
>
> % cat Makefile
> WURGLE = 11
> MAKEFLAGS = WURGLE=$(WURGLE)

You need to read all the applicable bits in the standard before
calling behavior incorrect.  In particular, the Macros section has
this line earlier in it:
The result of setting MAKEFLAGS in the Makefile is unspecified.

So if you want POSIX-like behavior, don't do that; if you do that,
you're at the whims of GNU make's choices.


Philip Guenther

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: exported vs command line variables

[Philip Guenther]

On Fri, Sep 23, 2016 at 11:23 AM, Paul Smith  wrote:
> On Fri, 2016-09-23 at 05:52 -0700, David Boyce wrote:
>> I still think that's a good plan, except that now I find out it ends
>> up exporting anyway. I'm sure it's too late to change now but is
>> there a reason for this (unfortunate IMHO) behavior?
>
> I can't tell you: this behavior has existed since the very first import
> of GNU make code into source code control, back in 1991.

...and in System III in 1980:
http://minnie.tuhs.org/cgi-bin/utree.pl?file=SysIII/usr/src/cmd/make

Looks like BSD picked it up in 4.4 around 1993 with the switch to pmake:
http://minnie.tuhs.org/cgi-bin/utree.pl?file=4.4BSD/usr/src/usr.bin/make


POSIX specifies this behavior in the "Macros" subsection of the
EXTENDED DESCRIPTION section for 'make'.  About a page and half in is
this paragraph:
Before the makefile(s) are read, all of the make utility command
line macro definitions (except the
MAKEFLAGS macro or the SHELL macro) shall be added to the
environment of make. Other
+   implementation-defined variables may also be added to the
environment of make. Macros
+  defined by the MAKEFLAGS environment variable and macros defined in
the makefile(s) shall
+   not be added to the environment of make if they are not already in
its environment. With the
+   exception of SHELL (see below), it is unspecified whether macros
defined in these ways update
the value of an environment variable that already exists in the
environment of make.

(That's from the 2013 draft update; the '+' lines were modified from
the original 2008 version of the standard, but that doesn't affect the
first sentence.)


Philip Guenther

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: [bug #49093] ifdef checks for non-empty value, not definition

[Philip Guenther]

On Wed, Sep 14, 2016 at 3:13 PM, Paul D. Smith  wrote:
...
> Probably an example like this would help make the doc more clear.

There *is* an example like that in the doc in at least version 4.2.1!

 Note that `ifdef' only tests whether a variable has a value.  It
 does not expand the variable to see if that value is nonempty.
 Consequently, tests using `ifdef' return true for all definitions
 except those like `foo ='.  To test for an empty value, use
 `ifeq ($(foo),)'.  For example,

  bar =
  foo = $(bar)
  ifdef foo
  frobozz = yes
  else
  frobozz = no
  endif

 sets `frobozz' to `yes', while:

  foo =
  ifdef foo
  frobozz = yes
  else
  frobozz = no
  endif

 sets `frobozz' to `no'.

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: disparity in Paul’s Rules

[Philip Guenther]

On Wed, Feb 18, 2015 at 5:01 PM, David Boyce  wrote:
> Am I missing something or is one of the iconic “Paul’s Rules of
> Makefiles” a little wrong (or outdated)? Rule 5 at
> http://make.mad-scientist.net/papers/rules-of-makefiles/ says:
>
> "Every non-continued line that starts with a TAB is part of a command
> script–and vice versa.”
>
> But it’s not really as simple as that. Consider this test makefile:
>
> % cat makefile
> AA = 12
> BB #= 42
>
> .PHONY: all
> all:
> @echo "AA=$(AA) BB=$(BB)”
>
> The BB line is prefixed with a tab and is not continued. With the
> comment character in place it provides a ‘recipe commences before
> first target. Stop.’ error but with the # removed it’s treated as a
> valid variable assignment despite the leading tab:
...
> So maybe Rule 5 needs a wording update?

I would call that a bug in make.  Putting that in a Makefile is an
exercise in unportability, especially since eight spaces there _would_
be portable.

As for updating the wording of the rule, why?  Paul's rules aren't
part of the GNU make documentation or otherwise the final word on how
GNU make behaves.  Rather, they're guidance/advice on writing good,
maintainable Makefiles.

Can you write Makefiles that violate them?  Sure, and with sufficient
justification it might even be a reasonable thing for some of his
rules, but if someone I was working with violated rule 5 intentionally
they would get a dope slap (verbal or otherwise) for being a
dumbass^W^W^Wviolating best practices.

Maybe the issue is that rule 5 is actually the closest to being a
restatement of the docs; GNU make doesn't enforce any of the others at
all (though it might not do what you want if you break them), but this
one it _almost_ does so.  Maybe the divergence between the rule and
GNU make's behavior is exactly what makes this a rule: Paul knows this
corner of GNU make's behavior and is telling you to act like it isn't
there and to follow his simpler, better rule...


Philip Guenther

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: Difficulties from the combination of functions "call" and "eval"

[Philip Guenther]

To home in on one key point here...


On Sun, Jan 18, 2015 at 4:31 AM, SF Markus Elfring
 wrote:
...
>>> Lines 183 - 203:
>>> define RESULT_CHECK
>>> for part in $(1); do \
>>> if test "x$$(< $$part)" != "x0"; then \
>>> $(PRINTF) "$$(TEXT3)" '$$part'; \
>>> exit 12; \
>>> fi; \
>>> done \
>>> && $$(TOUCH) '$(2)'
>>> endef
>>
>> That looks like it expands to shell text when used with $(call), so
>> just call it in a recipe!
>
> Yes. - The evaluated variable should produce shell commands for recipes.
> I try to reuse it as a subfunction.

You use the word "evaluated" there, which I think reflects an
incorrect view of make's operation. To define the words as they're
used in the make documentation:

-  make _expands_ variables and functions, as marked with a leading
dollar-sign.  This
-  make _executes_ recipes and the argument of the $(shell) function
by passing the _expanded_ text to the shell
-  make _evaluates_ the its own input, the makefile, files that it
includes, the argument of the --eval CLI option, and the _expanded_
argument to the $(eval) function

You do not need $(eval) to get expansion to do its job of creating the
final string to pass to the shell in a recipe, for example.

define STUFF
# some shell commands here
sort inputs | uniq -c >outputs
endef

define MORESTUFF
# do something, then do STUFF
create_inputs >inputs
${STUFF}
endef

all:
${MORESTUFF}

When 'all' is built, ${MORESTUFF} will be expanded (which will involve
expanding the ${STUFF} inside it) to get a final string, which will
then be passed to the shell.  No need for ${STUFF} or ${MORESTUFF} to
explicitly say "execute this" or "evaluate this".

That's true even when you use $(call):

# Generate file $2 from file $1
define STUFF
# some shell commands here
sort $1 | uniq -c >$2
endef

# Generate $1
define MORESTUFF
# do something, then do STUFF
create_inputs >inputs
$(call STUFF,inputs,$1)
endef

all:
$(call MORESTUFF,output)

When building 'all', make will expand $(call MORESTUFF,output) by
temporarily setting $1 to 'output' then expanding MORESTUFF.  The
$(call STUFF,inputs,$1) inside that will temporarily override that by
setting $1 to 'inputs' and $2 to 'output' then expanding STUFF.  The
result will be the same as the earlier example.


That distinction between expansion, execution and evaluation make sense?


Philip Guenther

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: Difficulties from the combination of functions "call" and "eval"

[Philip Guenther]

On Sat, Jan 17, 2015 at 11:11 PM, SF Markus Elfring
 wrote:
>> So that $(eval $(call GIBBERISH)) is wrong.  Exactly *how* it's wrong
>> depends on what the $(call) is supposed to return.  Currently you're
>> evaling something that doesn't look like a *STANDALONE* chunk of
>> Makefile, which results in the error *in the eval*.
>
> I have added another tab character to a multi-line variable definition
> which should be called for a specific evaluation.
> Now I get a bit of more "progress indication" from a different error message.

You're just trying random stuff and not paying attention!  Stop and
*think*!  $(eval) takes as its argument a *CHUNK OF STANDALONE
MAKEFILE*: a variable assignment, and rule w/ or w/o recipe, an
export, a define, and if/endif block, etc.

NEITHER OF YOUR VARIABLES BELOW MEET THAT CRITERIA, SO PASSING THEIR
EXPANSIONS TO $(eval) IS AN ERROR.


> Would you like to give further hints (or advices) for another excerpt
> from this build script?
>
> Lines 183 - 203:
> define RESULT_CHECK
> for part in $(1); do \
> if test "x$$(< $$part)" != "x0"; then \
> $(PRINTF) "$$(TEXT3)" '$$part'; \
> exit 12; \
> fi; \
> done \
> && $$(TOUCH) '$(2)'
> endef

That looks like it expands to shell text when used with $(call), so
just call it in a recipe!


> define HANDLE_BACKGROUND_TASK
> @$(RM) '$(1)'
> $(file >$(2)) \
> $(file >>$(2),for task in $$($(SEQ) $(PARALLEL_MAXIMUM) -1 0); \
> do $(MAKE) -f $(3) -j1 index=$$task &; \
> done) \
> $(file >>$(2),wait)
> @cat '$(2)'
> $$SHELL '$(2)'
> $(eval $(call RESULT_CHECK,$(4),$(1)))
> endef

Why are you using $(eval) there?  Think: what does $(call
RESULT_CHECK,$4,$1) expand to?  Would that expansion be a valid
Makefile if you put it in its own file?  No?  It's just _part_ of a
recipe?  Then $(eval) is the Wrong Thing.


Frankly, this entire HANDLE_BACKGROUND_TASK mess seems like it's at
the wrong level.  Either you should be letting the toplevel make
handle the parallelism by expressing this all with targets and
dependencies, or push it to the shell level and just have each recipe
start with a macro that expands to a canned block of shell that
figures out whether its the first call and forks the background stuff
then.  Or even wrap make in a shell script that does the imperative
background stuff before starting make with a Makefile that doesn't
have that insanity?

Make is itself a declarative language; forcing it into an imperative
style is just going to give you ulcers, or more likely, give ulcers to
your co-worker or co-maintainer or the six-months-from-now version of
you, when they/you have to figure out how this Makefile works.  To
quote Brian Kernighan: "Everyone knows that debugging is twice as hard
as writing a program in the first place. So if you're as clever as you
can be when you write it, how will you ever debug it?"


Philip Guenther

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: Questionable line number in a message "missing separator"?

[Philip Guenther]

On Sat, Jan 17, 2015 at 12:52 PM, SF Markus Elfring
 wrote:
>> Of course, if you had actually quoted the relevant lines from your
>> Makefile, we could be more precise.
>
> Thanks for your interest.
>
> Do you get further ideas from an excerpt of my build script 
> "parallel-inc.make"?
>
> Lines 241 - 256:
> $(EXIT_CODES_FUNCTIONS_THAT_CHECK_THEIR_SINGLE_PARAMETER_IN_HEADERS) \
> $(RESULT_SQL_DATABASE_NOTIFICATION3) \
> $(RUN_FUNCTIONS_THAT_CHECK_THEIR_SINGLE_PARAMETER_IN_HEADERS): \
> initialise_database \
> $(BUILD_FUNCTIONS_THAT_CHECK_THEIR_SINGLE_PARAMETER_IN_HEADERS) \
> $(HEADER_SEARCH_PARTS)
> $(if 
> $(LET_RUN_FIND_FUNCTIONS_THAT_CHECK_THEIR_SINGLE_PARAMETER_IN_HEADERS_PARALLEL),\
> $(eval 
> LET_RUN_FIND_FUNCTIONS_THAT_CHECK_THEIR_SINGLE_PARAMETER_IN_HEADERS_PARALLEL::=)$(eval
>  $(call HANDLE_BACKGROUND_TASK,\
> $(RESULT_SQL_DATABASE_NOTIFICATION3),\
> $(RUN_FUNCTIONS_THAT_CHECK_THEIR_SINGLE_PARAMETER_IN_HEADERS),\
> $(BUILD_FUNCTIONS_THAT_CHECK_THEIR_SINGLE_PARAMETER_IN_HEADERS),\
> $(EXIT_CODES_FUNCTIONS_THAT_CHECK_THEIR_SINGLE_PARAMETER_IN_HEADERS
>
> find_functions_that_check_their_single_parameter_in_headers_with_parallel_groups:
>  \
> $(RESULT_SQL_DATABASE_NOTIFICATION3)
> @$(ECHO) 'Header files were analysed.'



So that $(eval $(call GIBBERISH)) is wrong.  Exactly *how* it's wrong
depends on what the $(call) is supposed to return.  Currently you're
evaling something that doesn't look like a *STANDALONE* chunk of
Makefile, which results in the error *in the eval*.


Paul, I still think $(eval) should have been named
$(stick-arm-in-woodchipper), to make it less seductive to people
trying to layer imperative programming on the declarative nature of
make.


Philip Guenther

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: Questionable line number in a message "missing separator"?

[Philip Guenther]

On Sat, Jan 17, 2015 at 11:06 AM, SF Markus Elfring
 wrote:
> But the software tool "make 4.1-2.2" does not like
> a specific place in this file at the moment.
>
> …
> parallel-inc.make:247: *** missing separator.  Stop.
>
>
> The mentioned line has got a leading tab character
> for the beginning of a recipe.
> How can this syntax difficulty be resolved now?

A line starting with a tab is only interpreted as part of a recipe if
the previous non-comment line was either a rule or another recipe
line.  If the previous line was an include, a variable assignment, a
vpath setting, etc then the previous recipe is closed and you can't
add another recipe line to it.

Of course, if you had actually quoted the relevant lines from your
Makefile, we could be more precise.


Philip Guenther

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: bug with order-only prerequisites & implicit rules implementation ?

[Philip Guenther]

On Sat, Jan 10, 2015 at 7:06 PM, Jason Vas Dias
 wrote:
> Please could anyone explain the behaviour of this test makefile (attached) :
>
> 
> TMP:=/tmp
>
> %.ext:
> touch $@
>
> .PHONY: *.oop
> %.oop:
> @echo 'A phony order-only prequisite of /tmp/a.t';
>
> #$(TMP)/%.t: | %.oop
>
> $(TMP)/%.t:$(TMP)/%.ext | %.oop
> @echo Specific Rule
>
> %.t:%.ext
> @echo General rule
>
> 
>
> when invoked with :
>
>   $ make -f ${the_makefile} /tmp/a.t
>
> I would expect that the most specific matching first rule
> would be invoked always, with its extra order-only
> pre-requisite recipe always being invoked, but actually
> this occurs only if /tmp/a.ext does not already exist -
> I tested latest make-4.1, and make-3.82, on a RHEL6 linux
> platform,  and both show the same behaviour:
>
> $ make -f ${the_makefile} /tmp/a.t
> touch /tmp/a.ext
> A phony order-only prequisite of /tmp/a.t
> Specific Rule
> rm /tmp/a.ext
>
> but if I :
> $ touch /tmp/a.ext
> and then :
> $ make -f ${the_makefile} /tmp/a.t
> Gemeral Rule

This behavior is documented.  To quote from the info pages, section
10.5.4 How Patterns Match:

   A pattern rule can be used to build a given file only if there is a
target pattern that matches the file name, _and_ all prerequisites in
that rule either exist or can be built.  The rules you write take
precedence over those that are built in. Note however, that a rule
whose prerequisites actually exist or are mentioned always takes
priority over a rule with prerequisites that must be made by chaining
other implicit rules.


When /tmp/a.ext exists but a.oop doesn't, then the 'general' rule has
precedence because all the prerequisites exist, while the 'specific'
rule has a non-existent prerequisite (a.oop).


> If I remove the phony order only dependency. so that the /tmp/%.t rule reads:
> 
> $(TMP)/%.t:$(TMP)/%.ext
> 
> then the makefile always runs the first recipe, regardless of the existence
> of /tmp/a.ext :

Given the explanation above, that should make sense.



> Also, a second problem is that order-only dependencies are not
> recognized when specified by multiple rules without recipes are
> specified  for same target , ie:
> 
> $(TMP)/%.t: | %.oop
> $(TMP)/%.t:$(TMP)/%.ext
> 
> has the same effect (recipe for implicit order-only pre-requisite never runs)
> as no order-only dependency being specified at all. I thought the
> dependencies should be merged and the %.oop recipe should be run in
> this case, especially as I've told make that all *.oop targets are
> phony.

Pattern rules, unlike normal rules, are never merged.  Each one stands
alone and either completely overrides a previous pattern rule with the
exact same target and prerequisites (but possibly different commands,
or *no* commands, which cancels the previous pattern rule), or adds a
new pattern for the target with different prerequisites.


Philip Guenther

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: [bug #42690] make unconditionally resolves the current directory

[Philip Guenther]

On Sat, Jul 5, 2014 at 12:57 PM, anonymous  wrote:

> { cd /tmp && mkdir a && ln -sT a b && cd b && make -w; }
>
> make: Entering directory `/tmp/a'
>
> Why not /tmp/b?  Is there an option to prevent this resolution?
> I understand that relative path names must be resolved;
> but could you leave directory aliases as they are please?
>

The best make would be able to do would be to model its behavior on that of
"pwd -L": if the PWD environment variable is set to an absolute path with
no ".." or "." components that resolves to the process's current directory,
then use that instead of the path from getcwd().


This hit me when I tried to make in a directory that had a colon in the
> name;
>

Doctor says: "Don't do that!"   make is only one of many program which you
will have problems with.


Philip Guenther
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: Question about pattern rule with multiple targets

[Philip Guenther]

On Fri, Jun 27, 2014 at 2:52 PM, Tom Varga  wrote:

> b.zoo1 really only depends on b.bar1
> b.zoo2 really only depends on b.bar2
>
> However, only one rule (and tool) is used to build both b.bar1 and b.bar2
>
> I really don't want force b.zoo1 to artificially depend on b.bar2 as it's
> not a real dependency.
>
> I was really just hoping to be able to convince gnumake that b.bar1 and
> b.bar2 are built with the same rule
>

It works just fine for that!



> and MUST be consistent, that is both having been built at the same time
> and that both exist too.
>

Ah, *this* is the issue, the fact that you can't use generated files from
different runs.  For most(?) program that generate multiple files, mixing
and matching isn't an issue when the source file is unchanged.  If the
source file is changed, then make's current bits handle it just fine,
rebuilding both, of course.

There's certainly some way to express the "if the either file is missing,
rebuild both" using $(if) and $(wildcard) to check for existence, but my
reaction right now is "fix the tool that isn't generating consistent
output"...


Philip Guenther
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: Question about pattern rule with multiple targets

[Philip Guenther]

On Fri, Jun 27, 2014 at 11:24 AM, Tom Varga  wrote:
>
> On page 120 of the gnumake manual, it mentions support for pattern
> rules with multiple targets.
>
> This pattern rule has two targets:
> %.tab.c %.tab.h: %.y
>  bison -d $<
>
> So, if I have a simple rule that looks like:
>
> %.bar1 %.bar2 : %.foo
> touch $(*F).bar1
>  touch $(*F).bar2
>
> and then do:
>
> > touch a.foo
> > make a.bar1
> touch a.bar1
> touch a.bar2
> > make a.bar1
> make: 'a.bar1' is up to date.
> > rm a.bar2
> > make a.bar1
> make: 'a.bar1' is up to date.
> > make a.bar2
> touch a.bar1
> touch a.bar2
>
> What I was really hoping is that make would consider both a.bar1 and
> a.bar2 to be required outputs of the rule and if one of them is
> deleted, then both the .bar1 and .bar2 targets should be considered
> out-of-date.  But when I manually remove the a.bar2 file, the a.bar1
> file is still considered to be up-to-date.  Yet, when I then ask to
> build the a.bar2 target, both the a.bar1 and a.bar2 targets are
> re-built.
>

Umm, why isn't this solved by having a correct dependency on a.bar2 where
necessary?


Philip Guenther
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: error reporting

[Philip Guenther]

On Mon, Apr 7, 2014 at 4:45 PM, Rob Juergens  wrote:
> Given the make file (makefile):
>
> --
> foo : bar
> --
>
> gmake 3.75 gives this:
>
> gmake: *** No rule to make target 'bar', needed by 'foo'. Stop.
>
> gmake 4.0 gives this:
>
> gmake: ***. stop.
>
> This has caused a lot of time trying to figure out what is wrong with the
> makefile. A big step backward in error reporting.
>
> Please fix this.

I am unable to reproduce this:

: morgaine; ls -l
total 2
-rw-rw-r--  1 guenther  wheel  10 Apr  7 21:22 Makefile
: morgaine; cat Makefile
foo : bar
: morgaine; gmake --version
GNU Make 4.0
Built for x86_64-unknown-openbsd5.5
Copyright (C) 1988-2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
: morgaine; gmake
gmake: *** No rule to make target 'bar', needed by 'foo'.  Stop.
: morgaine;


What information about your situation did you leave out?


Philip Guenther

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: vms:test variables

[Philip Guenther]

On Thu, Apr 3, 2014 at 9:56 PM, John E. Malmberg  wrote:
> This is the patches for the variables tests on VMS.

I'm kinda surprised that you haven't worked out some direct
coordination with the GNU make developers for the handling of these
diffs.  I don't see how sending them to the full bug-make list is
useful; are you expecting random list members to provide feedback on
them?


Philip Guenther

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: win32 compilation of make 4.0 source code

[Philip Guenther]

On Tue, 28 Jan 2014, Mark Brown wrote:
> On Mon, Jan 27, 2014 at 11:05 PM, Mark Brown  wrote:
> > > > From: Paul Smith
> > > > Sent: Monday, January 27, 2014 8:57 PM
> > ...
> > > >  ifneq ($(filter else-if,$(.FEATURES)),else-if)
> > > >$(error Version $(MAKE_VERSION) does not support else-if)
> > > >  endif
> > > Are you saying that this statement can be placed outside
> > > of a make target recipe command sequence,
> > > and would be executed before the target recipe command sequence ?
> > The answer to your question can be found in the GNU make info pages.
> > Or, you could just TRY IT AND GET THE ANSWER INSTANTLY.
> This is what the new make 4.0 manual says about -trace capability:

So, you're _not_ going to just try the ifneq()...endif example that Paul 
provided?  Gotcha.


> =
> ?--trace? Show tracing information for make execution. Prints the entire
> recipe to be
> executed, even for recipes that are normally silent (due to .SILENT or ?@?).
> Also prints the makefile name and line number where the recipe was defined,
> and information on why the target is being rebuilt.
> =
> 
> Again, this is a re-paste of the desired output,
> which again you deleted in your reply:

No, it doesn't provide output in that format.  Your suggested output 
format can't be unambiguously parsed when the variables contain 
whitespace, which would make the output much less useful.


...
> Your role is maintenance of the make project.

I'm sorry, but you appear to suffer misconceptions about the project and 
myself.

I have *NO* official role in the project.  I'm just someone that uses it 
and answers some questions on the list.


> It is not your role to solve other people's engineering problems.

Huh.  What gave you the role of deciding what other peoples' roles are?


> When a bug or omission is presented to you, you have
> at least 3 appropriate response options:
> 1) we do not think that is an issue that needs to be solved by make,
> 2) that issue needs to be solved in make, and it is, but in a different way
> from what may be apparent from the documentation or intuitive,
> Read the following link  etc.
> 3) we do think that issue should solved by make, but it has
> yet to be implemented.

HAHAHHAHAHAHHHAHAHAHAHA

Do you have a contract with me or, for that matter, with the GNU make 
project which would let you specify that?  Heck, do you get to specify 
that when you complain to Microsoft about bugs in their tools?


(There are plenty of courteous people that ask questions on this list.  I 
shouldn't stop giving my minimal help in answering their questions just 
because one person stomps in complaining that we must answer questions in 
the way he demands.)



Philip

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: win32 compilation of make 4.0 source code

[Philip Guenther]

On Mon, Jan 27, 2014 at 11:05 PM, Mark Brown  wrote:
>> From: Paul Smith
>> Sent: Monday, January 27, 2014 8:57 PM
...
>>  ifneq ($(filter else-if,$(.FEATURES)),else-if)
>>$(error Version $(MAKE_VERSION) does not support else-if)
>>  endif
>
> Are you saying that this statement can be placed outside
> of a make target recipe command sequence,
> and would be executed before the target recipe command sequence ?

The answer to your question can be found in the GNU make info pages.
Or, you could just TRY IT AND GET THE ANSWER INSTANTLY.

...
>> In GNU make 4.0 the --trace option was introduced.  From the NEWS file:
>>
>>  * New command line option: --trace enables tracing of targets.  When
>> enabled
...
> Does this trace capability display the full evaluated automatic variables ?
> Why not include a sample paste of its output.

You've been unwilling to given any specific examples of your problems,
makefile snippets, or output, and yet you question when other don't
provide them?  Since you obviously don't have the current version of
make installed, why would anyone bother?


Philip Guenther

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: win32 compilation of make 4.0 source code

[Philip Guenther]

(Dang it: gmail treats control-enter as "send"...)

On Mon, Jan 27, 2014 at 1:12 PM, Philip Guenther  wrote:
> On Mon, Jan 27, 2014 at 9:59 AM, Mark Brown  wrote:
>> First, let me request that you include the question posed to you,
>> in your Reply responses in this email sequence.
>
> How about you stop top-posting and instead reply inline?
>
>
>> 1)  I think my question was explicit.
>> A method for an existing Makefile to test for .FEATURES capabilities
>> when it is downloaded to a random linux or Windows make environment
>> and existed.
>
>  That wasn't the question you originally asked.  To quote your
> original query about .FEATURES:
>
>>> As a separate related issue,
>>> I was try to echo the .FEATURES information, since one of the its it claims 
>>> to display
>>> mentions its Else If capabilities.
>>> However, every time I tried to echo the data I received a syntax error.
>>> What would be an example of a Makefile contents which would display
>>> the .FEATURES information ?
>
> The example that Paul gave answers that original question:
> all:
> echo ${.FEATURES}
>
>
> So now you have a new question
>
>> The Makefile itself when e.g "make " is selected, should be
>> able to precede execution of any target with a check of .FEATURES
>> to verify the make environment into which it is downloaded.
>> Give an example of .FEATURES display/echo in an existing Makefile.,
>> both v 3.80 and 4.00 .

This is where Paul question of "what did you already try?" comes in.
Rather than give you a fish, it would be better to teach you how to
fish; seeing what you tried would let us correct whatever
misunderstanding caused the syntax errors you got.

Or you could search the archives for examples, if you really don't
want to understand.


>> 2)  Also, please answer the other question posed:

Hmm, how much are you paying for these answers?  Oh right, nothing...


>> ---
>>
>> I also want to know if there is a debug mode within make
>> in which the Makefile filename and Line Number
>> (some Makefiles are huge and distributed over several subordinate Makefiles)
>> is matched to each automatic variable evaluation within a Target evaluation.
>> ---

Since you don't say what debug output you've already looked at, I'll
just suggest two possibilities
1) "make -pq" and examine the dumped output, which gives file and line
number for all commands
2) check out the "remake" project. http://bashdb.sourceforge.net/remake/


>> If either of these make capabilities are not possible currently,
>> then that is a case for implementation in  Make  version 4.1 .

You didn't describe the problem that you're trying to solve; how do
you know that data would solve it?  Why *only* automatic variables?
If there are several levels of variable expansion involved, what
should the output look like?


Philip Guenther

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: win32 compilation of make 4.0 source code

[Philip Guenther]

On Mon, Jan 27, 2014 at 9:59 AM, Mark Brown  wrote:
> First, let me request that you include the question posed to you,
> in your Reply responses in this email sequence.

How about you stop top-posting and instead reply inline?


> 1)  I think my question was explicit.
> A method for an existing Makefile to test for .FEATURES capabilities
> when it is downloaded to a random linux or Windows make environment
> and existed.

 That wasn't the question you originally asked.  To quote your
original query about .FEATURES:

>> As a separate related issue,
>> I was try to echo the .FEATURES information, since one of the its it claims 
>> to display
>> mentions its Else If capabilities.
>> However, every time I tried to echo the data I received a syntax error.
>> What would be an example of a Makefile contents which would display
>> the .FEATURES information ?

The example that Paul gave answers that original question:
all:
echo ${.FEATURES}


So now you have a new question

> The Makefile itself when e.g "make " is selected, should be
> able to precede execution of any target with a check of .FEATURES
> to verify the make environment into which it is downloaded.
> Give an example of .FEATURES display/echo in an existing Makefile.,
> both v 3.80 and 4.00 .





>
> 2)  Also, please answer the other question posed:
> ---
>
> I also want to know if there is a debug mode within make
> in which the Makefile filename and Line Number
> (some Makefiles are huge and distributed over several subordinate Makefiles)
> is matched to each automatic variable evaluation within a Target evaluation.
> ---
>
> If either of these make capabilities are not possible currently,
> then that is a case for implementation in  Make  version 4.1 .
>
>
>
>
> -Original Message- From: Paul Smith
> Sent: Monday, January 27, 2014 9:35 AM
> To: Mark Brown
> Cc: bug-make@gnu.org
>
> Subject: Re: win32 compilation of make 4.0 source code
>
> On Sun, 2014-01-26 at 16:22 -0800, Mark Brown wrote:
>>
>> That example method is a device to perform this .FEATURES test
>> without inserting it into an existing Makefile.
>> The syntax errors I was seeing were occurring when attempting to insert
>> this
>> test into an existing Makefile, full of Targets and command sequences.
>
>
> Well, since you've provided no details about exactly what you tried and
> what errors you received, or even details about exactly what you're

> trying to do, there's not much else we can say.  You said "echo the
> data", and I showed an example of echoing the data.  If that's not what
> you want, you need to give more information.
>
> 
> ==re-pasted text of the question posed=
> 
>
> That example method is a device to perform this .FEATURES test
> without inserting it into an existing Makefile.
> The syntax errors I was seeing were occurring when attempting to insert this
> test
> into an existing Makefile, full of Targets and command sequences.
> If this feature is used it would be at the top of an existing Makefile,
> before any targets
> are evaluated.
>
> I also want to know if there is a debug mode within make
> in which the Makefile filename and Line Number
> (some Makefiles are huge and distributed over several subordinate Makefiles)
> is matched to each automatic variable evaluation within a Target evaluation.
> =
>
>
>
> ___
> Bug-make mailing list
> Bug-make@gnu.org
> https://lists.gnu.org/mailman/listinfo/bug-make

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: make doesn't complain if target cannot be built

[Philip Guenther]

On Mon, Jan 13, 2014 at 9:56 PM, Christian Eggers  wrote:
> Is there a workaround for this? Using explicit rules seems to be difficult in
> my case because some objects are built from .c sources, other from .cpp.
> Is there a better way instead of this:
>
> SOURCES_C := foo.c
> SOURCES_CPP := bar.cpp
> SOURCES_ASM := ...
>
> OBJS := $(SOURCES_C:%.c=%.o) $(SOURCES_CPP:%.cpp=%.o) ...
>
> $(SOURCES_C:%.c=%.o):
> $(COMPILE.c) ...
>
> $(SOURCES_CPP:%.cpp=%.o):
> $(COMPILE.cpp) ...
>
> $(OBJS): generated.h
>
> EOF

In many cases, I've found it completely unnecessary to list the source
files.  Just list the objects that should be built and provide pattern
rules for the source types, then let make figure out which source
files generate which objects from the patterns, ala:

OBJS = foo.o bar.o ...
%.o: %.c:
$(COMPILE.c) 
%.o: %.cpp
$(COMPILE.cpp) 
...
$(OBJS): generated.h


You only need to match sources to objects if there's a naming
conflict...which I would tend to solve by renaming the file that
doesn't belong.


Side point: you only list an explicit dependency for a file named
generated.h, which suggests you're using some sort of automated
dependency technique (gcc -MD, make depend, etc) for handling
dependency tracking for other .h files.  If that's the case, then it
can be slightly better to use an order-only prerequisite for the
generated file, ala:

$(OBJS): | generated.h

That guarantees the generated.h file will exist before trying to build
any objects, but if generated.h gets rebuilt, only the objects that
have real dependencies from the automated dependency tracking setup
will get rebuilt.


Philip Guenther

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: [bug #40361] make 4.0 under hpux 11.31 no longer prints output correctly

[Philip Guenther]

On Thu, Oct 24, 2013 at 3:43 PM, Frank Heckenbach
 wrote:
> Another thing that changed in the course of the output patches is that
> messages are now generated in vfmtconcat() using vsnprintf() as well as
> va_copy(), both C99 and at least the latter AFAIK not very widely used.
>
> For testing you could try replacing the body of vfmtconcat() with "vprintf
> (fmt, args);". (Keep the return statement to avoid a compiler warning; the
> returned value isn't actually used.) This will break output-sync, of course,
> but if the messages are correct then, we've found the culprits.

I no longer have notes about what version I saw it in, but HP-UX's
vsnprintf/snprintf would, when the buffer wasn't large enough, return
-1 instead of the "number of chars that would have been written".

I think it also flubbed handling of buflen==0 as the workaround code
we used would make a first try passing a buflen of 1 and a single char
buf instead of a buflen of zero and NULL.  Or maybe that part was a
bug in AIX.  Hmm...


Philip Guenther

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: [bug #40225] Deterministic output ordering

[Philip Guenther]

On Sat, Oct 12, 2013 at 7:01 PM, Frank Heckenbach
 wrote:
> - My suggestion relies on the order the jobs are *started* (which,
>   as I said, ought to be deterministic and the same as with "-j0",
>   though Paul should know this better than me).

Maybe you're talking about some restricted subcase, but *IN GENERAL*,
the order in which jobs are started by make when running with -jN is
dependent on how long it takes to execute the subjobs.

Trivial example:

all: a b
a: a1.o a2.o
${LINK.c} -o $@ $^
b: b1.o b2.o
${LINK.c} -o $@ $^


Let's say building a1.o takes 1.5 second, but the others each takes 1 second.
Then the start order when you do "make -j2 all" will be:
a1.o a2.o b1.o a b2.o b

If building a1.o takes 2.5 second then the order will be:
a1.o a2.o b1.o b2.o a b

If building a1.o takes 3.5 second then the order will be:
a1.o a2.o b1.o b2.o b a

Without -j, the order will always be
    a1.o a2.o a b1.o b2.o b


Philip Guenther

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: [bug #40056] make should automatically detect targets with low resolution timestamps

[Philip Guenther]

On Tue, Sep 17, 2013 at 10:12 PM, James Ralston  wrote:
...
> The statfs(2) system call will return the f_type field in the struct statfs,
> but unfortunately, the field is the same for all variants of ext (ext2, ext3,
> ext4). So as far as I know (although I would be happy to be corrected), there
> is no library or system call that will reveal whether the filesystem that an
> arbitrary file is on supports high resolution timestamps.

You're looking for
pathconf(path, _PC_TIMESTAMP_RESOLUTION)

See also:
http://pubs.opengroup.org/onlinepubs/9699919799/functions/fpathconf.html

However, last I checked glibc and Linux didn't implement it.


Philip Guenther

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: Condtional target-specific variable assignment does not work as expected

[Philip Guenther]

On Fri, Aug 9, 2013 at 12:59 PM, Ed Hutchins  wrote:
...
> In my case I'd like to have "init", "start" and "start_clean" end-user
> targets which reuse common
> targets which in turn depend on targets specified by the above semantic
> intent. If there were a
> true order-only operator (say ||), I could do:
>
> .PHONY: 
>
> init_server: 
> start_server: 
> start_clean_server: 
> common: || init_server start_server start_clean_server
> init: init_server common
> start: start_server common
> start_clean: start_server common
>
> If I try the above with the current order-only | operator all three 
> dependencies are
> invoked by common. Is there a way to get the effect of the above that anyone 
> can think of?

Sounds to me like the commands currently in 'common' should be saved
in a macro which is used by the 'init', 'start', and 'start_clean'
targets and the 'common' target itself eliminated.  Indeed, the same
may be true of 'init_server', 'start_server', and
'start_clean_server', particularly if they don't have any
dependencies.  How is making them targets useful?


Philip Guenther

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: Default output-sync setting (was: Re: [bug #33138] .PARLLELSYNC enhancement with patch)

[Philip Guenther]

On Mon, Apr 29, 2013 at 10:30 AM, Tim Murphy  wrote:
> cc fred.c -c -o fred.o
> cc bob.c -c -o bob.o
> error on line 20 -X
> error on line 30 -
> error on line 330 -
> makefile:342: recipe for target 'fred.o' failed
> makefile:350: recipe for target 'bob.o' failed
>
> ?

"Doctor, my hammer has a head so large that I always hit my thumb"
"Throw out that hammer and get a non-broken one"

The GNU tool working around the brokenness of some non-free software?
Some would call that collaboration in retaining your chains.

:-/



I haven't had a chance to play with the new functionality in the
repository, so I'll merely caution that having major new functionality
that will affect the user experience be on by default runs the risk of
there being a problem and having the new version be
tarred-and-feathered, and the projects that would most benefit from
the new functionality instead turning it off.  If there are other
fixes and/or features in this release that people are waiting for,
burning them on this would be unfriendly.


Philip Guenther

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: [bug #38437] cannot find the include file

[Philip Guenther]

On Wed, Feb 27, 2013 at 8:55 PM, Jian  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

Re: [bug #38433] Example for "eval" in documentation contains error with "define"

[Philip Guenther]

On Wed, Feb 27, 2013 at 2:42 PM, Sebastian Pipping
 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"

[Philip Guenther]

On Wed, Feb 27, 2013 at 1:56 PM, Daniel Wagenaar  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"

[Philip Guenther]

On Wed, Feb 27, 2013 at 11:25 AM, Daniel Wagenaar
 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

Re: [bug #38420] $(realpath ...) doesn't recover from signals

[Philip Guenther]

On Wed, Feb 27, 2013 at 9:44 AM, Brian Vandenberg
 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

Re: prerequisites alter choice of pattern match rules?

[Philip Guenther]

On Mon, Feb 25, 2013 at 5:57 AM, Brian J. Murrell  wrote:
> I would think that given the following set of rules:
>
> /tmp/%.foo: %.foo
> echo "foo rule 1"
> touch $@
>
> %.foo:
> echo "foo rule 2"
> touch $@
>
> /tmp/%.bar:
> make $*.bar
> echo "bar rule 1"
> touch $@
>
> %.bar:
> echo "bar rule 2"
> touch $@
>
> Trying to create a target of /tmp/a.foo and /tmp/a.bar should result in
> the same rules being run but they don't:
...
> It would seem that for the /tmp/a.foo, the "/tmp/%.foo" pattern rule is
> not being chosen but for /tmp/a.bar" the "/tmp/%.bar" pattern rule is
> being chosen.  The only difference in those choices I can see is that
> the "/tmp/%.foo" pattern rule has a prerequisite and the "/tmp/%.bar"
> one doesn't.
>
> So the question is, why does a prerequisite change the behavior of
> pattern match rules?  I would think the selection of a pattern match
> rule would be independent of prerequisites but of course once the
> pattern match rule was chosen, the rule for the prerequisite would also
> need to be called to ensure it's freshness.
>
> Thoughts?

When there's no explicit rule for a target (i.e., a rule where the
exact target name is listed), the algorithm for chosing the implicit
rule to apply first checks for rule(s) for which all the prerequisites
either already exist or are explicitly listed as targets themselves,
or have no prerequisites**.  Only if all the pattern rules have at
least one non-existent prerequisite that isn't explicitly listed
elsewhere does make then recursively try chaining to other rules for
each of the (missing) prerequisites.  Yes, this behavior is documented
in the info pages in more than sufficient detail to be sure that it
was clearly intended.

You ask why that's done.  To really answer that question I think you
would have to find and review the discussions among the developers
when it was actually added to GNU make, presumably back when Roland
was the maintainer.  The answer might be "because that's how Stu
Feldman's version of make did it".  Or maybe "it was too slow if we
tried all the possible chains, and we also wanted some way other than
order-in-the-makefile to prefer a rule".  Or "if there's a direct way
to build something, it must obviously be the right choice over
something which requires an intermediate file; if you don't want that,
then you should craft your patterns and filename choices so that you
don't get overlapping patterns!"

...but I wasn't there and those are just guesses.


Philip Guenther


** if there are no prerequisites, then all of the prereqs are present;
the list of missing prereqs is empty.

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: prerequisites alter choice of pattern match rules?

[Philip Guenther]

On Mon, Feb 25, 2013 at 2:30 PM, Sebastian Pipping
 wrote:
...
> It seems like normally GNU make walks the path of the most specific
> match in case of ambiguities.  I wonder if that's specified/documented
> anywhere.

Yes, it is.  I don't remember where, but it's in the docs.


Philip Guenther

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: timestamp bug when files are created just before make is run

[Philip Guenther]

On Thu, Dec 6, 2012 at 2:02 PM, Mikulas Patocka
 wrote:
> The apparent problem is that after make rebuilds b, it compares b's time
> with a's time, finds that the times are equal (because a was touched just
> before make was run) and doesn't rebuild a.
>
> I think it is a bug - when b is finished, make should find out whether the
> rule for b modified the file b (if b's time is greater or equal than the
> time when the rule for b was started, then b may have been modified) and
> rebuild a in this case.

That's not the rule that make has always followed and, indeed, is
required by the standard to follow.  To quote POSIX:

The make utility attempts to perform the actions required to ensure
that the specified targets are up-to-date. A target is considered
out-of-date if it is older than any of its prerequisites or if
it does not
exist. The make utility shall treat all prerequisites as targets
themselves and recursively ensure that they are up-to-date, processing
them in the order in which they appear in the rule. The make utility
shall use the modification times of files to determine whether the
corresponding targets are out-of-date.

The fact that the timestamp on a prerequisite has changed do *not*
mean that it's newer than the target; it may have been copied from
some other file which, while newer, is still older than the target
file.  So the change to the make algorithm described in the paragraph
above that starts "I think it is a bug" would not be correct;
something more precise about what timestamps would be considered
"newer" would be necessary.


Note that this problem doesn't arise on systems with high precision
file timestamps.  Many systems have provided those since the mid 90's;
I'm appalled that the modern system that process the involved shell
commands fast enough for this to regularly be a problem don't provide
microsecond or better timestamp precision.


> This bug is causing real-world problems in automake-generated Makefiles.
> This is a simplified piece of Makefile from automake:
> all : config.h
> $(MAKE) all-am
>
> config.h : stamp-h1
> echo build config.h
>
> stamp-h1 : config.h.in
> echo build stamp-h1
> rm -f stamp-h1
> touch config.h
> touch stamp-h1
>
> config.h.in : am__configure_deps
> echo build config.h.in
> rm -f stamp-h1
> touch config.h.in
>
> all-am :
> echo ALL-AM
>
> Now, if you run this script, you trigger the bug:
>
> touch config.h.in;sleep 1;touch am__configure_deps;sleep 1;touch config.h 
> stamp-h1;make
>
> - you see "build config.h.in", but the other files are not rebuild and
> all-am is executed
> (the essential thing to trigger the bug is that make is run in the same
> second in which config.h and stamp-h1 were created)
...
> Another possible solution for this bug would be to remove rm -f stamp-h1
> from config.h.in rule, but there is some complex explanation in
> /usr/local/share/automake-1.12/am/remake-hdr.am why rm -f stamp-h1 is
> there so it would likely fix one bug and trigger another one.

Hmm, adding a "sleep 1" after that rm -f and before the touch
config.h.in would work without reintroducing the issue described in
that explanation, no?


Philip Guenther

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: Possible bug (documentation or make itself) not sure

[Philip Guenther]

On Tue, Nov 6, 2012 at 4:02 PM, LANGLOIS Olivier PIS -EXT
 wrote:
> In section 6.11:
>
> Target-specific variable assignments can be prefixed with any or all of the 
> special keywords export, override, or private; these apply their normal 
> behavior to this instance of the variable only.
>
> the way I read it is that you can specify one or many special keywords. If I 
> try to use 2, I get an error message. As soon, as I remove one of them, make 
> works as expected.
>
> Maybe it is the wording that is misleading the 'any or all' may be meaning 
> 'none or any one of the special keywords'.
>
> dev400t@dev400t-desktop:~/devel/make_test$ cat makefile
>
> .PHONY: datapluglib
> datapluglib : export override CC = g++
> datapluglib:
> echo $(CC)
>
> dev400t@dev400t-desktop:~/devel/make_test$ make
> make: *** No rule to make target `export', needed by `datapluglib'.  Stop.
> dev400t@dev400t-desktop:~/devel/make_test$ make --version
> GNU Make 3.81

No, the docs are correct *for the current version of GNU make*.  You
need to either
a) upgrade to the current version, or
b) read the documentation that was included in the version that you
have installed; try running "info make"

I suggest you also yell at your distribution for both not providing
the current version *and* for not pointing you at the correct
documentation for the version that they are shipping.


Philip Guenther

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: Example error in make manual

[Philip Guenther]

On Mon, Nov 5, 2012 at 3:26 AM, Zhitao Gong  wrote:
> there should be no `=` after the `run-yacc`.
>
> On Mon, Nov 5, 2012 at 7:26 PM, Zhitao Gong  wrote:
>> in Make Manual Pdf, Edition 0.71, last updated 19 July 2010,
>>
>> Page 54:
>> 5.8 Defining Canned Recipes,
>>
>> the example
>>> define run-yacc =

No, the example is correct *for the current version of GNU make*.  You
need to either
a) upgrade to the current version, or
b) read the documentation that was included in the version that you
have installed; try running "info make"


Philip Guenther

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: sh embedding

[Philip Guenther]

On Mon, Jul 23, 2012 at 11:59 AM, icegood  wrote:
> from newer version of gnu make (3.81 under kubuntu 12.04)
>
> .PHONEY: all
> all:
> if [ \( "$$(ls *.lock 2>/dev/null)" == "" \) ]; then \

The '==' operator is a bash extension that is supported by many but
not all shells.  Perhaps the shell seen by make on your kubuntu system
is one that doesn't support it?  The portable (30+ years!) equality
operator is "=".

(The '==' operator was an extension that improved usability but added
no new functionality and instead reduced portability; thanks, bash
maintainers, for screwing everyone by making that tradeoff!)


> touch $@.lock; \

This "check for lock file, if it doesn't exist then create it"
operation is *not* 100% safe!  If two makes are run at almost the same
time, they may both see the file doesn't exist and then both touch the
lock file and continue, so the lock file is not actually guaranteeing
that only one copy is running.  You should see if there's a real
atomic lock file program on your system that you can use for this.
For example, I see a "flock" program on a Redhat system that could be
used, those the usage is a bit different.


> if [ \( ! -e $@ \) -o \( ../$(tag_fn) -nt $@ \) ]; then \
>   echo $@ done; \
> else \
>   touch $@; \
> fi; \

Isn't this the same as making $(tag_fn) a dependency of 'all' and
having 'all' *not* be PHONY?


> rm -f $@.lock; \
>   else \
> sleep 1; \
>   fi;

If the lock cannot be obtained, you just sleep a second and then
return success?  Why not at least "exit 1" there so that the caller
can tell that the make failed in a consistent fashion?


Philip Guenther

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: [bug #36881] Sample code for $(eval) is incorrect and fails.

[Philip Guenther]

On Thu, Jul 19, 2012 at 10:14 AM, John Joganic  wrote:
> I was more concerned over the inability to access the information online as
> the vast majority of people who use make get it through binary package
> managers.  The NEWS file is not something that is conveniently available, and
> all my systems, even ones that I recently provisioned, are running 3.81.

The info docs that are part of the installed binary package would
surely match the installed binary.
Either
info make
or
info 'gnu make'

has worked on every system I've seen.


Philip Guenther

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: add Order-only Prerequisites example

[Philip Guenther]

On Sun, Jul 8, 2012 at 4:24 PM,   wrote:
>>>>>> "PS" == Paul Smith  writes:
>>> A:B C;D
>>> A:|B C;D
>
> PS> No.  C will never be run first, before B.  If you enable parallel builds
> PS> then B and C might be run at the same time (but B will still be started
> PS> first, then C).

Paul, as you know, you meant: "*this rule* will not cause C to be run
before B; if *this rule* is the trigger for B and C being built, then
B will be started before C".

An example of how C might be built before B, despite that rule being
used, would be

A: B C; D
E: C A

then "make E" will build in the order C B A E


> OK, I sure hope it will get documented that
> A:B C;D
> implies that if B fails, C will never get run (or built etc.),

What Paul said directly contradicts that.  He said:
 If you enable parallel builds then B and C might be run at the same time

If they're run at the same time, then obviously C will get built even
if B fails!


> and we never have to
> worry about C getting run first (unless we use some -option.)
> I.e., C will only get run after we know the results of B.

Nope, wrong.  If you want make to guarantee that, you must express it
as a dependency between C and B.


Philip Guenther

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: order-only prerequisites don't behave as I'd have expected after reading the documentation

[Philip Guenther]

On Tue, Jun 12, 2012 at 12:59 AM, Stefano Lattarini
 wrote:
> On 06/12/2012 02:06 AM, Philip Guenther wrote:
>> On Mon, Jun 11, 2012 at 12:53 PM, Stefano Lattarini
>>  wrote:
>> ...
>>> I was hoping to be able to the order-only prerequisites to enforce ordering
>>> between .PHONY targets.  At this point, I guess I should state the problem
>>> I am trying to solve rather than just the attempts I've made at solving it.
>>>
>>>   Is there an easy, scalable way to specify in a GNUmakefile that, whenever
>>>   two given targets T1 and T2 (either phony or not) are to be updated, T1's
>>>   recipe must be executed before T2's, all without declaring any dependency
>>>   of T2 on T1?  So that for example, assuming T1 and T2 are both phony:
>>>
>>>     $ make T1 # Only run T1's recipe
>>>     $ make T2 # Only run T2's recipe
>>>     $ make T2 T1 # Run T1's recipe, then T2's recipe
>>>     $ make -j8 T2 T1 # Again, run T1's recipe, then T2's recipe
>>
>> I think I would use a test on $(MAKECMDGOALS) to make T1 a
>> prerequisite of T2 if and only if T1 is a goal, say...
>>
>>      ifneq ($(filter T1,${MAKECMDGOALS}),)
>>      T2: T1
>>      endif
>>
> Not good enough; the "order dependency" I want between T1 and T2 should
> have to work also when they are updated as dependencies of other targets:
>
>    $ cat Makefile
>    all: T1 T2
>    ...
>    $ make all # Ought to work executing T1 before T2.

Given the design of make, with its lazy DAG building, what you are
asking for cannot be done automatically by make, as when it hits T2 as
a prerequisite it cannot know whether a not-yet-considered target will
end up having T1 as a prerequisite.

My gut reaction is that something in this setup is over-simplifying
things or misleading make.  If T1 needs to be done before T2 _ever_,
then why not _always_ have it as a prerequisite of T2?  Is the
.PHONYness of T1 a hack to get around some other limitation and using
some sort of timestamp file would let T1 be not-.PHONY and always be a
dependency of T2?

Whatever.  Insufficient data.  Workaround: use the MAKECMDGOALS test
previously cited but list all the targets that depend on T1 as well in
the $(filter) clause.


Philip Guenther

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: order-only prerequisites don't behave as I'd have expected after reading the documentation

[Philip Guenther]

On Mon, Jun 11, 2012 at 12:53 PM, Stefano Lattarini
 wrote:
...
> I was hoping to be able to the order-only prerequisites to enforce ordering
> between .PHONY targets.  At this point, I guess I should state the problem
> I am trying to solve rather than just the attempts I've made at solving it.
>
>   Is there an easy, scalable way to specify in a GNUmakefile that, whenever
>   two given targets T1 and T2 (either phony or not) are to be updated, T1's
>   recipe must be executed before T2's, all without declaring any dependency
>   of T2 on T1?  So that for example, assuming T1 and T2 are both phony:
>
>     $ make T1 # Only run T1's recipe
>     $ make T1 # Only run T2's recipe

(I think you meant "make T2" there...)


>     $ make T2 T1 # Run T1's recipe, then T2's recipe
>     $ make -j8 T2 T1 # Again, run T1's recipe, then T2's recipe

I think I would use a test on $(MAKECMDGOALS) to make T1 a
prerequisite of T2 if and only if T1 is a goal, say...

 ifneq ($(filter T1,${MAKECMDGOALS}),)
 T2: T1
 endif


Philip Guenther

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: order-only prerequisites don't behave as I'd have expected after reading the documentation

[Philip Guenther]

On Mon, Jun 11, 2012 at 9:40 AM, Stefano Lattarini
 wrote:
> The GNU make 3.82 manual reads:
>
>    Normally, this is exactly what you want: if a target's prerequisite
>    is updated, then the target should also be updated.
>
>    Occasionally, however, you have a situation where you want to impose
>    a specific ordering on the rules to be invoked without forcing the
>    target to be updated if one of those rules is executed.
>
> But if I write a makefile like this:
>
>    ALL = a b c d
>    default:
>        echo Specify a target: $(ALL); exit 1
>    .PHONY: $(ALL)

What is your intent for declaring all the targets PHONY in this Makefile?

(Note: to quote 4.6 Phony Targets:
A phony target should not be a prerequisite of a real target file;
if it is, its recipe will be run every time `make' goes to update that
file.  As long as a phony target is never a prerequisite of a real
target, the phony target recipe will be executed only when the phony
target is a specified goal (*note Arguments to Specify the Goals:
Goals.).
)


Philip Guenther

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: Feature request

[Philip Guenther]

On Sat, Mar 3, 2012 at 6:30 PM, Odne Hellebø  wrote:
...
> I have A.java which uses B.java and thus the rule becomes this  A.java B.class>, but I don't need to recompile A.java if B.class is changed,
> I just need B.class to be there with the features I use in A.class. So what
> I suggest is that we seperate the prerequisites and the "file uses these
> things" like . Where everything after £ is just
> checked to see if it exists.
...

If I understand what you're asking for, it's been present in GNU make
for almost 10 years under the name "order-only prerequisites".  Read
the GNU info pages for details of the syntax and to confirm that it
does what you want.


Philip Guenther

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: [bug #35132] Side effects of .SECONDARY with no targets not documented

[Philip Guenther]

On Tue, Dec 20, 2011 at 2:07 PM, anonymous  wrote:
> There are some side effects associated with intermediate/secondary targets
> that aren't documented in any real detail in the documentation.
>
> The documentation for .SECONDARY gives the impression you can use .SECONDARY
> to disable automatic deletion of intermediate targets, but doing so causes a
> number of side effects that produce unpredictable behavior in a build.
>
> Unfortunately, I do not have a concise or publishable example demonstrating
> the problem; however, I outlined it on this thread:
>
> http://groups.google.com/group/gnu.utils.bug/browse_frm/thread/d882703f60b20ea5?hl=en#

To confirm, when you say "thread", you mean "my single post", right?
I want to be sure that link isn't leaving off replies or something...

That said, your post references rules that build symlinks to other
files...and then you leave out important details of the cases that
cause problems.  If you don't have the time to find a minimal test
case, can you at least spend the time to figure out the conditions
under which the problem occurs?  If not, how are we, who don't have
access to your system, supposed to figure that out?  You might get
lucky...or you might just be pissing into the wind.

So: does the problem only occur when the symlink already exists?  Or
when the symlink *doesn't* exist?  Is this a recursive make setup?  If
so, which makefiles have which rules?  How can we debug this when you
don't provide *ANY* examples of a rule for building one of those
symlinks?

As for issue problem with .PRECIOUS, well, it works with patterns for
me; please provide an actual example.


Philip Guenther

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: Fw: error

[Philip Guenther]

On Sun, Dec 4, 2011 at 10:03 AM, Rajendra Shivade
 wrote:
...
> checking for suffix of object files... configure: error: in 
> `/home/durgesh/objdir/i686-pc-linux-gnu/libgcc':
> configure: error: cannot compute suffix of object files: cannot compile
> See `config.log' for more details.
> make[2]: *** [configure-stage1-target-libgcc] Error 1

This is a problem with gcc's configure script and/or your build
environment and has nothing to do with GNU make.  You've (apparently)
already posted your question to a mailing list for gcc; waiting for
help from there is the right thing to do.


Philip Guenther

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: [bug #33034] "Makefile:23: *** mixed implicit and normal rules. Stop." for Linux kernel out of source builds

[Philip Guenther]

On Fri, May 20, 2011 at 12:46 PM, David Boyce  wrote:
> My company makes drivers. The corollary is that we keep dozens if not hundreds
> of entire Linux kernel source build trees going back 10 years or so in order
> to build drivers for them. The way Linux kernel drivers are built makes it
> necessary to use the kernel build system. Thus it's not sufficient for us to
> fix our own makefiles, or even that Linux kernels which came out in the last
> year are fixed themselves. As things stand, we'll be unable to upgrade from
> GNU make 3.81 until all pre-2010 kernels have drained out of our support
> matrix, which could easily be another 10 years. Of course we also have the
> option of going back and "fixing" the makefiles for each old kernel, but once
> you've changed 2.6.18-128.7.1 then it's no longer 2.6.18-128.7.1.

Since gcc has changed many time across those years in ways that have
affected the Linux kernel build (the move to
__attribute__((always_inline)) comes to mind), don't you already have
to track a build environment for each kernel version?  I haven't
tried, but I believe that the current version of gcc will *not* build
a 10 year old kernel, or at least not a _working_ one.  For that you
need a 10 year old gcc, or at least something much closer to it in
time.  Well, the same applies to GNU make and may apply to other build
tools (binutils/as/ld?).  Whatever system you use for tracking gcc
releases should be applied to all the tools in the kernel build
environment.


Philip Guenther

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: [bug #33134] spurious error when stdout is already closed

[Philip Guenther]

On Thu, Apr 21, 2011 at 3:50 AM, David Boyce  wrote:
> All quite true and admirably researched but this is not a
> standards-lawyering exercise, it's a software-engineering issue.

Why are you closing stdout instead of redirecting it to /dev/null?


Philip Guenther

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: [bug #33134] spurious error when stdout is already closed

[Philip Guenther]

On Wed, Apr 20, 2011 at 9:31 PM, David Boyce  wrote:
> On Thu, Apr 21, 2011 at 12:00 AM, Philip Guenther  wrote:
>> Why is that a mistake?
>>
>> It appears you're saying that make should complain about failures to
>> write to stdout for reasons like EIO, ENOSPC,  and EOVERFLOW, but
>> *not* for EBADF.
>
> I think you're still not getting my point here. I do not believe this
> has anything to do with *writes* at all, failed or otherwise. Make is
> attempting to close something that's already closed and complaining
> when it doesn't work. POSIX is quite clear that fclose on a closed
> stream results in an error condition.

First, stdout is *NOT* a closed FILE.  It is a FILE that claims to be
attached to an fd that isn't open  There is *NO* provision in the C,
POSIX, or SUS standards for stdout to not be a FILE that can be passed
to the various stdio operations, even if fd 1 is closed and the
underlying operations all result in EBADF.

Next, close_stdout() doesn't just call close(), but rather fclose(),
which is *much* different.  In particular, fclose() flushes stdio
buffers, in which case it will call write().  By failing to call
fclose(), you'll lose any final buffered data.

close_stdout() doesn't just call fclose() but also ferror(), to see if
there was a previous error on the FILE.  It's not uncommon for
programs to leave out some or all error checks for writing to FILEs
and only check at the end, to see whether fclose() failed or similar.
In this case, the difference in error messages (that it didn't include
the "Bad file descriptor") plus the review of the logic shows that
make does *exactly* that.

And yes, write()s *are* failing.

$ cat Makefile
$(info hello)
all:
@:
$ ktrace make  >&-
make: write error: Bad file descriptor
$ kdump | grep write
 31284 gmakeCALL  write(0x1,0x202429000,0x6)
 31284 gmakeRET   write -1 errno 9 Bad file descriptor
 31284 gmakeCALL  write(0x2,0x7f7bf0f0,0x6)
 31284 gmakeRET   write 6
 31284 gmakeCALL  write(0x2,0x7f7bf1d0,0x20)
   "write error: Bad file descriptor"
 31284 gmakeRET   write 32/0x20
 31284 gmakeCALL  write(0x2,0x82b0e7,0x1)
 31284 gmakeRET   write 1
$


> but I lost the EBADF test when I redid it. That was a mistake, and
> maybe there's a better way of checking for closure than ftell anyway,
> but the basic point of not closing something unless it was open
> remains.

What problem are you trying to solve?  Do you find that fclose(stdout)
is exhibiting some sort of undefined behavior on your systems?


Philip Guenther

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: [bug #33134] spurious error when stdout is already closed

[Philip Guenther]

On Wed, Apr 20, 2011 at 7:36 PM, David Boyce  wrote:
> On Wed, Apr 20, 2011 at 9:58 PM, Philip Guenther  wrote:
>> Could you explain why you think that's spurious?  Make wanted to write
>> "date" to stdout and the write failed.  Seems legit to me.
...
> Basically in a (sensible and nicely documented) attempt to detect all
> errors, make does an explicit close of stdout just before exiting in
> order to make one last check for failure modes. However, it makes the
> mistake of assuming stdout was open to start with.

Why is that a mistake?

It appears you're saying that make should complain about failures to
write to stdout for reasons like EIO, ENOSPC,  and EOVERFLOW, but
*not* for EBADF.  Does the POSIX standard specify that that error
should be handled differently by make?

(Actually, your patch doesn't just ignore EBADF errors: it ignores
EPIPE errors, as the ftell() will fail on the pipe.  Why is that a
good idea?)


Philip Guenther

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: [bug #33134] spurious error when stdout is already closed

[Philip Guenther]

On Wed, Apr 20, 2011 at 6:03 PM, David Boyce  wrote:
...
> Ironically, make's attempt to be super-duper careful about catching write
> errors to stdout (in the close_stdout function) results in a spurious error
> message when the user has already closed stdout:
>
> % cat makefile
> .PHONY: all
> all:; date
>
> % make 1>&-
> make: write error
>
> Patch attached.

Could you explain why you think that's spurious?  Make wanted to write
"date" to stdout and the write failed.  Seems legit to me.

(I'm not sure why it doesn't say "make: write error: Bad file
descriptor" like it does if you change the command invoked to ":", but
that's a distinct issue.)


Philip Guenther

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: mention how to get the other half of $*

[Philip Guenther]

On Mon, Mar 14, 2011 at 5:30 AM,   wrote:
> (info "(make) Automatic Variables") says
> `$*'
>     The stem with which an implicit rule matches
>
> OK, that is the stem. Now mention what can we use to get the other half.
> OK, the answer apparently is here. Please mention it.
> %.xcf %.jpeg:%.pdf; gs -sDEVICE=$(subst .,,$(suffix $@)) -sOutputFile=$@ 
> -dNOPAUSE -dBATCH $?
>                                

That rule is not correct: it *claims* to generate both whatever.xcf
_and_ whatever.jpeg when its commands are run, but it does not do so.
The result is that if you ask make to build both files, it will only
generate one of them.  You need separate pattern rules to get what you
want.

I would probably just write it like this:

run_gs = gs -sDEVICE=$1 -sOutputFile=$@ -dNOPAUSE -dBATCH $<
%.xcf: %.pdf; $(call run_gs,xcf)
%.jpeg: %.pdf: $(call run_gs,jpeg)

(Yes, you could use $(foreach) and $(eval) to iterate across the types
and define rules for each...and it'll take you longer to write and GNU
make longer to process.)


Philip Guenther

___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: [PATCH] Options: `--dry-run' should prevent `--touch' from touching

[Philip Guenther]

On Tue, Mar 8, 2011 at 1:37 PM, Michael Witten  wrote:
> The `--dry-run' flag is supposed to be safe in that nothing
> in the file system is actually modified.

That's not actually true.  To quote the docs:

`-n'
`--just-print'
`--dry-run'
`--recon'
 "No-op".  The activity is to print what recipe would be used to
 make the targets up to date, but not actually execute it.  Some
 recipes are still executed, even with this flag (*note How the
 `MAKE' Variable Works: MAKE Variable.).

and then later on the same page:

   The `-n', `-t', and `-q' options do not affect recipe lines that
begin with `+' characters or contain the strings `$(MAKE)' or
`${MAKE}'.  Note that only the line containing the `+' character or the
strings `$(MAKE)' or `${MAKE}' is run regardless of these options.
Other lines in the same rule are not run unless they too begin with `+'
or contain `$(MAKE)' or `${MAKE}' (*Note How the `MAKE' Variable Works:
MAKE Variable.)


At least part of that behavior is required by the POSIX specification
and has a few decades of history behind it.


Philip

___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: Intermittent parallel make rebuild failures

[Philip Guenther]

Looking backwards, this rule from your toplevel makefile:

> $(INF_DIST_SVCS_OBJS): $(DIRS)

seems bogus, given that $(INF_DIST_SVCS_OBJS) is a list of objects in
directories _below_ the list of directories in $(DIRS).  The toplevel
make may recurse, then on popping back out see that the *SOURCE
DIRECTORY* didn't change, and thereby decide that the object must not
have changed.

It looks me like your makefile is misleading make.

Can you give examples of the output of make when this stuff *isn't*
working?  Preferable minimal, of course, where only a single source
file was changed/recompiled, showing how make failed to rebuild
everything that it you wish it would, and then the output of the
second make invocation that builds the missing piece?ou


I don't trust dependencies on directories; you have a dependency on a
directory WHOSE CONTENTS AREN'T BEING CHANGED.  That raises florescent
red flags to me.


Philip Guenther

___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: Intermittent parallel make rebuild failures

[Philip Guenther]

On Thu, Oct 7, 2010 at 9:22 AM, David Highley
 wrote:
...
> Let us just cut to the essence of the issue we are running into, how do
> target prerequisites get processed in version 3.81 of make?
>
> Example:
> $(LIBRARY): $(INF_DIST_SVCS_OBJS)
>
> $(INF_DIST_SVCS_OBJS): $(DIRS)
>
> $(DIRS):
>
> .PHONY: $(DIRS)
>
> With parallel building how does the macro $(INF_DIST_SVCS_OBJS) get
> evaluated before the target $(DIRS) is done? Is there a method to stop
> this other than turning parallel building off?

Have you read the info pages section "How `make' Reads a Makefile"?
In it, it explains that variables in targets and prerequisite lists
are expanded immediately when the rule is read during the parsing of
the Makefile.  So, *before any targets have been built*,
$(INF_DIST_SVCS_OBJS) will be expanded twice during the parsing of the
above Makefile snippet, once when the $(LIBRARY) rule is parsed and
once when the $(INF_DIST_SVCS_OBJS) rule is parsed.

The -j option has no effect on that, so I don't understand your last
question above.  Or are you saying that this makefile is part of a
recursive make setup, so that it might be read multiple times, the
earlier of which could affect the latter of which?


Philip Guenther

___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: GNU make distribution with proprietary products

[Philip Guenther]

On Wed, Aug 4, 2010 at 12:27 PM, tom honermann  wrote:
> On 8/4/2010 11:25 AM, Alfred M. Szmidt wrote:
>> 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.
>
> Ah, yes, if only the world were that simple.  Alas, the world consists of
> many software producers that do not share this view, but still function in
> accordance with the laws of their respective governments.  I'm
> attempting to identify (at least) one of them.

The tone of these messages seem...unfriendly to the practice.  I've
seen software that does what you describe, but I see no reason to
identify them to be pilloried for it.

What problem are you trying to solve?


Philip Guenther

___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: including makefile name and line number for shell_function_completed

[Philip Guenther]

On Sat, Jul 31, 2010 at 4:54 PM, Jon Grant  wrote:
> I am using make 3.81 built for MinGW.
>
> How easy to output the Makefile.mak:line for each command that fails to start?

I don't think there's any way for a snippet of Makefile to figure out
what its line # and filename are.  The $(warning) function will
include them in its output, but I don't see any way to trigger that
based on the success or failure of a command without completely
changing how the makefile operates.

Hmm.

So, what's needed is for a future version of GNU make to provide some
way to get the current filename and line number.  Now, that could mean
a number of things.  The *obvious* answer would be to provide
$(filename) and $(linenumber) functions that expand to the line number
and filename where they are expanded.  I'm 80% sure that that's the
right choice.  Consider the following sort of makefile:
--
define rules
echo "build $@ at $(filename):$(linenumber)"
@touch $@
endef

foo:
$(rules)
--

Should the reported line number be that of the use of $(rules), or
should it be where $(linenumber) was writen?  I'm mostly convinced
that the answer is the former, but I have slight misgivings and I
suspect there are places where someone would want immediate expansion.


Philip Guenther

___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: insufficient debug info from gnu-make

[Philip Guenther]

On Sat, Jul 31, 2010 at 7:19 PM, Peter Lawrence
 wrote:
> On Jul 31, 2010, at 9:41 AM, Eli Zaretskii wrote:
>>>           one thing I remember in detail about Sun's make, is that
>>> instead of writing a level number
>>>
>>> make[3]: ...
>>> make[2]: ...
>>> make[1]: ...
>>>
>>> it wrote out the directory that the commands had cd'ed to before
>>> recursing (and maybe the file name, can't be sure any more)
>>>
>>> make[foo/bar]: ...
>>> make[foo]: ...
>>> make[.]: ...
>>
>> GNU Make displays the equivalent "Entering directory foo..." and
>> "Leaving directory foo..." messages.  Isn't that the same info?
>
> the words "Entering" and "Leaving" never appear in the output I captured

So are you going to read the GNU make info pages to see what
conditions make will generate those messages and how something might
have suppressed them?  Perhaps the gcc maintainers have decided that
they hate those messages and have told GNU make to not generate them.
If so, complaining to make developers will result in absolutely no
progress.  You need to figure out who actually has control over the
stuff that's bugging you.


> typical output from gnu-make when making gcc is such
> tossed-salad-scrambled-eggs that nothing is readable,
> most lines are hundreds of characters long, as you can
> see below the average is over 400 chars/line, here is
> some sample output from my failed build, you can't
> really tell much of anything from reading this output

That problem (monstrously long compile lines) has absolutely nothing
to do with make and there's nothing that make can do about it.  That's
just a problem with the makefile itself and needs to be taken up with
the authors of that.


Philip Guenther

___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: [RFC]serialize the output of parallel make?

[Philip Guenther]

On Thu, Jul 29, 2010 at 11:29 PM, Chiheng Xu  wrote:
...
> My suggestion is that you can implement it as an optional command line
> option(like -j), and on one or two primary platforms(Linux/Windows),
> instead of on all platforms.

So, the complexity of both possibilities.  You're writing, debugging,
and contributing this code yourself?

(I would hope that this wouldn't require any Linux-specific code;
perhaps you meant "POSIX & Windows"?)


...
> The scenario like "make -j4 2>/dev/null" may be very rare, but
> scenario like "make -j4  2>&1 |  tee output.txt" may be common.

And what, exactly, are you suggesting that make do to reflect that
guess about usage patterns?


Philip Guenther

___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: [bug #29757] Target-specific variables change their flavor

[Philip Guenther]

On Fri, Jun 25, 2010 at 11:44 PM, Vitaly Grechko
 wrote:
> Follow-up Comment #2, bug #29757 (project make):
> Sorry. You were right. But this is not convenient to have just one way to
> append to a variable. Note that at least 2 *makes have :+= operator: dmake and
> fastmake. I guess GNU make could think about it.

Beware: even plain ":=" isn't implemented the same everywhere, even if
you ignore the appending issue.  I've seen at least one version where
":=" means "expand the right-hand side immediately, and then otherwise
act like '='", with the result that the right-hand side is expanded
*twice*.


Philip Guenther

___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: [bug #29757] Target-specific variables change their flavor

[Philip Guenther]

On Fri, Jun 25, 2010 at 2:03 PM, Vitaly Grechko  wrote:
> Follow-up Comment #1, bug #29757 (project make):
>
> I think you are wrong. Simple or deferred expansion is connected to operator,
> not variable.

Maybe in some other "*make" program, but not in GNU make.  To quote
the info pages:

   For the append operator, `+=', the right-hand side is considered
immediate if the variable was previously set as a simple variable
(`:='), and deferred otherwise.


> Variable does not know what way it was assigned.

They do in GNU make.  Note that += isn't standardized.


Philip Guenther

___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: Shorter and less error-prone rule for automatic prerequisite generation in the GNU Make manual

[Philip Guenther]

On Fri, Apr 30, 2010 at 5:46 AM, Edward Welbourne  wrote:
>> The fix for that has been documented for years on Paul's webpage, and
>> is most easily done now with gcc's -MP option.
>
> URL ?

http://make.paulandlesley.org/autodep.html#norule

(That explains the problem and what needs to be put in the dependency
files to solve it, and then gives an implementation that works with
all 'makedepend' methods; gcc's -MP option came later is is just an
optimized method for those using -MD)



Philip Guenther


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: Shorter and less error-prone rule for automatic prerequisite generation in the GNU Make manual

[Philip Guenther]

On Thu, Apr 29, 2010 at 3:59 AM, Edward Welbourne  wrote:
>> Delete a "clean-depend" rule on sight,
>
> I cannot agree.
> If I write a rule to make something, I also write a rule to get rid of
> it.  It's just basic hygiene ...

I propose the following guideline: If you have a target that generates
A (and B as a side-effect), then a 'clean*' rule that deletes B should
also delete A (and vice versa).

So, I do have a rule to delete *.d files, it's called "clean".  Since
I don't have rules for building .d files other than with .o files, it
Just Works.


>> or rename it to the more accurate "break-future-builds".
>
> If you have a sensible rule to generate .d files when needed, you
> haven't broken your builds - you've just obliged yourself to
> regenerate .d files.  Which may be wasteful, but see below.

Okay, so if you have a rule to delete .d files without deleting .o
files, you need rules to build .d files.  In my experience, the only
reason to have *either* of those is "because that's how the Makefile
was originally written and the current behavior doesn't hurt enough
for me to spend the time to fix it".


...
> Speaking of the subtleties of dependency tracking: do an update in
> your version control system, watch some header go away - and all files
> that used to reference it drop those references.  Your .d files claim
> a bunch of stuff depends on this missing file; but you have no rule to
> regenerate it.  So make will not even try to compile anything (even
> though everything *would* compile fine) because your .d file say that
> all the .o files that need recompiled depend on a file that doesn't
> exist any more; make clean-depend fixes that.

The fix for that has been documented for years on Paul's webpage, and
is most easily done now with gcc's -MP option.


> If generating .d as a side-effect, don't listen to the manual's advice
> that says you need to sed its content to claim that the .d depends on
> the same things the .o does.  If those things have changed, the .o
> shall be regenerated and hence so shall the .d; and you don't need
> this updated version of the .d file to discover that the .o needs
> rebuilt.  Changes to .h files consequently never trigger re-exec.

Ah, it looks like your comments are addressed at just what's in the
GNU make info pages and not the advanced method on Paul's webpage.  I
agree that what's in the info pages has many of the problems you
mention...which is why this thread is about updating what's there.


Philip Guenther


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: Shorter and less error-prone rule for automatic prerequisite generation in the GNU Make manual

[Philip Guenther]

On Wed, Apr 28, 2010 at 7:12 AM, Edward Welbourne  wrote:
>> It's also unnecessary - you don't need a rule for %.d at all. You can
>> just generate the dependencies as a side-effect of compilation using
>> -MMD or similar.
>
> Well, if a .d file gets deleted while its .o file exists, you do need
> to regenerate it - or regenerate the .o (which may cause wasteful
> knock-on actions since it's now newer than it was, even if unchanged).
> This matters if, for example, you have a make clean-depend rule to
> purge dependency information.

Delete a "clean-depend" rule on sight, or rename it to the more
accurate "break-future-builds".  I can think of absolutely no reason
to delete dependency files without deleting the objects they describe.


>> Then use '-include' to grab all the deps if they exist.
>
> better: include only the .d files that correspond to .o files *that
> exist* - if the .o file doesn't exist, you don't need to know what it
> depends on, aside from the primary source from which it's compiled
> (which is indicated by the pattern rule that makes the .o file).

Yeah, that's true.  Nice.


>> By providing a rule for the .d files you'll cause make to
>> re-execute itself, so you'll just end up parsing the Makefile twice.
>
> Only if you include .d files that aren't really needed (which is
> common practice).

There's still the case of a .o and .d pair that both exist where the
.o is out of date to one of its dependencies.  If the .d file is a
target, then make will first rebuild the .d, re-exec, then rebuild the
.o.  The re-exec is unnecessary there; building the .d as a
side-effect of building the .o is sufficient.


Philip Guenther


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: Static multiple target rules

[Philip Guenther]

On Mon, Mar 29, 2010 at 7:54 PM, tom honermann  wrote:
> Paul, would you be opposed to a patch that implements support for static
> multiple target rules using the above syntax?
> Any particular concerns or requirements you would have?
...
>   a1 (b1 b2 b3): d1
>       touch -r $^ $@
>
> Note the space between 'a1' and the left parenthesis.  This is required so
> that the target is not parsed as an archive member.

Hmm.  SysV make has offered the desired feature with the syntax

b1 + b2 + b3: d1
touch -r $^ $@

It appears the sysV implementation doesn't let you declare multiple
groups with a single rule, but that's not a restriction of the syntax
itself.  Yes, that syntax has a meaning in GNU make (treating '+' as a
target), but it's clearly not a portable name for a target.  (Indeed,
plus-sign is not part of the POSIX "Portable Filename Character Set".)


The proposed syntax already has a conflicting special meaning in GNU
make (multiple archive-member target) for what would be the common
case of a single group.  That is, this:

(b1 b2 b3): d1
whatever

currently means "the b1, b2, or b3 members of any archive library
depend on d1 and are updated by running 'whatever'".  The fact that
it's a special syntax means that it's more likely to actually be in
use out there.  How will the proposed change affect Makefiles using
that syntax?

(While I don't think the sysV syntax is *great*, I personally think
it's a better choice than overloading the meaning of parentheses.)


Philip Guenther


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: Weird text-dependent bug in $(eval ...), simple test case

[Philip Guenther]

On Sun, Feb 28, 2010 at 6:25 PM, Jamie Lokier  wrote:
> Both of you have confirmed the bug - because the correct behaviour has
> no error messages, and you both got messages.  Neither of you was able
> to reproduce getting a text-dependent number of messages, but both of
> you see buggy behaviour so it's easy to reproduce a problem to investigate.
>
> Nobody wants to investigate this bug further?

Not to make an insane suggestion, but have you considered filing a bug
in the GNU bug tracking system, Savannah?
http://savannah.gnu.org/projects/make/

As a side note, I don't understand why you call this a bug in
$(eval)...as it's completely reproducible without using $(eval)!  Did
you try testing it directly?  If not, why not?

We've seen this on the list now multiple times: it seems that if
someone first encounters a bug while working with $(eval), they report
the problem as being in $(eval) and make no attempt to reproduce it
directly.  Since this is a hinderance to getting good bug reports, it
would help if you could examine why this happened in this case so that
it might possible be avoided in the future with others.


Philip Guenther


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: Prioritizing non-dependent targets in parallel make

[Philip Guenther]

On Thu, Dec 24, 2009 at 7:16 AM, Paul Smith  wrote:
> On Thu, 2009-12-24 at 01:08 -0800, tom honermann wrote:
>> There are many valid orders in which the targets can be built.  When make
>> is invoked with the parallel execution (-j) option, the order in which the
>> non-dependent targets are scheduled has a significant impact on the total
>> run time.
>
> You can already completely control the order in which targets are
> invoked, even when using -j.
>
> At all times, make will try to build prerequisites starting with the
> first one in the prerequisite list, and continuing in order to the last
> one in the list.

The problem is that only works for the direct dependencies.  I think
the OP's request is more about stuff buried more than one level deep.
E.g., program "prog" requires two libraries, each one of which has
multiple objects of varying size, with one object in each taking
particularly long to compile, say:

prog: prog.o liba.a libb.a
liba.a: a1big.o a2.o a3.o a4.o a5.o
${AR} rc $@ $^
libb.a: b1big.o b2.o b3.o b5.o b5.o
${AR} rc $@ $^

Now, let's say a2.o, a3.o, a4.o, a5.o and b1big.o are out of date.
"make -j2 prog" will rebuild them in that exact order, but it would
take less total time if make started rebuilding b1big.o first.  Static
reorderings of the prerequisite lists can't solve this.

Personally, while I'm sympathetic to the concern, I think this is the
sort of problem where the consequences of the solution are likely to
be greater than expected and it should probably be handed to some CS
grad student as a possible research project.  Isn't that what grad
schools are for, banging on possibly open-ended problems?


Philip Guenther


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: [bug #27714] expansion of $(shell) in target forces serialization of targets

[Philip Guenther]

On Fri, Oct 16, 2009 at 4:34 AM, Paul D. Smith  wrote:
...
> But before it can invoke the recipe it has to expand all the variables and 
> functions.

I had to ponder that requirement for a bit before it occurred to me
that doing otherwise would either make $(eval) pointless in recipes or
make it an incredible, royal pain to implement.  Ditto for $(error).


Philip Guenther


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: GNU make to consider files checksum

[Philip Guenther]

On Mon, Sep 28, 2009 at 11:05 AM, Giuseppe Scrivano  wrote:
> it looks like a good idea.  Do you think it worths to be discussed with
> automake hackers?

I'm not actually convinced that this checksumming is a good idea,
mainly because I'm not convinced this is enough of a problem.  The
point of my message was just that this problem *can* be solved at the
makefile level.  Attacking it by changing automake sounds practical
and probably a faster way to a solution, though I would prefer it to
be optional even there.

(Have you measured how often this sort of thing would save
recompilation and/or relinking and how much time it would save then?
What's the comparison to how much time would be spent calculating the
checksums?  If it saves a minute once every 100 compiles but costs a
second in each of those, then it's a net loss...)

Philip Guenther


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

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

[Philip Guenther]

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 that file in a subdirectory,
unlike practically all other projects.)


Philip Guenther


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: GNU make to consider files checksum

[Philip Guenther]

On Fri, Apr 11, 2008 at 2:45 PM, Giuseppe Scrivano wrote:
> I could find on this ML archives only a thread about this subject: to
> consider the file checksum instead of the timestamp.
> Other systems like scons already support this feature and it would be
> great to have it for GNU Make too.

This is a long dead thread (it's been sitting in my mailbox for a
year, ouch), but I'll throw in my two cents that a makefile can
implement this for itself with pattern rules.  Consider:


%.o: %.c
%.o.new: %.c
$(COMPILE.c) -o $@ $<
%.o: %.o.new
@{ [ -f $...@.md5 ] && md5sum -c --status $...@.md5; } || \
{ md5sum $< >$...@.md5; cp $< $@; }

.SECONDARY:
-

Poof, if you touch a .c file without making changes that affect the
compiler output, the executable will not be relinked.  Indeed, the
presence of the .SECONDARY target means the only thing that will be
rerun each time is the md5sum.

Yes, this is non-trivial to use, but it's also completely flexible,
letting you use whatever checksum comparison you want (need to strip
comments or RCS/CVS tags from the file before checksumming it?  Sure!)
and can be used Right Now.

Anyway, we now return you to your originally scheduled mailing list.


Philip Guenther


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: Why "*** extraneous `endef'. Stop."?

[Philip Guenther]

On Sun, Sep 6, 2009 at 8:09 AM, Sergey Zubkovsky wrote:
> It seems to me this is a bug.
>
> All will be fine if we just rewrite 'ifneq (1,1)' as 'ifeq (1,1)'.
>
> That is why I sent the question.
> I hope someone will add an item in the bug tracker (who know `make' better
> than me and will confirm this supposition).

Sure looks like a bug to me.  Note that this has nothing to do with
$(eval); it's presence in your example just confuses the issue.  You
can see the issue directly with this:

ifneq (1,1)
define var1
define var2
endef
endef
endif


I suggest you visit
http://savannah.gnu.org/projects/make

and submit the bug.


Philip Guenther


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: [bug #27374] fatal error reading included makefile silently ignored

[Philip Guenther]

On Wednesday, September 2, 2009, Michael Coleman
 wrote:
...
> (I'm tempted to say that make should specifically disallow a file from
> including itself (even indirectly).  Perhaps there is some use for this,
> though.)

I have some subsidiary makefiles that include themselves as long as a
variable isn't empty to implement unbound iteration, which $(for)
can't do.

Philip Guenther


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: Segmentation fault in make-3.81

[Philip Guenther]

On Mon, Aug 3, 2009 at 2:22 AM, Glenn Coombs wrote:
...
> You're quite right and your solution above is indeed the sensible way to
> write it :-) However, I'd just been reading about the new features added in
> make 3.81 and was experimenting.

Well, be careful: $(eval) is great for removing fingers.  For example,
the value being assigned to CHIPNAME in this:
$(eval CHIPNAME := $(shell echo $* | tr a-z A-Z))

has expansion performed on it twice.  That almost certainly isn't a
problem in this case, but if you overlook it here
then you might not remember it when it does matter.  That line would
be better written, IMO, as:
$(eval CHIPNAME := $$(shell echo $$* | tr a-z A-Z))


> Still, having make throw a segmentation fault is bad so I figured it was
> worth reporting the issue so that the problem could be fixed.  After all,
> the next person to run into the same bug might not be using such a simple
> makefile with easy alternatives.

Sure.


Philip Guenther


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: Segmentation fault in make-3.81

[Philip Guenther]

On Fri, Jul 31, 2009 at 8:03 AM, Glenn
Coombs wrote:
...
> I encountered this issue when I added the eval at line 18 so that I could
> set CHIPNAME to the uppercase of the filename stub.

Is there some reason that you didn't use the solution that works in
every version of make that has ever been written and instead used a
complex solution that only has a chance of working in the most recent
versions of a single make implementation?

%_struct.h: %_struct.def
ifdef VERBOSE
CHIPNAME=`echo $* | tr a-z A-Z` ; \
$(REGCONV) -chipname $$CHIPNAME $< -simout $@
else
@CHIPNAME=`echo $* | tr a-z A-Z` ; \
echo Creating regconv header file CHIPNAME=$$CHIPNAME: $(notdir $@) ; \
$(REGCONV) -chipname $$CHIPNAME $< -simout $@
endif


If the duplication bugs you:

set_chipname = CHIPNAME=`echo $* | tr a-z A-Z`
regconv = $(REGCONV) -chipname $$CHIPNAME $< -simout $@
ifdef VERBOSE
  describe = echo "$(regconv)"
else
  describe = echo "Creating regconv header file CHIPNAME=$$CHIPNAME:
$(notdir $@)"
endif

%_struct.h: %_struct.def
@${set_chipname}; ${describe}; ${regconv}


(Yeah, it's a bug in make that it crashes on your makefile...but that
makefile just seems like the wrong way to solve your problem.)


Philip Guenther


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: .SECONDARY vs. .PRECIOUS doc of danger

[Philip Guenther]

On Mon, Jun 29, 2009 at 9:32 AM,  wrote:
> You fellows have a lot of explaining to do. (On the Info page, not to me.)
>
> In (info "(make) Special Targets")
> `.PRECIOUS'
>     ...Also, if the target is an intermediate file, it will not be
>     deleted after it is no longer needed, as is normally done... In
>     this latter respect it overlaps with the `.SECONDARY' special
>     target.

If you keep reading you'll see this:

 You can also list the target pattern of an implicit rule (such as
 `%.o') as a prerequisite file of the special target `.PRECIOUS' to
 preserve intermediate files created by rules whose target patterns
 match that file's name.

In contrast, the description of .SECONDARY only mentions targets and
not target patterns.


> However we see that only genuine .PRECIOUS will preserve the
> intermediate file. .SECONDARY, on the other hand, will blow - it - away.
>
> $ ls
> Makefile  u.kml
> $ cat Makefile
> .SECONDARY:%.kmz

As documented, .SECONDARY does not support target patterns, so the
difference in behavior is expected.



Philip Guenther


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: Section 3.8 of the info manual not respected

[Philip Guenther]

On Wed, May 27, 2009 at 10:03 AM, Anthony Shipman  wrote:
> On Wed, 27 May 2009 11:26:14 am Philip Guenther wrote:
...
>> The paragraph just above the example says this:
>> 
>>    For example, if you have a makefile called `Makefile' that says how
>> to make the target `foo' (and other targets), you can write a makefile
>> called `GNUmakefile' that contains:
>> 
>>
>> I.e., you *first* must have a file "Makefile" in the current
>> directory.  The error message you got says that you don't have that,
>> so of course the example doesn't work.
>
> I expected that "make foo" would cause "frobnicate > foo" to be run and not
> require a file called Makefile to exist. I thought that the Makefile would
> only be used when a "make bar" is attempted.

So, umm, why are you playing with this example?


Philip Guenther


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: Section 3.8 of the info manual not respected

[Philip Guenther]

On Tue, May 26, 2009 at 9:45 AM, Anthony Shipman  wrote:
> I've tried the example in section 3.8 Overriding Part of Another Makefile.
> i.e.
>
> foo:
>        frobnicate > foo
>
> %: force
>       �...@$(MAKE) -f Makefile $@
>
> force: ;
>
> The command 'make foo' results in
>
> make[1]: Makefile: No such file or directory
> make[1]: *** No rule to make target `Makefile'.  Stop.
> make: *** [GNUmakefile] Error 2


The paragraph just above the example says this:

   For example, if you have a makefile called `Makefile' that says how
to make the target `foo' (and other targets), you can write a makefile
called `GNUmakefile' that contains:


I.e., you *first* must have a file "Makefile" in the current
directory.  The error message you got says that you don't have that,
so of course the example doesn't work.

Since you don't have a Makefile already, why are you trying to use an
example for overriding an existing makefile?


> An implicit rule search is performed for the target GNUmakefile. This is not
> expected.

While GNU make will automatically try to rebuild its makefile, that's both
A) completely expected, and
B) not at all related the error message you quoted.


Philip Guenther


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: automatic linking links too many files

[Philip Guenther]

On Fri, May 22, 2009 at 8:04 AM, James Coleman  wrote:
...
> 4.
> I notice that adding a static library doesn't get picked up by a default
> rule. I'm not going to dig further into this. My syntax for libs might be
> wrong, makefile.lib:
> executable: othercfile.o staticlibrary.a
>
> staticlibrary.a: yetanothercfile.o
>
>
> $ make -f makefile.lib
> g++    -c -o othercfile.o othercfile.cpp
> g++    -c -o yetanothercfile.o yetanothercfile.cpp
> g++     executable.cpp othercfile.o staticlibrary.a   -o executable
> g++: staticlibrary.a: No such file or directory
> make: *** [executable] Error 1

Almost.  To trigger the built-in library archiving rules you need this:

executable: othercfile.o staticlibrary.a
staticlibrary.a: staticlibrary.a(yetanothercfile.o)

$ make
g++-c -o othercfile.o othercfile.cpp
g++-c -o yetanothercfile.o yetanothercfile.cpp
ar rv staticlibrary.a yetanothercfile.o
ar: creating staticlibrary.a
a - yetanothercfile.o
g++ executable.cpp othercfile.o staticlibrary.a   -o executable
rm yetanothercfile.o
$


However:
1) the syntax is annoyingly redundant, using the .a name twice
2) it unnecessarily rebuilds the archive's symbol table after each addition
3) it breaks if you have multiple files in the archive and use parallel make

(If your system's ar doesn't rebuild the symbol-table by default, the
(2) doesn't apply, but your archives don't have symbol-tables!)

Much better is to write a command that handles all the changed archive
members in one go:

staticlibrary.a: yetanothercfile.o yacf.o
$(AR) $(ARFLAGS) $@ $?


Philip Guenther


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: automatic linking links too many files

[Philip Guenther]

On Mon, May 25, 2009 at 5:56 AM, Federico Poloni  wrote:
...
> Thanks for the advice. I was not reporting this behavior as erroneous, but
> warning that it differs significantly from the documentation ("Each kind of
> file automatically made into `.o' object files will be
> automatically linked").

Yes, the behavior doesn't match the docs.  I guess the question now is
which should be changed.  The current behavior is  better than what is
documented for at least two cases---archive files and linker
scripts---though the latter is quite obscure.  Fixing the docs to say
that the default rule will treat all prerequisites of the executable
as linker inputs seems better to me.


> In fact, there is this neat workaround:
> -Makefile contents
> $(phony foo):   textfile
> executable: $(phony foo)
> -
> but that was not my point.

Umm, what do you think the above actually does?  There's no built-in
function $(phony), so all you've done is removed 'textfile' from
'executable's prerequisite list.  If you change textfile, executable
will *not* be rebuilt!


> Additional remark:
> An executable depending from a text file may actually be needed in real
> life: e.g. in order to use the Gtk+ component GtkBuilder, the executable
> must read a `foo.ui' xml file which should be built from a `foo.glade' file.

Can you briefly enumerate the actual commands that need to be invoked
in such a setup, indicating what files are the input and output files
in each step (if it's not obvious)?

I ask, because I suspect you're mixing *build-time* dependencies and
*run-time* dependencies.  In a makefile, the prerequisites for a
target, executable or otherwise, should only be those needed at
build-time.  If "foo.ui" is read at runtime by the executable itself,
then the foo.ui is *NOT* a prerequisite of the executable.


Philip Guenther


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make