On Fri, 2020-03-06 at 09:38 +0530, Dr Priyanka Jain wrote:
> -- Build files have been written to: /home/NFS/37_hg/freebayes/build
> /usr/bin/gmake: unrecognized option '--jobserver-auth=3,4'
This means that the version of make being invoked as a sub-make is
different from the version of make you
On Tue, 2020-02-18 at 23:00 +0300, Alexander Khomyak wrote:
> Why "Grouped targets recipe"in the following Makefile
>
> targets = target1 target2
>
> all : $(targets)
>
> $(targets) &:
> @echo "Grouped targets recipe"
> @echo $@ > target1
> @echo $@ > target2
>
> clean :
> rm
On Wed, 2020-02-19 at 17:56 +0100, Jerome Reybert wrote:
> I am facing what to seem to be a bug in Gnu make, since at least make
> 3.82, and still present in 4.2.1.
I'm not sure why your subject mentions SCCS suffix rules, but there is a
built-in rule that knows how to convert from a foo.sh to
On Fri, 2020-01-10 at 11:02 -0500, Dennis Clarke wrote:
> Meanwhile a friend and I are giving 4.2.93 a look on FreeBSD 12.0 and
> a whole slew of packages fail to build.
I can reproduce these failures trying to build dpkg 1.19.7 on GNU/Linux
with the new make. Ugh!!
There seems to be some issue
On Fri, 2020-01-10 at 14:54 -0500, Paul Smith wrote:
> On Fri, 2020-01-10 at 11:02 -0500, Dennis Clarke wrote:
> > Meanwhile a friend and I are giving 4.2.93 a look on FreeBSD 12.0
> > and
> > a whole slew of packages fail to build.
>
> I can reproduce these failures
On Fri, 2020-01-10 at 15:07 -0500, Paul Smith wrote:
> Oh. It's this change:
>
> * WARNING: Backward-incompatibility!
> Contrary to the documentation, suffix rules with prerequisites were being
> treated BOTH as simple targets AND as pattern rules. Behavior now matches
>
ify Oracle Studio c99
Port functions/shell test to Solaris 10
Paul Smith (172):
* Update to pre-release version 4.2.90.
* README.W32.template: Update the build documentation.
Resolve issues discovered by static code analysis.
* maintMakefile: Update default GPG ID fo
On Mon, 2020-01-20 at 18:03 +, Nan . wrote:
> I built latest GNU Make 4.3 and it failed. I use same way/compiler to
> build 4.2.1, it works. I think this might be regression issue.
>
> my configure is
> /home/build/src/make-4.3/configure --prefix=/home/build/native --with-
>
On Mon, 2020-01-20 at 13:58 -0500, Paul Smith wrote:
> > Makefile:8: /home/pete/esp/esp-idf:/home/esp/esp-idf/make/project.mk:
> > No such file or directory
>
> This means make is trying to include the file named, literally,
> /make/project.mk and that file (not surprisi
On Mon, 2020-01-20 at 20:15 +0100, Antonio Diaz Diaz wrote:
> I have built make 4.3 on a x86_64 with Slackware 13.37 in it. The
> compilation went well and the resulting 'make' builds all my projects
> flawlessly, but 2 tests failed:
>
> functions/wildcard ..
Please always CC the mailing list instead of email me directly (or just
reply only to the list). That way others can help even if I'm unavailable.
On Mon, 2020-01-20 at 14:44 -0500, Pete Edwards wrote:
> Dear paul, Thank you
> You are right, I tried to print the IDF_PATH variable contents using
On Mon, 2020-01-20 at 13:09 -0500, Pete Edwards wrote:
> The reference to RCS and SCCS file types on page
> https://www.gnu.org/software/make/manual/html_node/Remaking-Makefiles.html#Remaking-Makefiles
>
> What is an RCS File type? Google references 3D scene data type...I don't
> think that's
In general it's helpful if you use plain text emails, and/or format your
email carefully especially with makefiles as things like indentation are
crucial to see correctly.
Also it's important to ask clear questions, one at a time, and give a very
clear description of your environment etc.
As a
On Mon, 2020-01-20 at 16:32 -0500, Paul Smith wrote:
> > ...$ make Makefile
I also wanted to say, this is wrong as written here... you don't want to
give Makefile as a target to be built.
You should just run "make" with no arguments. Make will read a file named
"Makefi
On Mon, 2020-01-20 at 21:37 +, Nan . wrote:
> the actual command line is
>
> make[1]: Entering directory '/home/build/obj/n-make'
> depbase=`echo src/arscan.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\
> mingw64-gcc -DHAVE_CONFIG_H -Isrc -I/home/build/src/make-4.3/src -Ilib
>
On Fri, 2020-01-10 at 11:02 -0500, Dennis Clarke wrote:
> For some reason you say GNU make needs to read in the entire users
> environment? Really? OKay ... *shrug* ...
Sure; remember this:
https://www.gnu.org/software/make/manual/make.html#Environment
> Variables in make can come from the
GNU make is a tool which controls the generation of executables and
other non-source files of a program from the program's source files.
You can learn more at: https://www.gnu.org/software/make/
On Fri, 2019-08-09 at 17:52 +0200, Christof Warlich wrote:
> attached is the comprehensive (and significantly reworked) patch that
> implements the feature of a new internal variable
Hi Christof; .EXTRA_PREREQS is provided in 4.2.93 please test in your
environment.
Note that I did rework some
On Tue, 2019-10-08 at 19:00 +, Martin Dorey wrote:
> Sorry to reanimate this but I think I've run into a regression in 4.2.92
> over 4.2.1 that's probably related to this old email thread. Bug or
> email, bug or email... email:
>
> martind@swiftboat:~/playpen/make-2019-10-08$ cat > Makefile
On Wed, 2019-10-09 at 06:00 -0400, Jeffrey Walton wrote:
> make: *** No rule to make target 'libcrypto.a', needed by
> 'test2.exe'. Stop.
>
> I have a simple makefile:
>
> $ cat Makefile
> all: test.exe test2.exe
>
> LIBCRYPTO = -l:libcrypto.a
>
> test.exe:
> $(CXX) $(CXXFLAGS) -g2
On Mon, 2019-10-14 at 22:21 -0400, Dmitry Goncharov via Bug reports and
discussion for GNU make wrote:
> This patch adds a new test features/exec.
I added this test with a few adjustments.
On Fri, 2020-01-03 at 22:51 +, Martin Dorey wrote:
> thanks to some new for loop initial declarations in file.c and rule.c,
> which weren't legal in -std=gnu90, the compiler's default dialect.
Hrm. I had thought that was legal in C90 but I guess I was wrong :(.
On Fri, 2020-01-03 at 20:42 +0100, Christof Warlich wrote:
> By the way, I stumbled into a minor issue entirely unrelated to the
> feature above that you may want to fix: The gnulib git repository
> referenced in bootstrap seems to have changed its location, so you may
> want it to change it
On Fri, 2020-01-03 at 22:21 -0500, Dmitry Goncharov via Bug reports and
discussion for GNU make wrote:
> This patch replaced a c99 piece of code with c90 code.
> This c99 piece of code does not compile with the default ./configure &&
> make.
> Also, -std=c99 removes __attribute__.
I already made
On Thu, 2019-12-26 at 21:24 +0100, Jouke Witteveen wrote:
> > Your proposal has the potential to create variables that would have
> > scope local to a single invocation of a user-defined function, but it
> > wouldn't provide scoping to Make-proper. For that reason alone, I
> > would
On Fri, 2020-01-03 at 23:30 -0500, Paul Smith wrote:
> On Fri, 2020-01-03 at 22:21 -0500, Dmitry Goncharov via Bug reports and
> discussion for GNU make wrote:
> > This patch replaced a c99 piece of code with c90 code.
> > This c99 piece of code does not compile with the d
On Sat, 2020-01-04 at 20:36 -0500, Dmitry Goncharov wrote:
> On Sat, Jan 4, 2020 at 3:23 PM Paul Smith wrote:
> > Thanks, I did something similar to this but not quite the same.
> Have you pushed?
I have now.
On Sat, 2020-01-04 at 10:16 +0100, Christof Warlich wrote:
> The original doesen't work from my system (Debian Buster) at least:
>
> > $ ./bootstrap
> > ./bootstrap: Bootstrapping from checked-out make sources...
> > ./bootstrap: getting gnulib files...
> > Cloning into 'gnulib'...
> > fatal:
On Fri, 2020-01-03 at 22:18 -0500, Dmitry Goncharov via Bug reports and
discussion for GNU make wrote:
> This patch replaces __attribute__ with gmake_attribute to retain the
> current behavior of getting __attribute__ removed from gmake's internal
> function declartions and keep glibc declarations
On Sun, 2020-01-05 at 12:12 +0100, Christof Warlich wrote:
> Thus, everything looks perfectly fine so far. But the following still
> fails:
>
> > $ git ls-remote git://git.sv.gnu.org/git/gnulib
> > fatal: remote error: access denied or repository not exported:
> > /git/gnulib
That is not the
On Fri, 2020-01-03 at 02:42 -0500, Paul Smith wrote:
> A new release candidate for GNU make 4.3 is available now for download:
>
> 6b252188079b36d13e96d5527f8ca033 make-4.2.93.tar.lz
> 929d4d3a216c02d0d86eb379356f4d1c make-4.2.93.tar.gz
>
> You can obtain a
I have a deeper set of followup changes I am working on for a post-4.3
release that rewrite the signal handling in GNU make, so that we do not do
any work in signal handlers other than setting flags. Today, far too much
is done in signal handlers resulting in a number of bugs about hangs etc.
On Fri, 2020-01-03 at 22:19 -0500, Dmitry Goncharov via Bug reports and
discussion for GNU make wrote:
> This patch enhances error reporting from the test suite.
Thanks I applied this.
On Mon, 2020-01-06 at 05:33 -0500, Dennis Clarke wrote:
> The only nit, and it is a little nit, is the strange use of a three
> parameter main() in src/main.c line 1054 and this is a "warning". Well
> strictly speaking, pun intended, that isn't a terrible sin but it isn't
> correct either. Sure,
On Sun, 2020-04-05 at 16:19 +0200, Bruno Haible wrote:
> Hi Paul,
>
> > > Building GNU make 4.3 on Ubuntu 16.04, produces one failing test:
> >
> > This is because the glob() function in the older GNU libc has a bug
> > related to handling symlinks correctly.
>
> Gnulib provides a workaround
On Sun, 2020-04-05 at 15:33 +0200, Bruno Haible wrote:
> Building GNU make 4.3 on Ubuntu 16.04, produces one failing test:
This is because the glob() function in the older GNU libc has a bug
related to handling symlinks correctly.
On Wed, 2020-04-01 at 14:14 +0200, Andreas Schwab wrote:
> On Mär 31 2020, Paul D. Smith wrote:
>
> > In GNU make 4.3, for performance reasons we choose to use
> > posix_spawn() if it's available on the system. posix_spawn()
> > doesn't do any path search, so we do it ourselves and we don't have
On Fri, 2020-03-20 at 20:46 +0100, Jouke Witteveen wrote:
> On Thu, Dec 26, 2019 at 2:03 PM Jouke Witteveen <
> j.wittev...@gmail.com> wrote:
> > I would like make to have scoped variables. Here, I will propose an
> > implementation of them. This implementation is currently without
> > tests and
This missing INSTALL file has been reported before. It's surely a
poser because I haven't touched that package building stuff in a while.
I thought automake just handled it. Clearly something changed :)
On Wed, 2020-04-29 at 17:32 -0400, Dennis Clarke wrote:
> Sort of causes one to wonder
On Mon, 2020-05-11 at 14:01 -0500, Pete Dietl wrote:
> What do you all think about me attempting to implementing tail call
> elimination for recursive make functions? This combined with the
> proposed (let) construct would be rather powerful.
If it's straightforward it doesn't bother me. I'd
On Wed, 2020-05-06 at 21:06 +, Loch Brandon wrote:
> Hello,
> I am having the following issue while trying to run make.exe
Please cut and paste text into emails rather than insert screenshots...
we can't quote, search, etc. a screenshot.
> I am using version 3.78.1.
I don't know if you're
On Mon, 2020-05-18 at 21:05 +0200, Jouke Witteveen wrote:
> Otherwise, POSIX prescribes an expr command, so with:
> expr = $(shell expr '$1')
> you can already do $(call expr,2 * 3 + 5).
Please remember not every user of GNU make has access to a POSIX
environment.
I'm not suggesting we
On Mon, 2020-05-18 at 16:01 -0500, Pete Dietl wrote:
> I concur that string handling and comparison should be considered in
> a separate discussion.
>
> So let’s consider just integer comparison and arithmetic here?
The usual method is someone makes a concrete proposal (say, something
on the
On Mon, 2020-05-18 at 20:04 +, Tim Murphy wrote:
> Re comparing strings: we already have ifeq and what I have often
> wanted is to have a function equivalent so I can use it in
> expressions. As bad as ifeq may be from the point of view of locale
> this need be no better to be an improvement
On Mon, 2020-05-18 at 21:05 +0200, Jouke Witteveen wrote:
> On Mon, May 18, 2020 at 8:50 PM Paul Smith wrote:
> >
> > On Mon, 2020-05-11 at 16:32 -0500, Pete Dietl wrote:
> > > I would like to know your thoughts about adding something like
> > > $(expr
> &
On Mon, 2020-05-11 at 16:32 -0500, Pete Dietl wrote:
> I would like to know your thoughts about adding something like $(expr
> ) to evaluate integer expressions and comparisons.
I have no problem with some basic math facilities. We already have
functions like $(word ...), $(words ...), and
On Mon, 2020-05-18 at 11:54 -0500, Pete Dietl wrote:
> Any suggestions?
>
> On Wed, May 13, 2020 at 4:05 PM Pete Dietl
> wrote:
> > I am new to using mailing lists in general and I want to use it
> > properly. Is there is a document somewhere that explains the
> > conventions of using it.
There
On Mon, 2020-05-18 at 19:16 -0800, Britton Kerin wrote:
> # I'm hoping
> # for a little more feedback from paul declaring that the parser is indeed
> # sequential and .SHELLSTATUS is indeed per-process, so that this is ok.
GNU make is not multithreaded and all invocations of $(shell ...)
On Thu, 2020-03-19 at 11:16 -0400, Rocky Bernstein wrote:
> In another list I see that GNU has been accepted for Summer of Code
> and is looking for projects.
>
> [If this is not appropriate here, let me know. I couldn't find a
> general make developers list.]
>
> My suggesion regarding GNU
On Thu, 2020-05-07 at 18:41 +, Loch Brandon wrote:
> dirs:
> @$(ECHO)
> @$(ECHO) Verifying and building application directory structure...
> @if not exist $(OUTPUTDIR) $(MKDIR) $(OUTPUTDIR)
> @if not exist $(OUTPUTDIR)\$(notdir
On Wed, 2020-05-20 at 10:34 -0500, Pete Dietl wrote:
> I really like the idea of using GMP to do the math.
No, I'm not willing to make that requirement.
If anyone can provide any use case where >64bit math is needed in a
makefile I'll be interested to hear about it.
But, my position is that if
On Wed, 2020-05-20 at 11:13 -0500, Pete Dietl wrote:
> > - major added dependency (Make needs to be widely portable, and it
> > is often part of a boot-strapping procedure. The core
> > functionality needs to be trim. Heavy lifting needs to be
> > separable.)
>
> The shared library for libgmp
On Wed, 2020-05-20 at 17:17 +, Tim Murphy wrote:
> So if guile is a good language which does math in postfix notation
> (+ 1 1)
You mean prefix notation :)
I do have fond memories of postfix notation from my HP calculator but
it wouldn't work for GNU make.
> then I don't see why make can't
On Wed, 2020-05-20 at 11:48 -0500, Pete Dietl wrote:
> Another option would be to introduce some new syntax like $(()),
> but that might break existing Makefiles and would probably be more
> work, though it looks cleaner IMO.
No, I don't agree with that. Trying to change the base make parser
On Tue, 2020-05-19 at 15:21 +0100, Tim Murphy wrote:
> A question would be do we want to use GMP or are 64 bit ints enough?
> I'm inclined to say ints are ok of they are wide.
Straight 64bit integer arithmetic is fine IMO. I'm definitely not
interested in adding another library dependency.
>
On Mon, 2020-05-18 at 21:40 -0400, Daniel Herring wrote:
> This decision causes a difficult and error-prone ambiguity when the
> return value is really true and empty. For example, the operation
> succeeded and the result was "", versus the operation failed and thus
> returned "". So Scheme
On Wed, 2020-05-20 at 19:56 -0500, Pete Dietl wrote:
> Paul when you get a chance, could you let me know what you think
> about using many prefix functions?
I'm not sure. I may need to see the proposal to get a feel for what it
really means.
Of course we can still do prefix notation with a
On Fri, 2020-05-22 at 23:14 -0500, Pete Dietl wrote:
> So we are back to debating between many functions or (one or two)
> functions. Anyone else care to weigh in?
I understand what Tim is saying but I still prefer to have a single
function. I want to reduce the "namespace leakage" for these
On Fri, 2020-05-01 at 16:05 +0200, Jouke Witteveen wrote:
> A month ago, I got in touch with Paul Smith about some paperwork
> needed for assigning copyright to the FSF. I did not hear back from
> him since and assume he is busy with other things at the moment.
> Since Make is quite ol
On Thu, 2020-05-21 at 11:22 -0500, Kevin R. Bulgrien wrote:
>FILE_SIZES := 5 2 1 4
>TOTAL :- $(math +, $(FILE_SIZES))
>
> 2)
>
> FILE_SIZES := 5 2 1 4
> TOTAL :- $(+ $(FILE_SIZES))
>
> In my mind, TOTAL obviously ends up with the same value, but, 1) is
> more readable in the same
On Thu, 2020-05-21 at 11:46 -0400, Paul Smith wrote:
> In my discussion of the way to handle conditions I even mentioned
> allowing just one operand which would give the identity function.
>
> After sleeping on it, though, I'm not sure if that's the best idea.
> Maybe we s
On Thu, 2020-05-21 at 15:35 +, Tim Murphy wrote:
> There's something to be said for this being able potentially to work
> - not that I'm pushing it mind:
>
> FILE_SIZES:= 5 2 1 4
> TOTAL:=$(+ $(FILE_SIZES)) # TOTAL is 5+2+1+4
>
> Here I'm not objecting to ($math +,$(FILE_SIZES)) or $(op
>
On Sun, 2020-09-13 at 15:08 -0400, Paul Smith wrote:
> ... : .sentinel ;
>
> .sentinel:
>
> @touch $@
Just to be clear, you don't have to use ".sentinel" you can use any
target name, and obviously you must use a different name for each
"g
On Sun, 2020-09-13 at 20:55 +0200, Bruno Haible wrote:
> How can a rule that generates multiple files be formulated so
> that it works with parallel make?
>
> For example, a rule that invokes bison, or a rule that invokes
> a different Makefile. For simplicity, here, use a rule that
> creates
On Mon, 2020-10-05 at 15:14 -0400, Jeffrey Walton wrote:
> > $ CFLAGS=ok make
>
> I think you need to export CFLAGS. Or that is where I would look.
> CFLAGS is set in the first shell, but it is not inherited in child
> shells.
It should be: the value is set in the environment when make starts
On Fri, 2020-10-09 at 15:03 +, Byrnes, Robert wrote:
> Why is the embedded whitespace removed in the first (FOO) case? It
> seems related to the semicolon shell metacharacter ...
My suspicion is that it's a difference between your /bin/echo command
and your shell's builtin echo command.
In
On Fri, 2020-10-09 at 18:00 +, Byrnes, Robert wrote:
> [pid 144497] execve("/bin/sh", ["/bin/sh", "-c", "/bin/echo blartzblurfl ;
> "], 0x7ffd98ee6bc0 /* 72 vars */) = 0
Hm, interesting. I guess it's possible we are stripping out newlines
before invoking the shell. I don't remember that
On Wed, 2020-10-14 at 13:18 +0100, Jonathan Wakely wrote:
> Shouldn't special targets like .PHONY be listed in the index at
>
> https://www.gnu.org/savannah-checkouts/gnu/make/manual/html_node/Concept-Index.html#Concept-Index_cp_symbol-9
>
> ?
> Similarly for .SUFFIXES and others.
For some
On Wed, 2020-05-27 at 15:44 +0800, Truong Term wrote:
> I downloaded this one
> http://gnuwin32.sourceforge.net/packages/make.htm
That site is not part of the GNU project or the FSF.
If you want help using that version please refer to their support
lists:
http://gnuwin32.sourceforge.net/
On Sun, 2020-05-24 at 14:09 -0500, Pete Dietl wrote:
> > I think, as I mentioned before, that someone (I guess that's you
> > :)) should write up an actual proposal (maybe, for example, the
> > start of a new manual section) that can be examined and commented
> > on.
>
> Challenge accepted! What
On Sun, 2020-05-24 at 21:10 -0500, Pete Dietl wrote:
> Does anyone have advice on how to build the web documentation?
> I tried running `make gendocs` but I get errors like:
>
> cvs -d :pserver:anonym...@cvs.sv.gnu.org:/web/www co 'www/server/standards'
>
> cvs [checkout aborted]: connect to
On Mon, 2020-05-25 at 10:10 +, Edward Welbourne wrote:
> > > Mult-base support: should we support only base 10 integer
> > > constants in
> > > expressions, or also hex/octal constants?
> > I vote for decimal, hex, and binary.
> > Octal if you really want it.
>
> A case for octal and bitwise
On Mon, 2020-05-25 at 12:07 -0400, Sam Kendall wrote:
> I'd like to raise some questions that I think any proposal ought to
> answer. I'll assume a straw man proposal: there's one function, and
> it takes one of the following forms:
>
> $(math OPERATOR,VALUE1,VALUE2)
> $(math OPERATOR,VALUE1)
I
On Mon, 2020-05-25 at 13:28 -0500, Pete Dietl wrote:
> Question about 64-bit, what happens when compiling make for a 32-bit
> system? I don’t think c90 has `stdint.h`... maybe there’s something
> in gnulib. Anyway, would we want to support 64 bit integers even on
> 32-bit platforms?
32bit
On Sat, 2020-05-23 at 15:43 -0500, Pete Dietl wrote:
> > I understand what Tim is saying but I still prefer to have a single
> > function. I want to reduce the "namespace leakage" for these
> > capabilities. If we decide to add more operations to this in the
> > future I don't want it colliding
On Wed, 2020-05-27 at 13:47 -0500, Pete Dietl wrote:
> Technically, the C standard allows for machines which don't use 2's
> complement. So should we consider our LONG_MIN to be -2^63 + 1?
>
> Also, signed arithmetic overflow is undefined behavior, so should we
> also indicate that we have
On Thu, 2020-05-28 at 22:07 +0200, Jouke Witteveen wrote:
> Here is a thought: The current support for numeric variables is
> limited to unsigned numbers. We could choose to stick with that!
I'm not sure how this would work... it works today because we have no
subtraction and all numbers make can
On Thu, 2020-05-28 at 17:07 -0500, Pete Dietl wrote:
> Thoughts?
I'm fine with these choices, insofar as I can tell. I reserve the
right to change my mind after seeing the full scope of the proposal :).
On Fri, 2020-05-29 at 01:10 +, ky...@disroot.org wrote:
> as of version 4.3, with the inclusion of gnulib, make now appears to
> require c99 support in order to be compiled correctly.
>
> since this is the case, the configure script should check if flags
> are necessary to enable c99 support,
On Mon, 2020-05-25 at 15:44 -0500, Pete Dietl wrote:
> As for converting between bases, that could always be a separate
> function like `$(convert-base number,radix)` where radix is one of:
> 2, 8, 10, or 16
I agree it should be a separate function.
Perhaps it would be better to consider a more
On Thu, 2020-05-21 at 00:37 -0500, Kevin R. Bulgrien wrote:
> > Of course we can still do prefix notation with a single function we
> > just have to choose a name for it and it's a little less slick; for
> > example something like:
> >
> >$(op + 5 7 $(op * 3 2) 9)
> >
> > or whatever so the
On Tue, 2020-06-02 at 08:48 -0400, Sam Kendall wrote:
> > I suggest that
> > a) $HOME/.local/include is effectively added to the
> >include_directories ...
>
> If two users build the same source tree, they will effectively be
> building variants of it, each extending it with her own
>
On Fri, 2020-09-18 at 10:59 -0500, Pete Dietl wrote:
> Why are there so many form feeds in the source?
That was the style that Roland used when the code was written: form
feeds were used inside a source file to separate major functions.
I guess it hails from a time when it wasn't that unusual to
On Fri, 2020-10-09 at 16:36 +0200, Jouke Witteveen wrote:
> This was sent before at the end of last year. Meanwhile, the
> copyright of my contributions is assigned to the FSF, so I picked
> this up again and added some documentation (next patch).
Sorry for the delay. I have been super-busy
On Thu, 2020-07-02 at 17:16 +0200, Jan Beulich wrote:
> > export wom
> > introduces the variable to the env and set origin to environment.
>
> Not according to my observations.
The difference is whether the variable already exists in the
environment or not.
For this makefile:
export FOO
On Tue, 2020-06-30 at 16:04 +0800, mkckr0 wrote:
> I am a newbee programmer from China. Recently I am trying to read the
> GNU Make Manual. But I cannot find the C souce code. In Chapter 2,
> there is a text editor program as a example including 8 source file
> and 3 header file. I cannot find
On Tue, 2020-06-30 at 07:17 +, Preethi Selvaraju wrote:
> Kindly ignore if it has nothing to do with gmake.
This is not a GNU make issue.
On Thu, 2020-07-09 at 16:00 +, Edward Welbourne wrote:
> By the sounds of it, you have four files that are all created by a
> single rule, which isn't a scenario make is good at. So work-arounds
> are tricky:
If you want to use parallel builds you must find a workaround for this
issue, or
On Fri, 2020-07-03 at 11:50 +0200, Jan Beulich wrote:
> > For example if you change the above makefile:
> >export FOO
> >$(info FOO: $(origin FOO))
> >all: ; @env | grep FOO
> > then you run:
> >$ unset FOO; make
> >FOO: file
> >FOO=
> >make: 'all' is up to date.
> >
On Mon, 2020-06-29 at 08:56 +, Preethi Selvaraju wrote:
> Error:
> /usr/bin/gmake: invalid option -- 8
> /usr/bin/gmake: invalid option -- /
> /usr/bin/gmake: invalid option -- a
> /usr/bin/gmake: invalid option -- /
> /usr/bin/gmake: invalid option -- c
This are just the error messages.
On Mon, 2020-06-29 at 15:00 +, Martin Dorey wrote:
> I’m pleasantly surprised, as it looked like there were a bunch of
> later issues possibly not fixed in jdk8u, including
> https://savannah.gnu.org/bugs/index.php?57676, which is still waiting
> for Paul to visibly take a stance on, after
On Mon, 2020-06-29 at 11:41 -0400, Dmitry Goncharov wrote:
> On Mon, Jun 29, 2020 at 11:20 AM Paul Smith wrote:
>
> > Unfortunately, Dmitry has been so active with help that I'm not
> > able to accept any more of his patches until/unless some sort of
> > copyrigh
On Tue, 2020-07-28 at 08:07 +0300, Ivan Kozlov wrote:
> Doubling the backslash suppresses special newline handling in GNU
> make. I don’t see anything in the standard that allows this. It
> defines an escaped newline as one preceded by a backslash and doesn’t
> say anything about backslashes being
Hi Martin; please always reply to the mailing list: this allows
everyone else to help. Also, we try to use "inline replies" on the
mailing lists, rather than "top-posting" replies.
On Fri, 2021-01-08 at 08:59 +, Stühler, Martin wrote:
> Dear Paul,
>
> Thanks for your fast response. I saw,
On Tue, 2021-01-12 at 10:20 -0500, Dmitry Goncharov wrote:
> In bash (in recipe lines) you can replace cp with
> echo "$(dst
If you use this you must set the make variable SHELL to /bin/bash.
Also, if running "echo hi" is slow then I assume this would also be
slow.
> in make you can replace cp
On Thu, 2020-12-03 at 15:04 +0300, Dmitry wrote:
> > > It'll be very good to have some examples with explanations in the
> > > docs.
> > Maybe so. Concrete suggestions are easy to discuss, like:
>
> I think this example would saved me a lot of time.
>
> make -f mkfile
>
> content of mkfile:
>
On Sun, 2020-10-04 at 09:11 +0200, Danny Milosavljevic wrote:
> I just got a build failure in lz4. I've isolated it and made a
> minimal test case, see below.
>
> This is on GNU Guix on a x86_64 machine.
>
> The reason is that apparently one Makefile rule can unwittingly
> change how another
On Sat, 2020-10-10 at 17:50 -0500, Pete Dietl wrote:
> Also, I ran ‘’make html”, but it doesn’t look like it does on he
> website. Does anyone know how I can build the docs to look like the
> website locally?
It's not so easy to do unfortunately.
It requires a bunch of prerequisites, that are
On Fri, 2020-10-23 at 09:14 -0400, Paul Smith wrote:
> On Fri, 2020-10-09 at 16:36 +0200, Jouke Witteveen wrote:
>
> > This was sent before at the end of last year. Meanwhile, the
> > copyright of my contributions is assigned to the FSF, so I picked
> > this up again and
On Wed, 2020-12-09 at 12:42 +, DUDZIAK Krzysztof wrote:
> Why is a variable of null-string value used to protect leading space?
Stripping of leading space in a variable assignment happens while the
makefile is being parsed and BEFORE any part of the line is expanded.
So, any non-space
801 - 900 of 1346 matches
Mail list logo
