Pete Dietl wrote:
Here I submit to you a patch that adds the following builtin functions
to make: `add` (addition), `sub` (subtraction), `mul`
(multiplication), `div` (division), `mod` (modulus), `max` (maximum),
`min` (minimum), and `abs` (absolute value). The implementation I
provide supports
Since the commit:
https://git.savannah.gnu.org/cgit/make.git/commit/src/variable.c?id=ec348f51d0240ebc64d11c77c461e89c4a8dfed7
src/variable.c doesn't compile:
variable.c(1642): error C2065: 'specificity': undeclared identifier
variable.c(1658): error C2065: 'specificity': undeclared identi
Tim Murphy wrote:
HOW TO GET IT:
===
in the feature/jprint branch on this fork:
https://github.com/tnmurphy/gmake-experimental
Got it and tried to build it. With clang-cl there is
this warning:
jprint.c(483,40): warning: omitting the parameter name in a function
definition is a
Dmitry Goncharov wrote:
There are various techniques.
example 1, define the variable
\:=
This was simple and elegant. Worked w/o any warnings.
Thanks!
Martin Dorey wrote:
This seems to work:
martind@sirius:~/tmp/vanem-2023-04-14$ cat Makefile
g_trace.h: Makefile; $(file > $@,$(trace_h))
\ = \
define trace_h
#define G_TRACE(level, fmt, ...) $\\
do { $\\
if (_g_t
In a makefile I have the need to generate a
multi-line C-macro (for use in Glib):
g_trace.h: Makefile
$(file > $@,$(trace_h))
define trace_h
#define G_TRACE(level, fmt, ...) $\\
do { $\\
if (_g_trace_level() >= level
Dan Jacobson wrote:
(info "(make) Text Functions") says
'$(subst FROM,TO,TEXT)'
Performs a textual replacement on the text TEXT: each occurrence of
FROM is replaced by TO. The result is substituted for the function
call. For example,
$(subst ee,EE,feet on the str
Paul Smith wrote:
If you use "-d" you'll get the info you want:
No implicit rule found for 'default'.
Considering target file 'lib'.
Finished prerequisites of target file 'lib'.
No need to remake target 'lib'; using VPATH name 'apps/lib'.
Finished prerequisites of target file
Hello list.
I sometimes have issues when a 'VPATH' doesn't
do what I'd like. E.g. in this 'vpath-test.mak'
file:
#
# there is a 'apps/lib' directory here:
#
VPATH = apps
GEN_DIRS = ./lib
default all: $(GEN_DIRS)
$(GEN_DIRS):
mkdir --verbose $@
---
So I want to cr
Hello list.
I'm using the very latest GNU-make built on Win-10 by myself.
Except I've disabled the call to 'SetUnhandledExceptionFilter()'.
In one particular Wine Makefile I get a crash in 'hash_free_items()':
gnumake!hash_free_items+0x22
gnumake!hash_free+0x30
gnumake!clear_directory_cont
Edward Welbourne wrote:
Indeed, on Unix, time_t is signed and modern GLibc / Linux functions
using it are perfectly happy with values across the whole range of the
type (which extends to well before the big bang).
Thanks for the detailed explanation. Yes, it's rather confusing
with such timest
Paul Smith wrote:
... facilities that you don't specify (Cygwin? MinGW? WSL?)
I'm using Cygwin as my POSIX toolbox.
But, note that touch writes timestamps in the current timezone by
default. It could be that your timezone (which you also didn't
specify) makes a difference, when you are ta
I have an issue with things like
touch --date="1970-01-01"
(or 'touch -t time') that I sometime use in makefiles.
E.g. in this makefile:
-
all: test-file-1 test-file-2
test-file-1:
echo 'whatever' > $@
touch -t 197001010100 $@ # Jan 1. 1970, 01:
Hello folks.
I have a question regarding parenthesis
in GNU-make macros. Like in:
msg = @echo "$(1)"
ptest_1:
$(call msg, foo (arg1, arg2, arg3))
ptest_2:
$(call msg, foo, arg1, arg2, arg3)
A 'make ptest_1' shows:
foo (arg1, arg2, arg3)
and 'make
Follow-up Comment #2, bug #62575 (project make):
> sh -c 'clang -fansi-escape-codes -fcolor-diagnostics'
Why this when `clang` is giving nice colours w/o any problems
on Windows anyway?
Please do not add this patch without checking that the
`ENABLE_VIRTUAL_TERMINAL_PROCESSING` works. And it doe
Paul Smith wrote:
... else (b) make has to parse this string
and break it up into words that it can use to call exec() without going
through a shell
The crash and wild call-stack seems to be caused
by an overflow to 'sprintf(sh_path, ..)'. But replacing
with 'snprintf()' works w/o any crash:
Hello list.
Some resent (?) change has caused a crash in
'find_and_set_default_shell()' with this minimal
Makefile:
export PATH := $(PATH):node_modules/.bin
SHELL := env "PATH=$(PATH)" /bin/bash
all:
@echo "Hello"
---
Without the 'SHELL ..' line, all is good.
Or even a 'SHELL=/
Paul Smith wrote:
I'm OK with adding some short text about this into the man page. As
David mentions it may be important enough to do that since command
being run by make even when the user gives "-n" could give unexpected
or even unpleasant consequences.
The most unpleasant consequences of u
Paul Smith wrote:
You probably want to escape the non-argument references, so that call
will not run them and instead they will be passed to eval:
define add_c_src
VPATH += $(1)
C_SRC += $$(addprefix $(1)/, $(2))
$$(info Number of 'C_SRC': $$(words $$(C_SRC)))
endef
Hello list!
I have this really large makefile and
discovered the '$(eval..)' function was handy
to use for this. Like:
define add_c_src
VPATH += $(1)
C_SRC += $(addprefix $(1)/, $(2))
$(info Number of 'C_SRC': $(words $(C_SRC)))
endef
$(eval $(call add_c_src, frmts/ceos, ceoso
Dmitry Goncharov wrote:
On Sun, Dec 12, 2021 at 2:15 PM Paul Smith wrote:
Did something happen when it stopped working, like you updated to a
different version of GNU make?
i bet this make is built from the current git.
Correct.
Thanks for your report.
If you need make from git you shoul
Hello list.
Since some time the cool '.SECONDEXPANSION' feature has
stopped working for me. In a Makefile, I have many rules
to link module .DLLs:
mod_airspy_source_OBJ = $(OBJ_DIR)/airspy_source_main.obj
mod_airspyhf_source_OBJ = $(OBJ_DIR)/airspyhf_source_main.obj
mod_bladerf_source_OB
I wrote:
dir.c(528,24): error: use of undeclared identifier 'p'
memcpy (tem, name, p - name + 1);
^
dir.c(532,24): error: use of undeclared identifier 'p'
for (tend = tem + (p - name - 1);
^
I fixed this by:
--- a/src/dir
Hello list.
The Windows port of Gnu-make has some issues:
dep.h(60): error C2059: syntax error: ';'
dep.h(61): error C2059: syntax error: '}'
dep.h(69): error C2059: syntax error: ';'
dep.h(70): error C2365: 'error': redefinition; previous definition was
'function'
MSVC does not handle
Eli Zaretskii wrote:
gnss_libf2c.lib:
cd libf2c ; nmake.exe -nologo -f Makefile.VC all
cp libf2c/vcfc2.lib $@
but Nmake errors with:
Microsoft (R) Program Maintenance Utility Version 14.26.28806.0
Copyright (C) Microsoft Corporation. All rights reserved.
NMAKE : fatal erro
Hello list.
Now I have the need to use an already quite large
Makefile written for Microsoft's 'NMake', from within
GNU-make 4.390. Like:
gnss_libf2c.lib:
cd libf2c ; nmake.exe -nologo -f Makefile.VC all
cp libf2c/vcfc2.lib $@
but Nmake errors with:
Microsoft (R) Program Maintenance Utili
Paul Smith wrote:
What I'm considering is enhancing the EINTRLOOP etc. macros that I have
added across the code to check all system calls for EINTR and restart them,
so that this macro also checks to see if a signal has been received and if
so, calls a handler function. For almost all signals t
Paul Smith wrote:
All the .obj files are missing!?
Oh. $@ is "bin/animation.exe" so $(@F) is "animation.exe" and
$($(@F)_OBJ) would be "animation.exe_OBJ" but that's not the name of
your variable, so it expands to the empty string.
Sorry I didn't catch this problem in your original suggestio
Paul Smith wrote:
Or, you can enable secondary expansion which will allow you to write:
.SECONDEXPANSION:
bin/%.exe: $$($$(@F)_OBJ) $(LIBS)
$(call link_EXE, $@, $^)
Very compact and nice. But trying it, it wont work.
For 'bin/animation.exe', it expands to:
bin/animation.e
Hello list.
I need help with compacting a series of rules like (from a
Qwt makefile):
animation_OBJ = examples/animation/main.obj \
examples/animation/plot.obj
barchart_OBJ = examples/barchart/barchart.obj \
examples/barchart/main.obj \
Paul Smith wrote:
Then there's the question of case-preserving or not. To be case-
preserving, make would have to be doing all string searches and
comparisons using case-insensitive implementations which would be a lot
of code churn. And we would have to care a lot more about
internationalizat
Eli Zaretskii wrote:
I'm not sure Make can distinguish between the two kinds. E.g., the
rules for generating the "phony" target could be given later. Paul
will know for sure.
And anyway, wouldn't it be confusing if case-sensitivity changed
depending on whether a file exists or doesn't?
Than
Hello list.
In a discussion with the LuaList, I got involved with
how GNU-make on Windows handles all targets in a case-
insensitive manner. Like in this 'case-insensitive-win.mak':
-
default: program_name
PROGRAM_NAME Program_Name program_name:
@echo 'Do something for $@.'
-
David Boyce wrote:
> First, I think there’s some missing context as you seem to have an
> unusual environment. You’re mixing Unix (cat, rm) and Windows (link)
> invocations; is it Cygwin, GNUWin32, MKS, ???
Thanks for replying.
I'm on Windows 10 using CygWin32 tools together with MSVC tools. (no
Eli Zaretskii wrote:
> The Windows shell understands || and && between 2 commands. I think
> you already know that, so I'm quite sure I'm missing something here,
> because that's the first thing I'd try.
There is no Windows shell (cmd nor 4nt) involved here. I don't
have any 'SHELL' in the Makef
I have a question regarding a GNU-make macro like this
(which I use to link a MSVC .dll):
define do_link_DLL
link $(LDFLAGS) -dll -out:$(1) -implib:$(2) \
-pdb:$(1:.dll=.pdb) -map:$(1:.dll=.map) $(3) > link.tmp
cat link.tmp >> $(1:.dll=.map)
rm -f $(2:.lib=.exp) link.tmp
e
Some lines in this file seems a bit strange.
Line 755:
if (arr2envblk(envp, &envblk, &envsize_needed) == FALSE) {
pproc->last_err = 0; << !!
pproc->lerrno = E_NO_MEM;
free( command_line );
if (pproc->last_err == ERROR_INVALID_PARAMETER
Eli Zaretskii wrote:
Out of curiosity, which parts of the Make build process produce *.lib and
*.sbr files? (I don't use MSVC.)
'cl -FR' creates .sbr files (Source Browser File). Which IMHO is completely
useless when using .bat-files to build gnumake.
'link' creates a 'gnumake.lib' because o
"Eli Zaretskii" wrote:
Looks good on MS-Windows (I fixed a few minor issues, most of them
specific to the MS-Windows build).
I have only one issue with OpenWatcom. It builds fine except for
a missing 'ftruncate()':
--- Git-Latest/makeint.h 2014-09-21 16:21:17 +
+++ makeint.h 2014-0
The commit
http://git.savannah.gnu.org/cgit/make.git/commit/?id=562344122f3a3327ca4e285f203355857c4a25ff
breaks MSVC v16 build because of the C99 feature of 'declaration after code'.
Can you please apply this diff?
---Git-Latest/loadapi.c 2014-09-21 16:21:17 +
+++ loadapi.c 2014-09-2
"Eli Zaretskii" wrote:
Why is the RC file important? IME, maintaining such Windows specific files is
a nuisance in the long run, as they fall out of sync.
Why? It's can be nice to know which compiler was used to build
gnumake.exe, release/debug and on which date etc. (I build gnumake
with
"Martin Dorey" wrote:
this also removes the newlines.
...
IMHO make 4.x has a too strict definition of white-space.
http://pubs.opengroup.org/onlinepubs/95399/basedefs/xbd_chap07.html sayeth:
"In the POSIX locale, at a minimum, the , , ,
, , and shall be included."
Then the make ma
I'm a happy user of the $(file) function and multiline macros/variables
likes this:
..
define FOO_PACKAGE
exec_prefix=$(FOO_ROOT)
libdir=$${exec_prefix}/lib
includedir=$${exec_prefix}/inc
Version: $(FOO_VERSION)
Libs: $${libdir}/$(FOO_LIB)
endef
write_pkg:
$(file > ./foo.pc, $(strip $(FOO_P
"Paul Smith" wrote:
HOWEVER. I don't know nearly enough about all the variations and
different possibilities on Windows to make sound judgements on the
specific situation, so if Eli is OK with it then I'm OK with it.
If it's the value of 'batch_mode_shell' we speak of, it can easily be
chang
"Eli Zaretskii" wrote:
Wouldn't it be better to display the error only if CreateProcess fails
with e=87 _and_ the environment is larger than 32KB? That would allow
us to avoid calling GetVersionEx, which MS wants to deprecate (see
http://msdn.microsoft.com/en-us/library/windows/desktop/ms72445
"Gisle Vanem" wrote:
My revised patch doesn't use GetVersionEx(). Attached.
I forgot the patch for proc.h:
diff --git a/w32/subproc/proc.h b/w32/subproc/proc.h
index 62ebf65..ed8d3d4 100644
--- a/w32/subproc/proc.h
+++ b/w32/subproc/proc.h
@@ -24,6 +24,6 @@ typedef int
> Would you like to write a modified patch along these lines?
Okay, will do.
Done. Output in this case is now something like:
process_begin: CreateProcess(g:\MingW32\msys\bin\echo.exe, echo "Generating
..", ...) failed.
CreateProcess probably failed due to a too large environment. Env-size
"Eli Zaretskii" wrote:
Wouldn't it be better to display the error only if CreateProcess fails
with e=87 _and_ the environment is larger than 32KB? That would allow
us to avoid calling GetVersionEx, which MS wants to deprecate (see
http://msdn.microsoft.com/en-us/library/windows/desktop/ms72445
According to:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms682653(v=vs.85).aspx
the total size of the environment is 32kByte. This has hit me several
times in GNU-make when CreateProcess() triggers the mysterious error
87 (ERROR_INVALID_PARAMETER). Like in a very simple rule that in
"Paul Smith" wrote:
Then make invokes the shell with the results of the expansion, which are
the rm and echo commands (and some empty strings which are ignored).
So, the rm is running AFTER the file is created, and deleting it.
Thanks. That makes sense when I think about it.
--gv
_
I'm trying to understand if my use of the $(file..) function is correct or
not. Based on tests/scripts/function/file, I cooked up this little file.mak:
all: file_test
cat file.out
.PHONY: file_test
file_test:
rm file.out
$(file > file.out, "Hello")
$(file >> file.out, "world")
@echo 'abspa
"Eli Zaretskii" wrote:
This project file doesn't specify any runtime lib to link with. Hence the default is to use
LIBCMT.LIB as if '-MT' was used. I would like to build using '-MD' (or '-MDd') which
pulls in msvcrt[d].dll (most MSVC software seems to be using this CRT these
days).
Why is t
I've compiled the lastest Git-repo with MSVC using the make_msvc_net2003.vcproj
project. This is a bit outdated (was converted to make_msvc_net2003.vcxproj by
my Visual Studio 2010. I also had to insert guile.c in again).
This project file doesn't specify any runtime lib to link with. Hence the d
"Eli Zaretskii" wrote:
What about setting:
ent->fptr.func_ptr = func;
too?
They are one and the same, since they are members of a union:
struct function_table_entry
{
union {
char *(*func_ptr) (char *output, char **argv, const char *fname);
char *(*alloc_func_ptr) (const char *fn
"Eli Zaretskii" wrote:
Well, the tests in the test suite that test this feature did work for
me at some point, so you may wish first to verify they do for you, and
then compare your extension with the ones used by the test suite, to
see what's different.
Well this is just silly. I've added tr
"Eli Zaretskii" wrote:
I don't understand the problem you are describing. First, when Make
is built, it produces gnumake.exe, not make.exe. And second, if
make.exe that runs is on PATH, rather than in the current directory,
it's a different executable, and there should be no problem linking
i
Hi list.
I just built GNU make 3.99.93 using MingW. I tried long and
hard to get the "load" feature to give me anything useful. But no
success so far with a very simple mk_test.dll.
In my Makefile, I have this:
VERSION = 3.99.93
ifeq ($(MAKE_VERSION),$(VERSION))
-load ./mk_test.dll
endif
The a
57 matches
Mail list logo
