First, are there any libraries out there that attempt to factor out the
common code to build object files, link into programs/static/shared libs, etc.?
Essentially I'm thinking of a replacement for the old built-in rules implicit
rules but with everything visible in a fragment that you include.
I
On Wed, Nov 14, 2012 at 10:37 PM, Warlich, Christof
wrote:
>> I think this is correct behavior. Why do you think the rules for the 'all'
>> target should not be executed? The else part states that all targets
>> matching
>> % depend on all, so its rules get run first.
>
> I'm just puzzled bec
On Fri, Nov 16, 2012 at 7:14 AM, Philip Guenther wrote:
> On Fri, Nov 16, 2012 at 11:34 AM, Christof Warlich
> wrote:
>> Am 15.11.2012 21:08, schrieb Britton Kerin:
>>> Match-everything rules are really prone to problems of this sort. The -d
>>> flag will give you
On Thu, Nov 29, 2012 at 8:50 AM, Brian J. Murrell wrote:
> I have a file which is not created by make but is created/updated by an
> outside process. The time stamp on this file will always be some time
> in the past. Let's call this file "O".
>
> I have a target which I want make to build which
On Sun, May 5, 2013 at 9:03 AM, Pau Koning wrote:
> Hi,
>
> there are currently some things going on regarding the analysis of the
> build logs using blhc. This is extreme nice and made me think about a
> sentence most people missed in the GCC documentation (it is repeated often):
>
> "For predict
On Tue, May 7, 2013 at 1:16 PM, Mark Galeck wrote:
>>
>> Assigning to MAKEFLAGS only affects sub-makes, despite this (wrong)
>> paragraph from the documentation:
>>
>> MAKEFLAGS
>>The flags given to make. You can set this in the environment
>>or a makefile to set flags. See Communicating O
On Sun, Jun 2, 2013 at 7:12 AM, Rakesh Sharma wrote:
> Hello gnu makers,
>
> I wanted to enquire about the utility of intermdiate pre-requisites in gmake.
> Where & under what scenarios are they to be utilized in writing our
> makefiles. The documentation in the make manual is somewhat confusing
I wonder if it would be good to have a built-in like $(shell ...) that dies
if the given command exits with non-zero exit code.
Currently I have this somewhat icky fctn:
# This function works almost exactly like the builtin shell command, except it
# stops everything with an error if the shell co
On Fri, Nov 14, 2014 at 8:34 PM, Tim Murphy wrote:
> Hi :-)
Hello :)
> On 14 November 2014 19:31, Britton Kerin wrote:
>>
>> On Fri, Nov 14, 2014 at 1:35 AM, Tim Murphy wrote:
>> > To save typing here's an example of some of the possible hacks:
>> >
On Tue, Jan 27, 2015 at 12:35 PM, Jonathan Lennox wrote:
> Hi —
>
> I’m trying to structure a Makefile for a situation where a target depends on
> inputs that are in a subdirectory, which can be rebuilt by recursive make.
>
> The specific case is a top-level Makefile which builds a binary, which
On Tue, Jan 27, 2015 at 12:35 PM, Jonathan Lennox wrote:
> Hi —
>
> I’m trying to structure a Makefile for a situation where a target depends on
> inputs that are in a subdirectory, which can be rebuilt by recursive make.
>
> The specific case is a top-level Makefile which builds a binary, which
On Tue, Jan 27, 2015 at 1:55 PM, Jonathan Lennox wrote:
>
> On Jan 27, 2015, at 5:23 PM, Britton Kerin wrote:
>
>> On Tue, Jan 27, 2015 at 12:35 PM, Jonathan Lennox wrote:
>>> Hi —
>>>
>>> I’m trying to structure a Makefile for a situation where a t
One other small thing that may or may not be obvious: if your
estimationkmer.py script fails (returns non-zero), you won't be
notified (and ESTK will likely end up empty).
Paul, is there any chance of adding a different version of $(shell)
that fails noisily if the given shell command returns non-
MAKEFLAGS += rR still doesn't work as expected:
$ cat Makefile
MAKEFLAGS += rR
CC ?= my_gcc
debug:
@echo 'origin of CC:' $(origin CC)
@echo 'value of CC: ' $(CC)
%.o: %.c
$(CC) $< -o $@
$ touch test.c
$ make test.o
On Fri, Aug 26, 2016 at 7:37 AM, Paul Smith wrote:
> Please be sure to keep the mailing list in the loop, thanks!
>
> On Thu, 2016-08-25 at 11:55 -0800, Britton Kerin wrote:
>> It should explicitly mention that setting it in a makefile won't set
>> flags for that inst
It says this:
An example will illustrate this:
clean: FORCE
rm $(objects)
FORCE:
Here the target ‘FORCE’ satisfies the special conditions, so the
target clean that depends on it is
forced to run its recipe. There is nothing special about the name
‘FORCE’, bu
After a pretty large amount of Make I've concluded that one of the things that
tends to make make confusing is the fact that it uses linear order-dependent
code to express a DAG which isn't linear at all. A Makefile is just be a
database of facts about a DAG, so order should be strictly a matter o
This seems to work:
%.o: COMPILE = cp
%.o: %.c
$(COMPILE) $< $@
but it makes me a little nervous. The manual doesn't seem to mention
it in either the section on target-local variables or the one on
pattern rules. Is this well defined and intentionally supported
behavior?
Thanks,
Britt
On Wed, Jul 26, 2017 at 5:31 AM, Paul Smith wrote:
> On Wed, 2017-07-26 at 15:21 +0200, Sébastien Hinderer wrote:
>> Sorry, I meant:
>>
>> parsers := foo.mly bar.mly baz.mly
>>
>> $(parsers): %.ml %.mli: %.mly%.ml %.mli: %.mly
>> ocamlyacc $<
>
> No. That's a static pattern rule. You
On Wed, Jul 26, 2017 at 9:31 AM, Paul Smith wrote:
> On Wed, 2017-07-26 at 09:17 -0800, Britton Kerin wrote:
>> 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.m
On Wed, Jul 26, 2017 at 12:44 PM, Paul Smith wrote:
> On Wed, 2017-07-26 at 12:31 -0800, Britton Kerin wrote:
>> It's still worth it to avoid non-static pattern rules though IMO.
>
> I use normal pattern rules all the time in all my makefiles. Love 'em,
> and I see
Make treats intermediate files specially in two ways as described here:
https://www.gnu.org/software/make/manual/html_node/Chained-Rules.html#Chained-Rules
I guess this behavior doesn't apply to static pattern rules, since
listing every file they apply to presumably counts as "mentioning"
them as
I'm frequently rebuilding and uploading both ends of a tx/rx system
and it's just slow enough to be annoying. I'd like to rebuild the Tx
and Rx ends in parallel but they need different build options for the
same sources.
I'm guessing the easiest approach is to do cp -r or so from a script
and run
I currently have this:
SHELL_CHECKED = \
$(strip\
$(if $(shell (($1) 1>/tmp/SC_so) || echo nonempty), \
$(error shell command '$1' failed. Its stderr should be
The manual says:
The syntax of the conditional-directive is the same whether the
conditional is simple or complex; after an else or not. There are four
different directives that test different conditions. Here is a table
of them:
ifeq (arg1, arg2)
ifeq 'arg1' 'arg2'
ifeq "arg1" "arg2"
ifeq "arg1"
I've got vars like DEBUG_ENABLE only a big hairy pile of them at this
point, and I want make to rebuild everything when I give a different
set of them (including via command line) with my having
to remember to do clean first.
I can see how it might be done using .VARIABLES and a cache of some
sort
Given this Makefile:
VPATH = a_subdir
foo: some_prereq
touch $@
bar: some_prereq
touch $(VPATH)/$@
$(VPATH)/baz: some_prereq
touch $@
Rebuilding an already-up-to-date $(VPATH)/baz using 'make baz' doesn't
give the usual "is up to date" message, even though the recipe is
I'd like to use eval to emit some boilerplate vars and everything
short of the prereq list for a
static pattern rule. Is it possible? This is as close as I came:
# Production Stamp Target Header Template
PSTHT = \
$1_STAMPS = $$(PBT:.pcb=.$1.stamp)$(nl) \
PRODUCT
Maybe the below makes sense for some reason I don't understand but it
sure seems weird.
Seems like $< ends up with a different value depending on where the
request for the target comes from:
$ ls
Makefile
$ cat Makefile
OBJS = foo.o
FC = cp # Fake Compile
FL = cp # Fake Link
vpath %.o objdir
%.
It looks to me like when vpath evolved from VPATH a few things could
have been better:
1. It should just set the path, not add to a list of paths anymore.
The original behavior was needed for VPATH but since vpath works
per-pattern (or even per-target) it's pointless and potentially
confusing: th
On Thu, May 20, 2021 at 6:19 AM Paul Smith wrote:
>
> I'm adding help-make back; hope you don't mind. I prefer to keep all
> discussion of make on the lists.
>
> On Wed, 2021-05-19 at 16:45 -0800, Britton Kerin wrote:
> > > They are there to find _SOURCES_
The rebuild-the-world-if-anything-changed approach turned out to be
pretty simple I think. Opinions welcome on the below solution, I
haven't used it much yet. It can be tricked by pathological stuff
like ifdef SOME_VAR ... endif SOME_VAR=constant_val (without any
effects on other variables in ...
emo target
bar: foo
# Fake build for demo:
cp $< $@
clean:
rm -f $(OSMVF)
On Wed, Jun 9, 2021 at 6:14 PM Britton Kerin wrote:
>
> The rebuild-the-world-if-anything-changed approach turned out to be
> pretty simple I think. Opinions welcome on the below solu
As it is it easily creates a bunch of circular dependencies that
require the user to manually specify target-local .EXTRA_PREREQS for a
bunch of targets to avoid.
For example:
.PHONY: dependency_checks
dependency_checks: avrdude_version_check \
avrgcc_version_ch
On Tue, Jun 15, 2021 at 4:22 AM Mark Piffer wrote:
>
> My solution was to separate the build system into a (non-recursive) structure
> of make files which each have roughly speaking only one recipe. You may raise
> an eyebrow but I can assure you that the segregation of a build process in
> thi
Ok since I posted the first two attempts I'll add the latest fix here
also (while recognizing that this is a good example of why posting
solutions to email lists is not a good idea in general). The problem
was MAKECMDGOALS which means solution didn't work when switching
between targets. So:
OSMV
On Fri, Oct 8, 2021 at 12:10 PM Nicholas Clark wrote:
>
> I think it's a great change. I'd love for Make to understand trailing
> slashes intelligently, and I think it makes sense as a default.
I dunno, I'm on wrong computer to check but I believe other tools
sometimes distinguish between foo and
I notice that implicit-rule local variables now work:
BBS = foo.bb
%.bb: SHELL = /usr/bin/perl
%.bb: .SHELLFLAGS = -w -E
$(BBS): %.bb: %.aa
not system("cp $< $@") or die;
any change we could take the next step and make static-pattern local
vars? Like so:
BBS = foo.bb
$(BBS): %.bb: SH
I don't know how POSIX-ish it is but IMO -x deserves a mention,
especially since -e gets one. It's a little annoying that it end up
repeating the commands a second time, but without it you end up with
all the commands listed, followed by an error for one of the early
ones which is confusing at bes
I'd like to use:
SHELL = /usr/bin/perl
.SHELLFLAGS = -w -E 'use warnings FATAL => "all";' -E
but it doesn't work, saying at recipe execution time:
Can't find string terminator "'" anywhere before EOF at -e line 1.
I tried a few other quoting combinations without any luck. It loo
I'd like to migrate to .ONESHELL but I'm too scared to use it with
everything yet. Is there any way to apply it on a per-target basis?
Britton
On Mon, Jan 10, 2022 at 8:45 AM Cook, Malcolm wrote:
>
>
> >I'd like to migrate to .ONESHELL but I'm too scared to use it with
> >everything yet. Is there any way to apply it on a per-target basis?
>
> FWIW: Not to my knowledge.
>
> You *can* usefully use [Target\-specific Variable
> Values](http
On Mon, Jan 10, 2022 at 8:29 AM Cook, Malcolm wrote:
>
> >I'd like to use:
> >
> >SHELL = /usr/bin/perl
> >.SHELLFLAGS = -w -E 'use warnings FATAL => "all";' -E
> >
> >but it doesn't work, saying at recipe execution time:
> >
> >Can't find string terminator "'" anywhere before EOF at -e line 1.
>
On Tue, Jan 18, 2022 at 4:51 PM Hongyi Zhao wrote:
>
> On Wed, Jan 19, 2022 at 2:56 AM Paul Smith wrote:
> >
> > On Tue, 2022-01-18 at 10:14 +0800, Hongyi Zhao wrote:
> > > But it seems that the `$?' used above can't obtain the exit status of
> > > the code block in @(...) when used from outside
44 matches
Mail list logo
