On Tue, 2019-09-10 at 20:36 -0400, Dmitry Goncharov via Bug reports and
discussion for GNU make wrote:
> echo -n is not portable.
> Certain implementations of echo everything, including -n.
> This makes test 1 of grouped_targets fail.
This was already fixed by a patch from Paul Eggert on Aug 27.
T
On Sat, 2019-09-14 at 16:19 -0400, Dmitry Goncharov wrote:
> On Sat, Sep 14, 2019 at 10:22 AM Paul Smith wrote:
> > and, I've checked with a makefile invoked by the test suite and
> > this setting is in effect, even if the shell invoking
> > run_make_tests.pl has a di
On Sat, 2019-09-14 at 18:27 -0400, Paul Smith wrote:
Can you apply the attached patch
Oops ignore/delete the diff of m4/.gitignore :(
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
On Fri, 2019-09-13 at 21:40 -0400, Dmitry Goncharov via Bug reports and
discussion for GNU make wrote:
> -The third serious problem is that it's not relocatable: the only
> -way it works when you build out of the source tree is to create
> -symlinks, which doesn't work on every system and is bogus
On Sat, 2019-09-14 at 22:31 -0400, Dmitry Goncharov wrote:
> On Sat, Sep 14, 2019 at 6:27 PM Paul Smith wrote:
> > Your setting of LANG or LC_MESSAGES
> > cannot make any difference to the test suite because the test suite
> > does not pass those values to the make that
On Sun, 2019-09-15 at 09:44 -0400, Dmitry Goncharov wrote:
> > So, the question is why does your Perl still provide language-specific
> > messages?
> has_POSIX is uninitialized at the time test_driver.pl reads it, because
> (atleast in my testing) the code which initializes has_POSIX hasn't run yet
On Sun, 2019-09-15 at 13:01 -0400, Dmitry Goncharov wrote:
> perl will tell you that it does not know what POSIX::LC_MESSAGES is.
>
> This patch initializes has_posix right here in test_driver.pl and pulls in
> locale_h.
> This patch sets LC_ALL because we saw that LANG has an affect.
> This patc
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 Thu, 2019-09-12 at 09:33 +0200, Andreas Schwab wrote:
> On Sep 11 2019, Dmitry Goncharov wrote:
> > On Wed, Sep 11, 2019 at 2:51 AM Andreas Schwab wrote:
> > > > The new hashing mechanism hashes differently on big vs little
> > > > endian.
> > >
> > > Should this be considered as a bug?
> >
On Fri, 2019-09-13 at 21:42 -0400, Dmitry Goncharov via Bug reports and
discussion for GNU make wrote:
> aix implementation of realpath returns a path with a trailing slash
> given a path with 2 or more trailing slashes. This makes realpath test
> fail.
This one didn't make it into the current RC
On Mon, 2019-09-16 at 11:04 -0700, Paul Eggert wrote:
> syntax error at ./run_make_tests.pl line 473, near "or continue"
Ugh. Can you change this line:
-x $prog or continue;
to this:
-x $prog or next;
? That's a dumb syntax error. Too many different languages.
However, I don't
On Mon, 2019-09-16 at 12:23 -0700, Paul Eggert wrote:
> > Can you run this and tell me what it prints:
> >
> >perl -we 'use File::Spec::Functions qw(splitpath); my @o =
> splitpath("../make"); print "@o\n"'
>
> A single line " ../make".
Ugh, that's wrong. It should be " ../ make" (note the
On Mon, 2019-09-16 at 15:49 -0400, Paul Smith wrote:
> Ugh, that's wrong. It should be " ../ make" (note the space before
> "make"). File::Spec is not correctly splitting the directory from the
> file, apparently. Bogus!! Can you try this one:
>
>
On Sat, 2019-09-21 at 12:09 -0700, Paul Eggert wrote:
> On 9/21/19 10:55 AM, Paul Smith wrote:
> > perl -we 'use File::Spec; my @o = File::Spec->splitpath("../make");
> > print "@o\n"'
>
> It outputs a single line containing " ../ make&q
On Wed, 2019-09-18 at 21:38 -0400, Dmitry Goncharov via Bug reports and
discussion for GNU make wrote:
> The test suite fails to run valgrind with an error message like the following.
I pushed a different fix for this issue. Thanks for noticing!
___
B
On Sat, 2019-09-21 at 21:21 -0400, Dmitry Goncharov wrote:
> On Sat, Sep 21, 2019 at 04:54:59PM -0400, Paul Smith wrote:
> > I pushed a different fix for this issue. Thanks for noticing!
> Thank you.
> Do you intentionally avoid $! in the "Cannot execute" error message?
On Wed, 2019-09-11 at 08:44 +0200, Andreas Schwab wrote:
> On Sep 10 2019, Paul Smith wrote:
>
> > That didn't work, however, because particularly in recursive make
> > the makefile name is likely not qualified with a path, but the
> > current working directory whe
On Thu, 2019-09-05 at 16:49 -0400, Peter Marshall wrote:
> 5.3 Recipe Execution
>
> foo : bar/lose
> cd $(@D) && gobble $(@F) > ../$@
Indeed this is incorrect. I've updated the manual.
Thanks for mentioning this!
___
Bug-make mailing list
Bu
On Tue, 2019-09-10 at 13:33 +0200, Florian Weimer wrote:
> * configure.ac (HAVE_GETTIMEOFDAY): Avoid reference to undeclared
> exit function.
I applied this to Git. Thanks for contributing to GNU make!
___
Bug-make mailing list
Bug-make@gnu.org
https:
On Mon, 2019-09-16 at 15:07 +0200, Andreas Schwab wrote:
> > I didn't apply this change because I'm not exactly sure where I want to
> > go with this yet. I'm not excited about tweaking the test suite based
> > on the endianness of the underlying system but it seems silly to reduce
> > the perform
On Tue, 2019-09-17 at 09:40 +0200, Dagobert Michelsen wrote:
> cd tests && perl ./run_make_tests.pl -srcdir
> /home/dam/mgar/pkg/gmake/trunk/work/solaris10-i386/build-isa-
> pentium_pro-guile-yes/make-4.2.91 -make ../make
> syntax error at ./run_make_tests.pl line 473, near "or continue"
> Executio
On Fri, 2019-09-13 at 21:42 -0400, Dmitry Goncharov via Bug reports and
discussion for GNU make wrote:
> aix implementation of realpath returns a path with a trailing slash
> given a path with 2 or more trailing slashes. This makes realpath test
> fail.
I changed the realpath function to remove tr
On Mon, 2019-09-23 at 07:48 +0200, Dagobert Michelsen wrote:
> Hi Paul,
>
> Am 22.09.2019 um 23:42 schrieb Paul Smith :
> > On Tue, 2019-09-17 at 09:40 +0200, Dagobert Michelsen wrote:
> > > Additionally, I have two failed tests on Solaris 10 borg Sparc
> > > x8
On Tue, 2019-09-03 at 04:14 +, Dmitry Goncharov via Bug reports and
discussion for GNU make wrote:
> sum_up_to_nul reads 4 bytes starting from the passed string 'p'.
> 'p' can have fewer than 4 bytes. Usually there more allocated space
> after 'p', which prevents this reading from manifesting i
On Wed, 2019-09-25 at 08:29 +, Edward Welbourne wrote:
> > With "normal" systems it's safe to read (only) memory beyond the end
> > of an array, at least up to the next word size, which is what this
> > code does.
>
> If you want to be able to rely on this "normal" behaviour, for the sake
> of
On Fri, 2019-10-04 at 15:50 -0700, Deepasree Mulabagal via Bug-make wrote:
> I am Unable to setup the path for "vtslab" under working directory
> for changing the SPL Date on GSI. I filed a bug but unable to assign
> it to bug-make@gnu.org, could you please take a look at the below
> issue.
Sorr
On Tue, 2019-09-03 at 04:14 +, Dmitry Goncharov via Bug reports and
discussion for GNU make wrote:
> sum_up_to_nul reads 4 bytes starting from the passed string 'p'.
> 'p' can have fewer than 4 bytes. Usually there more allocated space
> after 'p', which prevents this reading from manifesting i
On Sat, 2019-08-31 at 13:59 +0300, Eli Zaretskii wrote:
> The failures where all eyeballed, and the conclusion is that they are
> due to non-portable assumptions that are too much work to fix. The
> worst offenders are:
>
> . the assumption that $$FOO gets expanded by the shell into the
> v
On Mon, 2019-10-07 at 11:26 -0400, Dmitry Goncharov wrote:
> On Mon, Oct 7, 2019 at 9:03 AM anonymous
> wrote:
> > With the following Makefile, make-4.2.91 segfaults on my Solaris
> > 10:
>
> ...
> > include /dev/null
> > dummy: subdir/*.c
> > include /dev/null
>
> This reproduces for me. This i
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 Tue, 2019-10-08 at 15:28 -0700, Paul Eggert wrote:
> * tests/scripts/functions/shell: Port exit-status calculation
> to Solaris 10 with Perl 5.8.4.
Thanks Paul. I had hoped that my attempts to get Perl to tell me what
the expected return codes are on the local system would have been
sufficient
On Sat, 2019-10-12 at 13:11 +0200, Jouke Witteveen wrote:
> Before, this was only expanded to $(*F) in prerequisites.
Sorry but I need more information than this; I can't understand this
change.
The bug in Savannah, as I understand it, is that directory prefixes
which should be present are missin
On Fri, 2019-11-15 at 15:52 +0200, Eli Zaretskii wrote:
> Ping! Paul, did you have a chance to look at this issue?
Sorry, I'm quite underwater. I hope to be able to do a bit of make work
over the next few weeks: get out a final RC and a release.
For this, I don't really understand the issue :).
On Sat, 2019-11-23 at 12:22 +0100, Jouke Witteveen wrote:
> Is there anything I can do to further review and/or acceptance of this
> patch I sent last month?
I applied your changes although updates were needed.
For the future, please note that (a) changes should contain updates to the
regression
On Wed, 2019-12-18 at 16:02 +0100, Jouke Witteveen wrote:
> Your se_implicit test case got left out of your commit. I guess this
> was unintentional.
I'm not sure what you mean? It's there...?
> Presumably, the test case was based on [SV 54161]. The bug can now be
> closed.
Yes, will do that la
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 sugges
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, 2020-01-03 at 18:41 +0530, nilsocket wrote:
> In last bullet point, word `that` is repeated twice.
Thanks!
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 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 -O0
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 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 thi
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 accord
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 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 s
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 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: unab
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 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 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 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 righ
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.
(and
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, to
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 envir
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
&
racle Studio 12.6
Pacify Oracle Studio 12.6 in init_switches
Remove useless code in eval
Port grouped_targets test to Solaris 10
Pacify Oracle Studio c99
Port functions/shell test to Solaris 10
Paul Smith (172):
* Update to pre-release version 4.2.90.
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-
> sysroot=/home/bui
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 wh
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 no
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 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
"Make
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
> -I/home/build/src/m
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 -r
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 fo
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 i
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 Make
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 do
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 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 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 aga
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 about
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 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 aw
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 $(OBJD
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 have
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-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 $(word
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-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 re-impleme
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 ov
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 same
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 ...)
functions
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 added
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.
> So
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 y
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 do
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
like
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 b
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 singl
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 f
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 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 way
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 w
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
capa
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 w
901 - 1000 of 1499 matches
Mail list logo
