I'm using the following:
yapn:[EMAIL PROTECTED]:~/proj/aoeu> make --version
GNU Make 3.81beta4
Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Well, at least it's consistent with:
FOO := foo
FOO +=
all: ; @echo '"$(FOO)"'
Having said that, I suppose it would it would be nice for it not to add the
space for situations like:
FOO := foo
FOO += $(BAR)
in which BAR isn't defined.
Noel
[EMAIL PROTECTED] wrote:
I just realized this, which I thi
This sounds to me like you have a recursive make structure that's trying to cd
into a subdirectory to do another gmake install. If so, the cd could be
failing so the gmake install goes into an infinite loop.
Alan Cooney wrote:
I have GNU make version 3.80 on Linux Fedora Core 3. When I try to
i
Paul D. Smith wrote:
Personally, I don't agree with the attitude that gotos are always evil
and should never be used (certainly in C). I find that, used in
specific ways, they make code much clearer by avoiding the useless noise
of deeply nested conditionals.
I completely agree with this sentiment
Try:
$ cat >bar.make
include foo.make
$(warning $(dir $(word $(words $(MAKEFILE_LIST)),$(MAKEFILE_LIST
Noel
Boris Kolpackov wrote:
Noel Yap <[EMAIL PROTECTED]> writes:
Unless MAKEFILE_LIST is used before any other includes, using the trick
below doesn't work.
$ cat >
Boris Kolpackov wrote:
Noel Yap <[EMAIL PROTECTED]> writes:
How are you going to guarantee that the names of the variables are unique?
You could use variable framing ;-)
What's variable framing?
Do you still think that MAKEFILE_LIST is a scalable, viable solution?
It is good enough t
Boris Kolpackov wrote:
One thing I can say right now is, if you had an include-makefile function,
the below would become:
$(call include-makefile,foo.make) # frame-enter and
frame-leave are implicit
Well, when you include a makefile you would probably want it's variable
definitions too so I am
e:
$(call include-makefile,foo.make) # frame-enter and frame-leave are
implicit
Thanks,
Noel
Boris Kolpackov wrote:
Noel Yap <[EMAIL PROTECTED]> writes:
How are you going to guarantee that the names of the variables are unique?
You could use variable framing ;-)
What's variabl
Unless MAKEFILE_LIST is used before any other includes, using the trick below doesn't work. I think it's also quite messy to have to create explicitly a variable to hold this information in each makefile that needs it. Moreover, there's no guarantee that
someone won't overwrite the variable in w
scalable, viable solution?
Noel
Boris Kolpackov wrote:
Noel Yap <[EMAIL PROTECTED]> writes:
Try:
$ cat >bar.make
include foo.make
$(warning $(dir $(word $(words $(MAKEFILE_LIST)),$(MAKEFILE_LIST
You gotta be kidding me!
p := $(dir $(word $(words $(MAKEFILE_LIST)),$(MAKEFILE_LIST))
Boris Kolpackov wrote:
Noel Yap <[EMAIL PROTECTED]> writes:
Try:
$ cat >bar.make
include foo.make
$(warning $(dir $(word $(words $(MAKEFILE_LIST)),$(MAKEFILE_LIST
You gotta be kidding me!
p := $(dir $(word $(words $(MAKEFILE_LIST)),$(MAKEFILE_LIST)))
include foo.make
$(warning $
Boris Kolpackov wrote:
Alternatively, if you have a makefile which is always included at the
top (say your bootstrap.make file) you can put the "all" target in that
file as the first thing:
Now you are forcing user to use the same name for default target which is
not always acceptable (well, at lea
Paul D. Smith wrote:
%% Jim <[EMAIL PROTECTED]> writes:
j> Absolutely...
j> all: junk.test
j> $.test:%.c | thing
j> touch $@
j> junk.c thing:
j> touch $@
j> make...
j> (touches thing and junk.c to create them)
j> then after every touch of 'thing' junk.test is t
Paul D. Smith wrote:
Making it work the way you want (if I understand you correctly), where
steps 2 and 3 are performed in a loop so that the re-exec happens
immediately when each makefile is rebuilt instead of after all the
makefiles are rebuilt, is simply not the way make is designed. Trying
to
Jim wrote:
Some ideas I've toyed with - a make preprocessor... alternative makes -
cook, hmm can't think of the others off the top of my head..
I've been saying this for several years now, but one day I'll learn cook :-)
Make is good... there have been several things I've wanted that I
couldn't
Jim wrote:
I'm not really sure if this falls in the same category, but the rule
base is a pattern rule... it seems that something like
%.o:%.c | $(intermdiate_path)
intermediate_path is no longer order only, it is instead a valid rule,
and that being a directory means it's often newer then the
Can you state what you want to do in development process terms, rather than makefile implementation terms, please? Maybe there's another solution that doesn't involve extremely complicated makefiles (maybe it doesn't even involve make ;-).
Thanks,
Noel
Jim wrote:
If there was just a way to end m
Jim wrote:
Maybe you could chalk this up to a documentation bug, it says whenever
ANY included makefile is read, it reloads, the above trace indicates
that two rules to generate makefiles were performed before reloading...
I still don't understand what the problem is; the documentation, accordin
Jim wrote:
Noel Yap wrote:
The amount of hairy code in a system stays constant :-) Although the
definition may be ugly, it's usage is pretty simple:
$(call include-makefile,my-makefile)
well yeah - but include-makefile supplies ,-include,$(m), for the $(1)
and $(2) in _include-mak
Jim wrote:
Well that's an ugly thing :)
The amount of hairy code in a system stays constant :-) Although the definition may be ugly, it's usage is pretty simple:
$(call include-makefile,my-makefile)
> $(1) $(2)
within the macro will include a makefile on the fly eh? but sometime
after a
Jim wrote:
Noel Yap wrote:
okay so I extended it some... and this fails.
.PHONY:all
all: junk;
@echo $(TICKS)
include ticks2
ticks2:
@echo TICKS=a number >> ticks2
include make2
make2:
@echo junk: >>make2
@echo echo $(TICKS) >>make2
if ticks2 were really r
Jim wrote:
Hmm not sure how eval equates to include...
Since the actual end in mind is a Makefile.cache, which is the literal
expanded targets, rules nessecary to genearte the product defined by the
makefile... This must be dependant on all makefiles which may have
changed... the final result
Jim wrote:
Noel Yap wrote:
This makefile works:
.PHONY: all
all: ;
include ticks
ticks:
@touch $(@)
How do you know? Sure the rule is done, it doesn't mean that ticks is
reloaded
Since we have this sort of thing in our makefiles, I'm pretty sure it gets reloaded. The
This makefile works:
.PHONY: all
all: ;
include ticks
ticks:
@touch $(@)
Try adding to it little by little until it stops working.
Noel
Jim wrote:
Noel Yap wrote:
It would help if you can post a /minimal/ makefile that demonstrates
the problem.
right here - there is no fewer
It would help if you can post a /minimal/ makefile that demonstrates the problem.
Noel
Jim wrote:
Noel Yap wrote:
I've done what the documentation describes many, many times. It's
always worked for me.
Which make are you using? Are you sure it's GNU make?
3.80 positive
Paul D. Smith wrote:
%% "Dave Korn" <[EMAIL PROTECTED]> writes:
The problem is that in many makefiles you tend to get a lot of "false
positives".
For example, many makefiles leave certain variables to be set by the
user, like CPPFLAGS or CFLAGS. If you do that in your makefiles, and
the user has
I've done what the documentation describes many, many times. It's always worked for me.
Which make are you using? Are you sure it's GNU make?
http://make.paulandlesley.org/autodep.html provides more examples on how to rebuild included makefiles.
HTH,
Noel
Jim wrote:
http://www.gnu.org/softwar
Paul D. Smith wrote:
%% Boris Kolpackov <[EMAIL PROTECTED]> writes:
bk> If you expect it to print
bk> %r: | baz
bk> then look in read.c line 537. The dumping code simply does not
bk> distinguish between normal and order-only prerequisites.
ITYM rule.c.
I have a fix for this already b
Paul D. Smith wrote:
%% Noel Yap <[EMAIL PROTECTED]> writes:
ny> Hmmm, I ran into something similar in which:
ny> a := A
ny> bar:
ny>@echo $a
ny> a := B
ny> would output B.
Of course. As expected.
Command scripts are not expanded until they are abo
Hmmm, I ran into something similar in which:
a := A
bar:
@echo $a
a := B
would output B.
Does this patch fix this as well?
Thanks,
Noel
Boris Kolpackov wrote:
Good day,
The following makefile prints 'B' instead of 'A'.
a := A
%bar : arg := $a
%bar : ; @echo $(arg)
a := B
foobar:
Once this patch is installed, does "gmake -npqr | grep '%r:'" output the proper thing? If so, I suspect this patch will fix much of the odd behaviour I've seen with regards to implicit rules and order rules.
Thanks,
Noel
Boris Kolpackov wrote:
Good day,
The following makefile prints "baz foo ba
Noel Yap wrote:
> It's even uglier when you're dealing with macros:
>
> $(FOO): $(dir $(FOO)).
Correction, this should be:
$(FOO): | $(dir $(FOO)).
Noel
--
NOTICE: If received in error, please destroy and notify sender. Sender does not waive
confidentiality or pr
Boris Kolpackov wrote:
>
> Hi Noel,
>
> > Since there is a workaround, simplifying GNU make in this respect
> > isn't worth it.
>
> Speaking of workaround, having the following implicit rule
>
> %/. :
> @mkdir $*
>
> you cannot just write
>
> foo : bar/
>
> instead you will have to w
"Paul D. Smith" wrote:
> It's done so that if you write:
>
> foo: bar/
>
> in one place in your makefile, and:
>
> bar: biz
>
> another place, and:
>
> boz: $(CURDIR)/bar
>
> in a third place, make realizes they are all the same target and won't
> try to build them multiple times
"Paul D. Smith" wrote:
> GNU make strips trailing slashes, so that "foo/" and "foo" are
> considered the same prerequisite.
Is there any reason, other than backwards compatibility, to keep this particular
feature? I find it a bit annoying although the workaround is feasible.
Thanks,
Noel
--
NO
Will this release include the distributed make feature? If not, when do you think
this will be incorporated?
Thanks,
Noel
"Paul D. Smith" wrote:
>
> %% "Dr. Jörn von Holten" <[EMAIL PROTECTED]> writes:
>
> jvh> I'm currently using 3.81rc1 (taken from CVS) and I'm quite
> jvh> satisfied.
"Dale R. Worley" wrote:
>
> [This enhancement request is for Gnu make 3.79.1.]
>
> It would be a useful thing if Make variable names were forbidden to
> contain slash (`/'), as well as `:', `#', and `='. The reason I make
> this request is that I was rebuilding a Linux kernel in a directory
> na
The error indicates that the build is trying to include a file called
"makefile.d" which doesn't exist. If you need further assistance, you'll
need to contact whomever wrote the SOS software.
HTH,
Noel
"posta Enrico" <[EMAIL PROTECTED]> wrote:
>
>I download yhe file SOS-10.12.03.zip and I follow
Great. Has this patch been submitted?
Thanks,
Noel
Benoit Poulot-Cazajous wrote:
>
> Noel Yap <[EMAIL PROTECTED]> writes:
>
> > $(install.DIR)/common/%/.: | $(install.DIR)/common/.
> >@echo building $(@): $(^)
>
> order-only dependencies do not
"Paul D. Smith" wrote:
> accurate: for example GNU make has had support for distributed builds
> for a long time (at least on UNIX platforms), but it requires linking in
> a 3rd party library (free, but not provided with GNU make).
I didn't know about this. Can you provide a URL?
Thanks,
Noel
ndency rule is being changed to a normal dependency.
Thanks,
Noel
Noel Yap wrote:
>
> I'm getting the following output:
>
> $ ls -ld ../install/common/.
> drwxr-x---5 yapn morgan 96 Nov 9 16:52 ../install/common/./
>
> $ ls -ld ../install/common/m
I'm getting the following output:
$ ls -ld ../install/common/.
drwxr-x---5 yapn morgan 96 Nov 9 16:52 ../install/common/./
$ ls -ld ../install/common/make/.:
ls: ../install/common/make/.\:: No such file or directory
$ cat mf2
install.DIR := ../install
$(install.DIR)/common/%
Are you executing gmake with a target (eg "gmake all") or relying on the "first rule
hit" behaviour (eg "gmake")? If the former, what does "gmake -npqr all 2>&1 | grep
MAKECMDGOALS" give? If the latter, I think MAKECMDGOALS is supposed to be empty.
HTH,
Noel
Andy Xiao wrote:
>
> Is MAKECMDGO
According to the NEWS file that comes with the source, MAKECMDGOALS was added in 3.76.
HTH,
Noel
Andy Xiao wrote:
>
> I am executing gmake (verion 3.74) with a target: "gmake xxx", I am
> expecting the MAKECMDGOALS containing xxx.
>
> At 05:20 PM 10/30/2003 -0500, N
I'm not sure about your syntax. I think you might mean:
$(ROOT)etc/dir1/%: %
cp $< $@
chmod 644 $@
and so on.
Anyway the way I'd go about this would be:
$(foreach d,etc/dir1 etc/dir2 etc/dirN,$(eval $(ROOT)$(d)/%: % ; cp $< $@ && chmod
644 $@))
I haven't tested it, but it s
I've got the following makefile:
aoeu/aoeu: aoeu/
touch $@
%/:
mkdir -p $@
and get the following:
$ gmake
gmake: *** No rule to make target `aoeu', needed by `aoeu/aoeu'. Stop.
As a workaround for now, I'll append '.' to my rules.
Noel
--
NOTICE: If received in error, please d
I'm too lazy to do all this work in order to help you ;-)
Can you provide a minimal makefile and description directly in your email, please?
Thanks,
Noel
Jean Kusters wrote:
>
> Hello,
>
> Could you untar, unzip the attachment and read
> my README file which describes a problem which I
> can n
"Paul D. Smith" wrote:
> Yes, not only in theory but in fact.
>
> But what I'm saying is that if you're providing a capability to jump to
> where a target is defined, you'll have to pick one of those. How do you
> choose which one? Or do you list the install target 3 times?
Not that I agree wit
Alain Magloire wrote:
> I am just looking for feedbacks on how to tackle the issue, maybe the answer
> is not to change make and build other tools around it that can exploit its
> build paradigm?
> The goals are simple, help the users in the development cycle.
We have a standard, well-documented m
ld not be make's job.
> On Wed, Aug 27, 2003 at 05:14:50PM -0400, Noel Yap wrote:
> > Manoj Srivastava wrote:
> >
> > > If we found a security hole in a structure or function: how
> > > many projects would be impacted? All these are what if scenarios).
[EMAIL PROTECTED] wrote:
>
> On Wed, 27 Aug 2003 07:37:46 -0400, Noel Yap <[EMAIL PROTECTED]> said:
>
> >> I would like a way to list all dependencies and subdependencies of
> >> a given target to avoid the recursive shell function hackism I
> >>
[EMAIL PROTECTED] wrote:
> > Sorry for not checking the URL. If you're still interested in the
> > paper, googling for "recursive make harmful" turns up many links.
>
> OK. But I think we are being bitten by semantics -- the paper
> refers to inefficiencies in complex build environments
Manoj Srivastava wrote:
> What if I have a build machine, where several dozen projects
> of my software house are kept. I want a database of reverse
> dependencies, where every file that is changed gives a listing of
> targets and hence programs that would be affected.
>
> So, w
Manoj Srivastava wrote:
>
> Hi,
> [Please retain the CC to [EMAIL PROTECTED] so
>that the Debian Bug Tracking system can record your input]
>
> This was a feature request from a Debian user.
>
> I would like a way to list all dependencies and subdependencies of a
>
I'm not sure if this has been reported by anyone, but the following makefile:
define _append
ifeq ($(filter $(1),$(AOEU)),)
AOEU += $(1)
endif
endef
append = $(eval $(call _append,$(1)))
ifndef aoeu
aoeu := 1
$(call append,aoeu)
endif
.PHONY: aoeu
aoeu:
@echo $(AOEU)
produces
55 matches
Mail list logo
