Some compilers/linkers care about the order in which the files are given
to them. I currently have a build rule which takes a .depend file,
massages it with a sed script and then passes it to `tsort', but I feel
silly: `make' already has those dependencies at hand, and it knows very
well how to do
Is there some way to make "make" watch files (e.g. with `inotify') and
automatically rebuild dependencies on an ongoing basis?
Stefan
___
Help-make mailing list
Help-make@gnu.org
https://lists.gnu.org/mailman/listinfo/help-make
> Another option if you don't like non-static pattern rules or the
> special-case stuff involved, is to use a stamp file:
> yaccouts.stamp: parser.mly
> ocamlyacc $<
IIUC a degenerate form of this is to decide that "parse.ml" plays the
role of the stamp file, so you do
parser.ml: par
I need to update some files whenever a symlink changes, even if the new
target of the symlink is an old file.
How can I do that with GNU Make?
Stefan
___
Help-make mailing list
Help-make@gnu.org
https://lists.gnu.org/mailman/listinfo/help-mak
>> I need to update some files whenever a symlink changes, even if the new
>> target of the symlink is an old file.
>> How can I do that with GNU Make?
> See:
> -L, --check-symlink-times
> Use the latest mtime between symlinks and target.
Thanks. Is there a way to do it from
> MAKEFLAGS += -L
Ha!
Stefan "Thanks!"
___
Help-make mailing list
Help-make@gnu.org
https://lists.gnu.org/mailman/listinfo/help-make
My `make` complains that
make: execvp: /bin/sh: Argument list too long
make: execvp: /bin/sh: Argument list too long
but I'm having trouble figuring out which command's argument list is
too long. I tried "make -d" but it doesn't really help:
% LANG=C make -d
GNU Make 4.2.1
B
> > Looking at the make file I see one $(shell ..) invocation which is the
> > most likely culprit:
> >
> > define SET-diff
> > $(shell echo "$(1)" "$(2)" "$(2)" | tr ' ' '\n' | sort | uniq -u)
> > endef
>
> Could you use a standard Make rule to generate an output file,
How coul
>> How could I generate an output file via a Make rule when the desired
>> content of the file is in a Make variable that's too big for the
>> command line?
>
> If you are using GNU make 4.0 or better you can use the $(file ...)
> function to write to a file (there is no limit, other than memory, t
I'm using GNU Make here to keep some generated data files uptodate.
In general, the kind of facility offered by GNU Make fits this purpose
very well, but these files have all kinds of funny characters in their
names (spaces, semi-colons, colons, you name it) and here I bump into
lots and lots of
> On the hardware of the day, it took 30 seconds for GNU Make
> 3.80 to read the files and issue the first build command.
Do you have some idea of how those 30s were spent?
> So then I took the "unexec" code from GNU Emacs, transplanted it into
> GNU Make and hooked it to a "--dump" option.
> Now
I'm trying to make a rule along the following lines:
packages/%.tar.gz : $(shell find packages/% -name '*.el' -print | sed
's/\.el/.elc/')
tar -zcf packages/$*.tar.gz packages/$*
I expect the `%` which appears within the $(shell..) to be replaced with
the target's stem, but tests i
>> I'm trying to make a rule along the following lines:
>> packages/%.tar.gz : $(shell find packages/% -name '*.el' -print |
>> sed 's/\.el/.elc/')
>> tar -zcf packages/$*.tar.gz packages/$*
> I'd say this is wrongheaded, because you're saying that the materials
> which belong to this pack
> make, unfortunately it turns out, falls into that category for sure.
`make` feel very deeply in that category, to the point where it's not
just space, but several different characters and that it does not
include the necessary quoting functionality to make it *possible* to
deal with those charac
ut without having to buffer it until it ends.
IIUC this might require a non-trivial restructuring :-(
Stefan
Paul Smith [2022-09-23 15:19:09] wrote:
> On Fri, 2022-09-23 at 13:23 -0400, Stefan Monnier via Users list for
> the GNU implementation of make wrote:
>> I like the fac
>> Any hope to see a version of GNU Make that lifts those limitations,
>> providing some sane way to handle any character in filenames (and
>> ideally also able to sanely manipulate lists of such names)?
> A number of years ago I proposed a way to deal with special characters.
> You can find the st
> There is no issue.
> The legal aspects of linking GPL software with MSVCRT.DLL have been
> examined long ago, and the examination concluded that doing so is
> perfectly kosher.
I think you're talking at cross-purposes: you're talking about whether
it's legally safe to link to this library, where
I like the fact that `make -O` gives me output that's always meaningful,
but it's sometimes annoying how it's sitting idly while a command is
spewing output. To some extent it's unavoidable, but I wonder if we
could reduce the inconvenience by making such that Make emits the
subprocess's output wi
> My attitude about GTP answers is that they're OK to post, AS LONG AS
> you (the person who posts the answer) fully understands and agrees with
> everything in the response.
IMO, it's only OK to post if you clearly mark it as a citation
(e.g. indented, marked with "> ", or something), *and* you c
> Addendum, yes, directly via:
>
> define a b c
> ...
> endef
>
> as well as with embedded comma:
>
> define a b c,
> ...
> endef
>
> These can be referenced via $(a b c) and $(a b c,).
Eww!
Stefan
> Note I don't really recommend any of this. With the current
> limitations of make, as defined by POSIX, it's just very difficult to
Any hope to see a version of GNU Make that lifts those limitations,
providing some sane way to handle any character in filenames (and
ideally also able to sanely m
21 matches
Mail list logo
