Re: kbuild: Problem with latest GNU make rc
On Sun, Mar 05, 2006 at 05:21:08PM -0500, Paul D. Smith wrote: > %% Sam Ravnborg <[EMAIL PROTECTED]> writes: > > sr> I foresee a lot of mails to lkml the next year or more with this > sr> issue if kept. People do build older kernels and continue to do so > sr> the next long time. Especially the embedded market seem keen to > sr> stay at 2.4 (wonder why), and as such we will see many systems > sr> that keep older kernel src but never make behaviour. > > Well, this behavior doesn't exist in 2.4 kernels, since the kernel build > in 2.4 was very different. Nevertheless there are plenty of 2.6 kernels > out there :-). OK, I did not actually look at 2.4. But you are right that the build system has seen a few updates since then. > sr> Suggestion: > sr> We are now warned about an incompatibility in kbuild and we will > sr> fix this asap. But that you postpone this particular behaviour > sr> change until next make release. Maybe you add in this change as > sr> the first thing after the stable relase so all bleeding edge make > sr> users see it and can report issues. > > I am willing to postpone this change. However, I can't say how much of > a window this delay will give you: I can say that it's extremely > unlikely that it will be another 3 years before GNU make 3.82 comes out. One year would be good. The fixed kernel build will be available in an official kernel in maybe two or three months form now. With current pace we will have maybe 3 more kernel relase until this hits us. And only on bleeding edge machines. > sr> It is not acceptable that the kernel links each time we do a make. > sr> We keep track of a version number, we do partly jobs as root etc. > sr> So any updates on an otherwise build tree is a bug - and will be > sr> reported and has to get fixed. > > I've modified the kbuild system to collect .PHONY files into a variable, > PHONY, and then used that in the if_changed* macros. > > Using this method I've determined that the new version of GNU make works > exactly like the old version under various tests (build from scratch, > rebuild without any changes, rebuild with simple changes, etc.) > > I've submitted a patch to linux-kernel implementing this change, with > an appropriate Signed-off-by line. GNU make is used and abused in several ways in the kbuild files. If you found something prticular fishy then please let me know, there may well be better solutions for part of the build system that I am not aware of. Sam ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: kbuild: Problem with latest GNU make rc
[linux-kernel added. Please keep both bug-make and linux-kernel] On Wed, Mar 01, 2006 at 10:46:25AM -0500, [EMAIL PROTECTED] wrote: Content-Description: message body text > Hi all. I've set Reply-To: to the bug-make@gnu.org list; I'm hoping we > can keep the discussion there since I don't subscribe to kbuild-devel. > > > I'm working on getting the next release of GNU make, 3.81, out the door > (amazing!) The weekend before last I released 3.81rc1 for people to > test. A day or two ago, Art Haas <[EMAIL PROTECTED]> emailed me that he > was having problems using kbuild with this version. The previous > version, 3.81beta4, works fine. > > The symptoms are that much of the kernel was rebuilding over gain > every time he ran make, even after he'd just done a top-down build. > > I pulled the 2.6.15 kernel and sure enough, I see the same behavior. I > delved into the kbuild infrastructure and I found the problem. > > > The kbuild system uses a trick to force rebuilds if the command line > changes for a given target (normally make only rebuilds if the target is > out of date--some versions of make, like Solaris make, have a > .KEEP_STATE feature but GNU make does not support this). Here's a > stripped-down example of what kbuild does: > > .PHONY: FORCE > > %.o : %.c FORCE > $(if_changed_rule ...) > > if_changed_rule = $(if $(strip $? $(call arg-check, $(cmd_$(1)), $(cmd_$@)) > ),\ > @set -e; \ > $(rule_$(1))) > > The FORCE prerequisite causes ALL .o targets that match this rule to be > considered by make to be out of date (because FORCE is always > out-of-date and it's a prerequisite of the .o). > > The trick is in the if_changed_rule macro: it tests whether any > prerequisites have changed ($? is the changed prerequisites; it'll be > empty if none have changed) and whether the command lines have changed > (the call to arg-check). If those values are true (non-empty) it > expands to the rule. Otherwise it expands to nothing. > > GNU make takes several shortcuts to provide efficiency in places where > it doesn't matter, and so if it sees an empty command it doesn't try to > run a shell. In this way, kbuild gets the benefit of checking the > command line for every target without paying a price for useless shells > being invoked during the build. > > > However, this trick as implemented is accidentally relying on what may > be a misbehavior on GNU make's part: one that was changed in the latest > rc release. This is causing rebuilds to happen. > > In previous versions of GNU make, prerequisites that didn't exist were > not included in the $? variable. In the new version that's been changed > (fixed?) so that all out-of-date prerequisites are included in the $? > variable, even if they don't exist. > > > The old behavior allowed this rule to work, because even though FORCE > was out-of-date and would normally always appear in $?, it didn't exist > as a file and this exception caused it to be left out. So, the value of > $? was empty in the old version if the only prerequisite that was > considered out-of-date was the non-existent file FORCE. > > In the new version of GNU make, the value of $? is FORCE in that > situation, so the test in if_changed_rule is always true and it always > evaluates to the compile line, and rebuilds. > > > Neither the GNU make manual nor the POSIX definition of make gives us > clear direction as to the correct behavior in this particular situation. > SuS says: > > $? > The $? macro shall evaluate to the list of prerequisites that are > newer than the current target. It shall be evaluated for both target > and inference rules. > > The GNU make manual says: > > $? > The names of all the prerequisites that are newer than the target, > with spaces between them. > > So... is a non-existent file "newer than the target"? This specific > situation is not addressed. However, other versions of make (SysV make > for example) interpret a non-existent file as out-of-date and DO include > it in $?. Given the meaning of "newer than the current target" to make > (that it causes the target to be rebuilt) and the implied meaning of $? > (a list of the prerequisites that cause the target to be rebuilt), I > feel that the new behavior is correct and the old behavior is incorrect. > > > So. If the change is correct, how should we proceed? Obviously it's > not hard to change kbuild to fix the majority of the problem; replace > the above macro with something like: > > if_changed_rule = $(if $(strip $(filter-out FORCE,$?) $(call arg-check, > $(cmd_$(1)), $(cmd_$@)) ),\ > @set -e; \ > $(rule_$(1))) > > and all will be well. There are other, similar macros that need this > change as well. > And, there are other places where this $(filter-out > FORCE,...) is already done, so it's apparently come up before. Current use of $(filter-out FORCE, ...) is always with $^ where FORCE cor
make removes trailing '/' when dir does not exists
This is with GNU Make 3.80 Consider following Makefile: .PHONY: $(MAKECMDGOALS) $(MAKECMDGOALS): @echo $@ As expected it prints out the targetname when supplied with a filename as parameter (no matter if the file exists or not): make foo.c => foo.c When I try specifying an existing directory then is it also ok: make foo/ => foo/ When I try to specify a non-existing directory it no longer works: make bar/ => make: *** No rule to make target `bar/'. Stop. Digging a bit further I realised that make will drop the final '/' for non-existing directiories but I fail to see why it does so. A bug or a feature? Sam ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: make removes trailing '/' when dir does not exists
Any reply for this one? I still do not get the rationale behind it. A quick (very quick) grep in the make soruce did not tell me anything. Sam On Wed, Apr 05, 2006 at 11:57:51PM +0200, Sam Ravnborg wrote: > This is with GNU Make 3.80 > > Consider following Makefile: > > .PHONY: $(MAKECMDGOALS) > > $(MAKECMDGOALS): > @echo $@ > > As expected it prints out the targetname when supplied with a filename > as parameter (no matter if the file exists or not): > make foo.c => foo.c > > When I try specifying an existing directory then is it also ok: > make foo/ => foo/ > > When I try to specify a non-existing directory it no longer works: > make bar/ => make: *** No rule to make target `bar/'. Stop. > > Digging a bit further I realised that make will drop the final '/' for > non-existing directiories but I fail to see why it does so. > > A bug or a feature? > > Sam > > > ___ > Bug-make mailing list > Bug-make@gnu.org > http://lists.gnu.org/mailman/listinfo/bug-make ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: [bug #17529] Variable set with $(shell date '+%Y%m%d-%H%M%S') changes mid-make
On Sat, Aug 26, 2006 at 03:06:33AM +0200, Terry Jones wrote: > Hi Martin > > | > base = xxx-$(shell date '+%Y%m%d-%H%M%S') > | > | Perhaps you wanted := instead of =. The difference is explained in (for > | example): > | > | http://www.gnu.org/software/make/manual/html_node/Reading-Makefiles.html > | #Reading-Makefiles > > Thanks for the pointer. But, at least as I read that page, it sounds like > all variables are expanded exactly once - whether they are immediate or > deferred. Nope - this is wrong. Variables with deferred assignment are evaluated each time they are referenced which your example shows. And this is needed in many situations. Just think of the following variable: info = INFO $@ Here each time you reference $(info) is is evaluated. And in different command $@ may have different values. And for variables there is no difference if they are used twice in a command or in different commands. My rule of thumb is: Always use immediate (:=) variables unless there is a reason to use deferred variables. Sam ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: [bug #17880] Manual needs example for order-only prerequisites
> Details: > > This section needs an example and/or more clarification. > > http://www.gnu.org/software/make/manual/make.html#index-order_002donly-prerequisites-155 > Last time this was requested there was noone that could cook up a sensible example for this strange feature. So unless you come up with a good proposal it may not happen. Sam ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: build breaks
On Wed, Feb 28, 2007 at 07:36:27AM +, Guyeng Gankhuyag wrote:
> on PIII 800 PC System, Ubuntu 5.04, kernel 2.6.10-5-386
>
> the build breaks whenever I include the ext2_fs.h header into C file as
> simple as following:
>
> #include
> #include
> #include
> #include
> #include
> #include
So you are including a kernel header in your program.
>
> int main()
> {
>
> return 0;
> }
>
> I really believe what you guys do is a crap.
And report this in a mailing list used to report bugs
in the make program.
This list is not for random build failures.
So a few points to consider:
1) This is not related to problems with make.
2) You have a missing dependency - ext_fs.h needs one
or a few .h files included to compile.
grep is your friend here - or look at other
progrmas that uses ext2_fs.h.
3) Reporting this type of basic
problem I have the impression you try
to do something where you do not need
to deal with the internals of etx2.
For basic file operations use the glibc
provided header files.
Sam
___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make
Re: Error in kernel module
On Thu, May 24, 2007 at 05:24:21AM +0100, ajay parashar wrote: > Hi, > I am using fedora 6. i write a simple hello world kernel module > i write following makefile for building this module. > ### > > obj-m+=hello.o > all: > make -c /lib/modules/ $(shell uname -r)/ build M=$(PWD) modules > clean: > make -c /lib/modules/ $(shell uname -r)/ build M=$(PWD) clean > > ## > while runnimg make i am getting this error > > " This program is built for i686-redhat-linux-gnu > report bugs to > make *** [all] Error2 " > could you please let me know what is the issue. >From the linux kernel source - Documentation/kbuild/modules.txt: --- === 2. How to build external modules kbuild offers functionality to build external modules, with the prerequisite that there is a pre-built kernel available with full source. A subset of the targets available when building the kernel is available when building an external module. --- 2.1 Building external modules Use the following command to build an external module: make -C M=`pwd` For the running kernel use: make -C /lib/modules/`uname -r`/build M=`pwd` For the above command to succeed, the kernel must have been built with modules enabled. To install the modules that were just built: make -C M=`pwd` modules_install More complex examples will be shown later, the above should be enough to get you started. --- As you can see from the above you shall useupper case 'C'. Can I please ask you to post kernel related questions to [EMAIL PROTECTED] in the future. This is where the kernel people hangs out. And do not be shy and post all source + all output next time. Thanks, Sam ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: mention how to quote a comma in "call"
On Sat, Jun 02, 2007 at 05:25:50AM +0800, [EMAIL PROTECTED] wrote:
> Your
> reverse = $(2) $(1)
> example in the manual is great, however if one day your users happen
> to want to quote a comma,
> OK:;echo $(call reverse,a,b)
> SORRY1:;echo $(call reverse,a\,b,c)
> SORRY2:;echo $(call reverse,"a,b",c)
> then they are S.O.L. unless you mention how.
>
> One apparently needs to do
> EE=a,b
> OK2:;echo $(call reverse,$(EE),c)
>
> Mention that it is the only(?) way.
>
> Wait,
> OK3:;s=,;echo $(call reverse,a$${s}b,c)
>From info make:
Commas and unmatched parentheses or braces cannot appear in the text
of an argument as written; leading spaces cannot appear in the text of
the first argument as written. These characters can be put into the
argument value by variable substitution. First define variables
`comma' and `space' whose values are isolated comma and space
characters, then substitute these variables where such characters are
wanted, like this:
comma:= ,
empty:=
space:= $(empty) $(empty)
foo:= a b c
bar:= $(subst $(space),$(comma),$(foo))
# bar is now `a,b,c'.
Here the `subst' function replaces each space with a comma, through the
value of `foo', and substitutes the result.
Available online here:
http://uw713doc.sco.com/cgi-bin/info2html?(make.info)Syntax%2520of%2520Functions&lang=en
That should cover it.
Sam
___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make
Re: bug? $(warning)/$(error) evaluated from inside a comment in a 'define'?
On Tue, Jun 19, 2007 at 08:50:32PM +0200, Stephan Beal wrote: > Hi, Makers! > > i just discovered a Make behaviour which really surprises me. While that > in itself is nothing new ;), this one certainly violates the principal > of least astonishment: > > When a $(warning) or $(error) is inside a 'define', it is evaluated even > if it is part of a comment. A demonstration: > > [EMAIL PROTECTED]:~/cvs/www.t5$ make --version > GNU Make 3.81 > ... > > Input file to reproduce problem: > #!/usr/bin/make -f > ## > default: all > define bogo ># $(warning this should not be evaluated here: (bogo $(1))) >abc := $(1) > endef On the other hand I would have been suprised if make supported having comments between define/endef. So in several cases I have used define/endef to avoid the need to quote "#". Or in other words if "#" suddenly becomes a comment inside define/endef some Makefile's will break. Sam ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: problem
On Fri, Jul 27, 2007 at 04:13:57PM +0530, Gupta, Sonia (Product Engineering Services, Mumbai) wrote: > Hi, > While doing qmake calculator.pro we get an error Qfile:: file not > specified.atleast 100 times. Can you tell us why is that. I can only tell this is not a make error. So please direct your question to someone that knows the program or the library. Please drop gnu-make from your cc list. Thanks, Sam ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: problem
On Fri, Jul 27, 2007 at 12:13:16PM +0530, Laxman wrote: > Hi, > > > > While creating a executable for x86 target - Lynx OS found following error > > > > > > Reading makefiles... > Updating goal targets > File `first' does not exist. >File `all' does not exist. > File `calculator' does not exist. > Must remake target `calculator'. > g++ > -Wl,-rpath,/data/omni/lynx/4.0.0/x86/usr/local/Trolltech/qtopia-core-commerc > ial-src-4.1.4/lib -o calculator .obj/debug-shared-emb-auto/button.o > .obj/debug-shared-emb-auto/calculator.o .obj/debug-shared-emb-auto/main.o > .obj/debug-shared-emb-auto/moc_button.o > .obj/debug-shared-emb-auto/moc_calculator.o > -L/data/omni/lynx/4.0.0/x86/usr/local/Trolltech/qtopia-core-commercial-src-4 > .1.4/lib -lqte -mshared -ldl -mshared > /usr/lynx/4.0.0/x86/cdk/linux-elf-x86/usr/lib/gcc-lib/i386-lynx-lynxos/3.2.2 > /../../../../i386-lynx-lynxos/bin/ld: cannot find -lqte > collect2: ld returned 1 exit status > make: *** [calculator] Error 1 > > Please update us on following problem for compiling a program on cross > compiler. This is not a bug in make itself but related to building the program. So please try to ask a relevent place for the program. But from the link error I may guess you need to install a qt library (qt-embedded). Sam ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: Switching from CVS to GIT
On Sat, Oct 13, 2007 at 09:10:48PM +0200, Eli Zaretskii wrote: > > From: Paul Smith <[EMAIL PROTECTED]> > > Date: Sat, 13 Oct 2007 12:37:46 -0400 > > Cc: > > > > I'm considering switching from CVS to another form of SCM. > > Can you tell why? Paul already wrote: "I would like some more advanced SCM capabilities such as moving/renaming files (I've been putting off some code cleanups waiting for this)." Sam ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: [bug #21854] Dependency to a -l to be made in a not yet existing directory doesn't match(?)
> > gmake > > will fail, giving > > gmake: *** No rule to make target `-lfunny_name', needed by `my_program'. > Stop. > > while > > "mkdir temp; gmake" To create a directory I usually do: obj := temp # Create output directory if not already present _dummy := $(shell [ -d $(obj) ] || mkdir -p $(obj)) Works well and I recall it is recommended in make manual too. Sam ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: query
On Wed, Jan 02, 2008 at 09:59:41PM -0800, rohith s wrote: > hi > > this is rohith.s i am very new to this embedded field i have some doubt on > make gnu tool(make-3.8) windowsxp platform my project is porting linux > into some target processor so i need to generate linux kernel image so can > i do that in the windows plat form itself by using make tool >i tried to do that but it is giving error that no rule to make > target is there any standard procedure to do this please reply me > regarding this As this is related to building the linux kernel please post your question to [EMAIL PROTECTED] And include all the missing info: I assume you use cygwin - what version The exact error message Did you try to build some toy project just to check that your toolchain works? I assume you are aware that you need a cross ctoolchain .a s you are building on Windows XP but your target is a linux based box - so the native supplied gcc does not work for you. Anyway - please take it to linux-kernel and include the above requested info. Sam ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: Help : how to use $(or condition ) & $(and condition ) in makefiles
On Thu, Jun 05, 2008 at 05:36:56AM -0700, rakesh aggarwal wrote: > Hi, > > I read the GNU make manual and found there are $(or condition ) and $(and > condition ) functions. ( at > http://www.gnu.org/software/make/manual/make.html#Conditional-Functions ) > But i didnt get in which format i have to put conditions in these functions. Notice that this is condition and not expressions. Sample: havefile := $(if $(wildcard myfile.c), YES, NO) $(warning HAVEFILE=$(HAVEFILE)) This will print HAVEFILE=NO if no myfile.c exist (because the $(wildcard myfile.c) expands to an empty string Sam ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: Reg Make build on LINUX
On Tue, Jun 17, 2008 at 04:00:22PM +0530, A, Sravanthi wrote: > Team, > > Can any one of you help to resolve this issue. > My file structure will have root make file which will call makefiles in > each subfolder. Some of the CC files which are dependant on other folder > object files are getting recompiled. > > For example > 1. Folder d1 will have a.o which is compiled from a.cc > 2. Folder d2 has b.o which is compiled from b.cc. > 3. b.o is dependant on a.o How come that b.o is dependent on a.o? Sam ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: Bug in pattern rule parsing: how to handle?
On Sun, Oct 26, 2008 at 05:48:11PM -0400, Paul Smith wrote: > Hi all; > > While working on some changes to 2nd expansion etc. to try to reduce > total heap usage in GNU make, I've discovered that there is a bug in the > current makefile parsing. My new version doesn't have this bug (or, > more precisely, it contains the opposite bug) and I've noticed at least > two different build environments that stop working due to this: one is > glibc and one is the Linux kernel (!) Can you give me a more precise pointer where we have this issue so I can get it fixed. I guess it is Makefile.build... Thanks, Sam ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: Bug in pattern rule parsing: how to handle?
On Sun, Oct 26, 2008 at 07:12:53PM -0400, Paul Smith wrote: > On Sun, 2008-10-26 at 23:15 +0100, Sam Ravnborg wrote: > > Can you give me a more precise pointer where we have this issue > > so I can get it fixed. I guess it is Makefile.build... > > If you mean in the Linux kernel there are two places: > > Makefile:1601: *** mixed implicit and normal rules. Stop. > > # Modules > / %/: prepare scripts FORCE Here we try to catch that the following targets can be specified: make / make foobar/ make foo/bar/ I have this wake memory that I had some troubles initially when I did this. Most likely I did it the other way around: %/ /: bla bla and it did not work. But later I chenged the order and suddenly it worked. But you imply that it is not acceptable to mix it like I do. And this one looks easy to fix. I can rewrite it like this: %/: prepare scripts FORCE And we are happy. > and: > > Makefile:442: *** mixed implicit and normal rules. Stop. > > config %config: scripts_basic outputmakefile FORCE > $(Q)mkdir -p include/linux include/config > $(Q)$(MAKE) $(build)=scripts/kconfig $@ Here I try to catch the following: make config make menuconfig make xconfig make foobarconfig I must admit I cannot see the problem with mixing implicit and normal rules in the above. But I gues this is my simple use of it. Do you have any god suggestion how to rewrite this? Note: %onfig: works but I would hate to use it. Sam ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: Bug in pattern rule parsing: how to handle?
On Wed, Oct 29, 2008 at 07:24:50PM -0700, Philip Guenther wrote:
> On Wed, Oct 29, 2008 at 2:12 PM, Sam Ravnborg <[EMAIL PROTECTED]> wrote:
> > On Sun, Oct 26, 2008 at 07:12:53PM -0400, Paul Smith wrote:
> ...
> >> Makefile:442: *** mixed implicit and normal rules. Stop.
> >>
> >> config %config: scripts_basic outputmakefile FORCE
> >> $(Q)mkdir -p include/linux include/config
> >> $(Q)$(MAKE) $(build)=scripts/kconfig $@
> >
> > Here I try to catch the following:
> >
> > make config
> > make menuconfig
> > make xconfig
> > make foobarconfig
> >
> > I must admit I cannot see the problem with mixing implicit and normal
> > rules in the above. But I gues this is my simple use of it.
>
> I see at least two ways in which it's confusing:
> 1) what prerequisites does "foo" have with this rule:
> foo %.c: %.c.real
> @: cp $< $@
>
> 2) rules with multiple pattern targets have special meaning to make:
>Pattern rules may have more than one target. Unlike normal rules,
>this does not act as many different rules with the same prerequisites
>and commands. If a pattern rule has multiple targets, `make' knows
> that
>the rule's commands are responsible for making all of the targets.
> <...>
> I.e., this rule:
> %.a %.b:
> ${commands}
> says that building "bar.a" will also build "bar.b", and
> building "quux.a" will also build "quux.b". With this rule:
> foo %.a %.b:
> ${commands}
> should make assume that building "bar.a" will also build "bar.b"
> *and* "foo"?
> How about this rule:
> foo blip %.a %.b:
> ${commands}
> Will building "bar.a" also build "bar.b", "foo", and "blip"?
> How about this one:
> foo blip %.a:
> ${commands}
> ...whoops...
Thanks for the detailed explanation. I see how it is confusing in
the cases you list. I was initally wondering because the specific
usage in the kernel is simpler.
>
>
> > Do you have any god suggestion how to rewrite this?
[suggestions snipped]
Thanks. I will most likely do something along the lines of the last
suggestion.
Sam
___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make
Re: Bug in pattern rule parsing: how to handle?
On Wed, Oct 29, 2008 at 07:24:50PM -0700, Philip Guenther wrote: > On Wed, Oct 29, 2008 at 2:12 PM, Sam Ravnborg wrote: > > On Sun, Oct 26, 2008 at 07:12:53PM -0400, Paul Smith wrote: > ... > >> Makefile:442: *** mixed implicit and normal rules. Stop. > >> > >> config %config: scripts_basic outputmakefile FORCE > >> $(Q)mkdir -p include/linux include/config > >> $(Q)$(MAKE) $(build)=scripts/kconfig $@ > > > > Here I try to catch the following: > > > > make config > > make menuconfig > > make xconfig > > make foobarconfig > > > > I must admit I cannot see the problem with mixing implicit and normal > > rules in the above. But I gues this is my simple use of it. > > I see at least two ways in which it's confusing: > 1) what prerequisites does "foo" have with this rule: > foo %.c: %.c.real > @: cp $< $@ ... For the record I pushed the following patch to the Linux kernel. Sam >From 31110ebbec8688c6e9597b641101afc94e1c762a Mon Sep 17 00:00:00 2001 From: Sam Ravnborg Date: Sat, 13 Dec 2008 23:00:45 +0100 Subject: [PATCH] kbuild: fix make incompatibility "Paul Smith" reported that we would fail to build with a new check that may be enabled in an upcoming version of make. The error was: Makefile:442: *** mixed implicit and normal rules. Stop. The problem is that we did stuff like this: config %config: ... The solution was simple - the above was split into two with identical prerequisites and commands. With only three lines it was not worth to try to avoid the duplication. Cc: "Paul Smith" Signed-off-by: Sam Ravnborg --- Makefile | 12 ++-- 1 files changed, 10 insertions(+), 2 deletions(-) diff --git a/Makefile b/Makefile index be462cf..95160e5 100644 --- a/Makefile +++ b/Makefile @@ -439,7 +439,11 @@ ifeq ($(config-targets),1) include $(srctree)/arch/$(SRCARCH)/Makefile export KBUILD_DEFCONFIG KBUILD_KCONFIG -config %config: scripts_basic outputmakefile FORCE +config: scripts_basic outputmakefile FORCE + $(Q)mkdir -p include/linux include/config + $(Q)$(MAKE) $(build)=scripts/kconfig $@ + +%config: scripts_basic outputmakefile FORCE $(Q)mkdir -p include/linux include/config $(Q)$(MAKE) $(build)=scripts/kconfig $@ @@ -1493,7 +1497,11 @@ endif $(Q)$(MAKE) $(build)=$(build-dir) $(target-dir)$(notdir $@) # Modules -/ %/: prepare scripts FORCE +/: prepare scripts FORCE + $(cmd_crmodverdir) + $(Q)$(MAKE) KBUILD_MODULES=$(if $(CONFIG_MODULES),1) \ + $(build)=$(build-dir) +%/: prepare scripts FORCE $(cmd_crmodverdir) $(Q)$(MAKE) KBUILD_MODULES=$(if $(CONFIG_MODULES),1) \ $(build)=$(build-dir) -- 1.5.6.GIT ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: make error but no message
On Thu, Mar 12, 2009 at 02:07:56PM -0700, Jeremiah Perry wrote: > Hi, > > I don't know if the following is a bug or not, but it came to my > attention recently. I ran make on a project only to have make stop > abruptly with no error messages. After some digging, I found one of my > dependencies referred to a non-existent file. My dependency rules are > in .d files that I then -include into the makefile. See the code > example below. It seems this -include throws make off somehow so it > doesn't issue any error messages. However, when I put the dependencies > explicitly into the makefile, make tells me "*** No rule to make > target `doesnt_exist.h', needed by `test.o'. Stop.", so that seems to > be fine. I tried it here. With make 3.80 it works as expected. I do not have 3.81 handy right now. Which version of make did you use? Sam ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: make 3.82 fails on powerpc defconfig update [was: Linux 2.6.35]
On Mon, Aug 02, 2010 at 11:51:11AM +0300, Thomas Backlund wrote: > Hi, > (please cc me as I'm not subscribed) > > updating from make 3.81 to 3.82 gets me this: > > [tho...@tmb linux-2.6.35]$ cp arch/powerpc/configs/ppc64_defconfig .config > [tho...@tmb linux-2.6.35]$ LC_ALL=C make oldconfig ARCH=powerpc > /mnt/work/2.6.35/linux-2.6.35/arch/powerpc/Makefile:183: *** mixed > implicit and normal rules. Stop. > > The lines are: > > 182: > 183: $(BOOT_TARGETS): vmlinux > 184: $(Q)$(MAKE) ARCH=ppc64 $(build)=$(boot) $(patsubst > %,$(boot)/%,$@) > 185: > > BOOT_TARGETS are defined on line 166 as: > BOOT_TARGETS = zImage zImage.initrd uImage zImage% dtbImage% treeImage.% > cuImage.% simpleImage.% > > > Now it's not a regression in the kernel as the same happends with the > 2.6.34 tree too. > > (btw, the host I'm syncing the defconfig with is a x86_64 machine) > > > Now, I dont know if this is "intended breakage" by the make update, or > if the Makefile needs to be updated > > Any ideas how to fix ? This is in the category "intended breakage". We had a similar issue in the top-level Makefile which Paul (IIRC) helped me to fix long time ago. To fix popwerpc I suggest something along these lines. [Note: I did not test it - please do so. Sam [PATCH] powerpc: fix build with make 3.82 Thomas Backlund reported that the powerpc build broke with make 3.82. It failed with the following message: arch/powerpc/Makefile:183: *** mixed implicit and normal rules. Stop. The fix is to avoid mixing non-wildcard and wildcard targets. Reported-by: Thomas Backlund Cc: Michal Marek Signed-off-by: Sam Ravnborg --- diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile index 77cfe7a..ad88b21 100644 --- a/arch/powerpc/Makefile +++ b/arch/powerpc/Makefile @@ -163,9 +163,11 @@ drivers-$(CONFIG_OPROFILE) += arch/powerpc/oprofile/ # Default to zImage, override when needed all: zImage -BOOT_TARGETS = zImage zImage.initrd uImage zImage% dtbImage% treeImage.% cuImage.% simpleImage.% +# With make 3.82 we cannot mix normal and wildcard targets +BOOT_TARGETS1 := zImage zImage.initrd uImaged +BOOT_TARGETS2 := zImage% dtbImage% treeImage.% cuImage.% simpleImage.% -PHONY += $(BOOT_TARGETS) +PHONY += $(BOOT_TARGETS1) $(BOOT_TARGETS2) boot := arch/$(ARCH)/boot @@ -180,7 +182,9 @@ relocs_check: arch/powerpc/relocs_check.pl vmlinux zImage: relocs_check endif -$(BOOT_TARGETS): vmlinux +$(BOOT_TARGETS1): vmlinux + $(Q)$(MAKE) ARCH=ppc64 $(build)=$(boot) $(patsubst %,$(boot)/%,$@) +$(BOOT_TARGETS2): vmlinux $(Q)$(MAKE) ARCH=ppc64 $(build)=$(boot) $(patsubst %,$(boot)/%,$@) bootwrapper_install %.dtb: ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: make 3.82 fails on powerpc defconfig update [was: Linux 2.6.35]
> > Thanks, this seems to fix the first issue, but then I get the same erro on > the following line 190: > > 190: bootwrapper_install %.dtb: > 191:$(Q)$(MAKE) ARCH=ppc64 $(build)=$(boot) $(patsubst %,$(boot)/%,$@) > Obviously - dunno how I missed that. Updated patch below. I will do a proper submission after you confirm that powerpc build is working with make 3.82. Sam diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile index 77cfe7a..ace7a3e 100644 --- a/arch/powerpc/Makefile +++ b/arch/powerpc/Makefile @@ -163,9 +163,11 @@ drivers-$(CONFIG_OPROFILE) += arch/powerpc/oprofile/ # Default to zImage, override when needed all: zImage -BOOT_TARGETS = zImage zImage.initrd uImage zImage% dtbImage% treeImage.% cuImage.% simpleImage.% +# With make 3.82 we cannot mix normal and wildcard targets +BOOT_TARGETS1 := zImage zImage.initrd uImaged +BOOT_TARGETS2 := zImage% dtbImage% treeImage.% cuImage.% simpleImage.% -PHONY += $(BOOT_TARGETS) +PHONY += $(BOOT_TARGETS1) $(BOOT_TARGETS2) boot := arch/$(ARCH)/boot @@ -180,10 +182,16 @@ relocs_check: arch/powerpc/relocs_check.pl vmlinux zImage: relocs_check endif -$(BOOT_TARGETS): vmlinux +$(BOOT_TARGETS1): vmlinux + $(Q)$(MAKE) ARCH=ppc64 $(build)=$(boot) $(patsubst %,$(boot)/%,$@) +$(BOOT_TARGETS2): vmlinux + $(Q)$(MAKE) ARCH=ppc64 $(build)=$(boot) $(patsubst %,$(boot)/%,$@) + + +bootwrapper_install $(Q)$(MAKE) ARCH=ppc64 $(build)=$(boot) $(patsubst %,$(boot)/%,$@) -bootwrapper_install %.dtb: +%.dtb: $(Q)$(MAKE) ARCH=ppc64 $(build)=$(boot) $(patsubst %,$(boot)/%,$@) define archhelp ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: make 3.82 fails on powerpc defconfig update [was: Linux 2.6.35]
On Tue, Aug 03, 2010 at 12:03:35AM +0300, Thomas Backlund wrote: > 02.08.2010 23:51, Sam Ravnborg skrev: > >> > >> Thanks, this seems to fix the first issue, but then I get the same erro on > >> the following line 190: > >> > >> 190: bootwrapper_install %.dtb: > >> 191:$(Q)$(MAKE) ARCH=ppc64 $(build)=$(boot) $(patsubst > >> %,$(boot)/%,$@) > >> > > > > Obviously - dunno how I missed that. > > Updated patch below. > > > > I will do a proper submission after you > > confirm that powerpc build is working with make 3.82. > > > > Yeah, that was an obvious fix, thanks! > > One small typo fix below... > (a missing ':') > > Otherwise it works here, so: > > Tested-by: Thomas Backlund Thanks. I have sent a proper patch to Ben/Paul (powerpc maintainers). Sam ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: make 3.82 performing more stat() calls than 3.81
On Fri, Sep 16, 2011 at 07:18:32PM +, Troy Runkel wrote: > FYI, > > I believe I've located the fix in the GNU make CVS repository that resolves > the > excessive stat() call problem. I've back-ported the fix into 3.82 and it > appears > to be working in our build system. The patch for 'read.c' is attached if > anybody is interested. Just curious... Any reason why you are not running from latest CVS version? I assume that there are no know bugs in latest CVS - otherwise I would not ask.. And it seems that your setup would be a good test-candidate for latest CVS anyway. Sam ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [bug #33034] "Makefile:23: *** mixed implicit and normal rules. Stop." for Linux kernel out of source builds
On Thu, Nov 10, 2011 at 10:45:07AM -0600, Jonathan Nieder wrote: > David Boyce wrote: > > > I'm unsurprised at seeing no public response to > > yours either. But disappointed. > > I'm not disappointed. Paul doesn't work for me so there is no obligation > for him to write patches or design specs supporting my use cases. And > neverthless, so far I've had no reason to be unhappy with what he does. > > > I think the best approach is probably to follow the CVS commit trail, > > find the commit which fixed the original bug, and > > Yes, that's probably good advice. For the kernel Makefile this is the relevant commit: https://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=31110ebbec8688c6e9597b641101afc94e1c762a Sam ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Canned command sequences
I have a few reports that when building the Linux 2.5.70 kernel the build system is more noisy than supposed to be. The problem is tracked down to usage of canned command sequences. The following is from the makefiles: #General definition (scripts/Makefile.lib) if_changed_rule = $(if $(strip $? \ $(filter-out $(cmd_$(1)),$(cmd_$@))\ $(filter-out $(cmd_$@),$(cmd_$(1,\ @set -e; \ $(rule_$(1))) #definition of the rule (scripts/Makefile.build) define rule_vcc_o_c $(if $($(quiet)cmd_vcc_o_c),echo ' $($(quiet)cmd_vcc_o_c)';) \ $(cmd_vcc_o_c); \ \ if ! $(OBJDUMP) -h $(@D)/.tmp_$(@F) | grep -q __ksymtab; then \ mv $(@D)/.tmp_$(@F) $@; \ else \ $(CPP) -D__GENKSYMS__ $(c_flags) $< \ | $(GENKSYMS) \ > $(@D)/.tmp_$(@F:.o=.ver); \ \ $(LD) $(LDFLAGS) -r -o $@ $(@D)/.tmp_$(@F)\ -T $(@D)/.tmp_$(@F:.o=.ver); \ rm -f $(@D)/.tmp_$(@F) $(@D)/.tmp_$(@F:.o=.ver); \ fi; \ scripts/fixdep $(depfile) $@ '$(cmd_vcc_o_c)' > $(@D)/.$(@F).tmp; \ rm -f $(depfile); \ mv -f $(@D)/.$(@F).tmp $(@D)/.$(@F).cmd endef #usage of the rule (scripts/Makefile.build) %.o: %.c FORCE $(call if_changed_rule,vcc_o_c) What happens is that the scripts/fixdep command is displayed. In if_changed_rule '@' is used to supress all commands in the canned command sequence - but is fails to do so for the fixdep command. People reporting this has been using debian unstable, with make 3.80-1. I have tried to reproduce this with RH8.0 with make 3.79.1 + 3.80 with no luck. The following makefile exhibit the problem, also at my installation: -- define rule_up echo hello echo hello again endef shut = @set -e;$(rule_$(1)) all: $(call shut,up) Output with make 3.79.1: [EMAIL PROTECTED] tmp]$ make.old --version GNU Make version 3.79.1, by Richard Stallman and Roland McGrath. [EMAIL PROTECTED] tmp]$ make.old hello hello again Output with make 3.80: == [EMAIL PROTECTED] tmp]$ make --version GNU Make 3.80 [EMAIL PROTECTED] tmp]$ make hello echo hello again hello again The culprint is the extra line: "echo hello again" It should not be there. Any explanation and suggested workarounds that are backward compatible? So far my best approach is to avoid launching a new subshell, by continuing the line. Sam ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: problems with directory in make
On Wed, Jun 11, 2003 at 10:36:11AM -0400, Paul D. Smith wrote: > > This would work: > > install: > cd LINUX/mod; mod2=`echo *` Or without launching a shell: install:mod2 := $(patsubst LINUX/%,%,$(wildcard LINUX/*)) $(wildcard LINUX/*) will list all files in the LINUX directory, including the LINUX/ part of the path. $(patsubst LINUX/%,% ...) replaces all occurences of LINUX/ with nothing. The second '%' tell make to take what it matched with '%' in the first part and use that string. So with LINUX/abc.c using "LINUX/%", then % will match abc.c (the stem) and that is the string used. But them we start to use the advanced make features, and in this case the basics are missing. Sam ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: Brahms bug report
On Sat, Jun 14, 2003 at 01:59:46PM +0400, Aleksej Mazunin wrote: > Hello! > I have a problem when trying to make Brahms application. > Logfiles are attached. Could you please attach them as plain text files. Neither gunzip nor bunzip2 understand the format of the .zip file you have attached. Maybe it is obvious from the log-files, but still providing a summary of the problem you see would help finding the cause of the problem. Sam ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: Suffix rule not applied - make says its impossible(sometimes....)
On Wed, Jun 18, 2003 at 03:21:46PM +0100, Alex Hornby wrote: > > I've looked into this a bit more and it is VPATH related. > > If I copy PnL.idl from the source area into the build area then make > thinks the suffix rule is fine. > > Alex. > > > On Thu, 2003-04-03 at 12:40, Alex Hornby wrote: > > > > Did anyone have a look at this? It looks like a make bug to me. > > > > Cheers, > > Alex. Hi Alex. I tried to browse the Makefile, but the presumed GNU make error did not look obvious to me. Could you please try to create a minimal Makefile that shows the error - and post it here with instructions how to reproduce it. The somebody may be able to help you. Sam ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: Canned command sequences
Hi all. Posted the following a few weeks ago - wondered if anyone could explain it. I have stripped down the background info a bit - so the essense is kept. TIA, Sam On Tue, Jun 03, 2003 at 10:50:53PM +0200, Sam Ravnborg wrote: > The following makefile exhibit the problem, also at my installation: > -- > define rule_up > echo hello > echo hello again > endef > > shut = @set -e; $(rule_$(1)) > > all: > $(call shut,up) > > > Output with make 3.79.1: > > [EMAIL PROTECTED] tmp]$ make.old --version > GNU Make version 3.79.1, by Richard Stallman and Roland McGrath. > [EMAIL PROTECTED] tmp]$ make.old > hello > hello again > > Output with make 3.80: > == > [EMAIL PROTECTED] tmp]$ make --version > GNU Make 3.80 > [EMAIL PROTECTED] tmp]$ make > hello > echo hello again <= Extra line only present with make 3.80 > hello again > > The culprint is the extra line: > "echo hello again" > It should not be there. ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: Canned command sequences
On Fri, Jun 20, 2003 at 06:17:45PM -0400, Paul D. Smith wrote: > > Yes, exactly. > > In fact, it was a regression in 3.79.1 which allowed it to "work" there, > and I fixed that bug in 3.80. If you use older versions of GNU make > you'll see they work like 3.80, not 3.79.1. Thanks! Then I apologize that I have attributed this as an make 3.80 error in the kernel changelog :-( Sam ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: make is deleting the c files created during compilation
On Sun, Jun 22, 2003 at 04:15:13PM +0100, J. Grant wrote: > Hello, > > I'm experiencing an odd effect using GNU Make version 3.79.1. > > When the file created during the execution of the makefile is deleted > based on this line "$(BMP2C) $< $(*F) > $@" in the Makefile below. > > Does make have a rule that "deletes all files cat into automated > filenames" on exit or something? I am not calling "rm cd.c" at any > point in the Makefile. Make is deleting intermidiate files - which seems to be the case here. See info make: Implicit Rules | Chained Rules Sam ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: ..:: DREAMCAST PROGRAMMING WITH Dev-C++ : ERROR WITH "MAKE.EXE"::..
On Sun, Jul 20, 2003 at 02:53:32PM +0200, DeZNiUS wrote: > But when i try to compile any program, i have this error : > > Compilator : Dreamcast Profil > Building Makefile: "E:\Documents and Settings\DEZNIUS\Bureau\COOL\Makefile.win" > Finding dependencies for file: E:\Documents and > Settings\DEZNIUS\Bureau\COOL\SansNom1.cpp > Execution of make... > make.exe -f "E:\Documents and Settings\DEZNIUS\Bureau\COOL\Makefile.win" all > sh-sega-dreamcast-g++.exe -c SansNom1.cpp -o SansNom1.o -I"C:/DevKitDc/include" > -I"C:/DevKitDc/include/g++-v3/backward" -I"C:/DevKitDc/include" > make.exe: /bin/sh.exe: Command not found > make.exe: *** [SansNom1.o] Error 127 > Execution Completed > > Can u explain what's the "/bin/sh.exe" error ??? What you see above is make complaining that it cannot find the executable /bin/sh.exe. I suggest you to consult the README file for any dependencies on your system in order to build the application. The above is _not_ an eror in make, but instead make telling you that it cannot find the executable. Sam ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: gmake and embedded PL/SQL block
On Wed, Jul 23, 2003 at 02:52:49PM -0500, Pankratz, Theresa wrote: > I am trying to compile a Pro*C project using gmake. One of the pc files in > the project contains embedded PL/SQL. I have set SQLCHECK=SEMANTICS > USERID=scott/tiger in the mk file. I keep getting errors that look like > gmake is not recognizing that SQLCHECK is set. If I compile the same code > without using gmake, it compiles fine. Hi Theresa. Could you please try to post relevant parts of the makefile, or even better a small Makefile that exhibit the same problem. One thing to check is that the mentioned assignments are not located in a block ifdeffed out. Example: ifeq ($(FOO),1) SQLCHECK=SEMANTICS endif You must look for more than ifeq, but in general such a construct. Sam ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: Output line too long.
On Wed, Jul 23, 2003 at 02:23:04PM +0200, Anton van Oosten wrote: > L.S. > > When building KOffice 1.2.91 (Kpresenter) gmake 3.79 warns:"Output line too > long." Then gmake exits in a way that suggests that some output line was > truncated. I tried to grep the make sources (3.80), and there was no such error message defined in make. I suspect that libtool is the culprint. Try to add "sh -x" or similar to the libtool shell script and see when the error occurs. Sam ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Variable is assigned wrong value
When a variable is followed by a comment the variable is assigned a value containing a space. Sample Makefile: -- var1 := X var2 := X # Comment $(warning var1=-$(var1)-) $(warning var2=-$(var2)-) all: -- Output: $make -v GNU Make 3.80 Copyright (C) 2002 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. $ $make Makefile:4: var1=-X- Makefile:5: var2=-X - make: Nothing to be done for `all'. Note that var2 is assigned a value including a trailing space. Sam ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: Variable is assigned wrong value
On Wed, Jul 30, 2003 at 04:36:20PM -0400, Paul D. Smith wrote: > %% Sam Ravnborg <[EMAIL PROTECTED]> writes: > > sr> When a variable is followed by a comment the variable is assigned > sr> a value containing a space. > > Yes. This is documented in the manual and is exactly how all versions > of make behave. OK. I recalled that make would remove leading and trailing spaces, but was obviously wrong. Thanks, Sam ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: [FEATURE Request] Please add an option to list all dependenciesof a target (recursively)
On Wed, Aug 27, 2003 at 12:12:38AM -0500, 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 > given target to avoid the recursive shell function hackism I > currently have to do when using "make -pnq". Do you think of: `$?' The names of all the prerequisites that are newer than the target, with spaces between them. For prerequisites which are archive members, only the member named is used (*note Archives::). Sam ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: GNU make: Please give an example for the 'if' function (chapter 8 .5 of 'make.html')
On Tue, Sep 23, 2003 at 02:42:36PM +0200, Haeusler Reinhard wrote: > > I wanted to set a variable depending on another variable to different > values. You need to use a few tricks to do this. I have rewritten the code you provided: > VAR2 = $(if ??? $(VAR1), S1, s, $(if ??? $(VAR1), M, m)) # ??? means: don't VAR2 := $(if $(filter S1,$(VAR1)),s) VAR2 := $(if $(filter M, $(VAR1)),m,$(VAR2)) So what happens here: The expression $(filter S1,$(VAR1)) result in 'S1' when VAR1 equals S1. Therefore $(if select the first part, which is s. The second line have $(VAR2) in the else clause to avoid overwriting the previously assigned value. You can use filter-out, filter, patsubst to obtain the same functionality. HTH, Sam ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: Static pattern usage
On Fri, Oct 03, 2003 at 11:01:02PM +0200, Sam Ravnborg wrote: > I'm having troubles using static patters. > See following example: > > deps_foo.o := foo.h > > foo.o : % : $(deps_%) bar.h FORCE > @echo $^ > > FORCE: > > > When executed I expected it to print: > foo.h bar.h FORCE > > But it only prints bar.h FORCE > > Is it coorect behaviour that make does not expand the variable > $(deps_foo.o)? > % is equal to foo.o in the above example, and the varibale is > constructed correct. But it is not expanded. Short question.. Is there any other way to get the name of the target to be used in the prerequisite list? Other make implementation expands $* to the name of the target when listed in the prerequisites, but not gnu make. Sam ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Static pattern usage
I'm having troubles using static patters. See following example: deps_foo.o := foo.h foo.o : % : $(deps_%) bar.h FORCE @echo $^ FORCE: When executed I expected it to print: foo.h bar.h FORCE But it only prints bar.h FORCE Is it coorect behaviour that make does not expand the variable $(deps_foo.o)? % is equal to foo.o in the above example, and the varibale is constructed correct. But it is not expanded. GNU Make 3.80 Copyright (C) 2002 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. Sam ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: Static pattern usage
On Fri, Oct 03, 2003 at 05:26:54PM -0400, Paul D. Smith wrote: > > No make expands $* in the prerequisites list to the name of the target. Hmmm.. foo.o : _$* FORCE echo $^ FORCE: I expected make to print out: make: *** No rule to make target `_foo.o', needed by `foo.o'. Stop. But I got: make: *** No rule to make target `_', needed by `foo.o'. Stop. That seems to me that make does not expand $* to the target. See also the manual: Section: Missing: * In some Unix `make's, the automatic variable `$*' appearing in the prerequisites of a rule has the amazingly strange "feature" of expanding to the full name of the _target of that rule_. We cannot imagine what went on in the minds of Unix `make' developers to do this; it is utterly inconsistent with the normal definition of `$*'. And it does not seem to happen in the above example. > The only way to do what you want is to use the $(eval ...) function to > declare extra dependencies. Something like: > > OBJS = foo.o > deps_foo.o := foo.h > > $(foreach target,$(OBJS),$(eval $(target): $$(deps_$(target Not an option for me - I have to support 3.79.1. Thanks for feedback. Sam ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: Static pattern usage
On Fri, Oct 03, 2003 at 05:18:04PM -0400, Paul D. Smith wrote: > > sr> Is it coorect behaviour that make does not expand the variable > sr> $(deps_foo.o)? > > Yes, because that's not the variable you asked to expand. You asked it > to expand the variable $(deps_%). Got it now, found the right section in the manual. IMMEDIATE :-( I will go back and invent another way to do what I want. Sam ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: Static pattern usage
On Mon, Oct 06, 2003 at 01:53:48PM +0400, Peter A. Kerzum wrote: > I used this trick with rather complex define/eval constructs > It really works but sometimes gives me 'virtual memory exhaused' > If you (Sam) are interested, I can give you precise example. I would be glad to see that - if not for anything else then just to learn one more way to utilise make. TIA, Sam ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: Hi.
On Sat, Oct 18, 2003 at 12:33:48AM -0700, Erkin Borucu wrote: > My name is Erkin. > I have small problem > I m first install this program. > Can you help me ? > > Report bugs to <[EMAIL PROTECTED]>. > [EMAIL PROTECTED] src]# make > g++ -O2 --pipe -I/usr/local/include -c -o > LDAPException.o LDAPException.cpp > make: g++: Command not found > make: *** [LDAPException.o] Error 127 This is not a gnu make problem. What happens here is that make tells you that when trying to execute g++ ... it failed to find the g++ executable. Try the command g++ -O2 --pipe -I/usr/local/include -c -o alone in the shell and you will see the same. You are probarly missing a gcc related package, or your system is misconfigured. HTH, Sam ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: makefile:71: *** Recursive variable `LIBS' references itself (eventually). Stop
On Tue, Oct 28, 2003 at 12:21:49PM +0900, Dominique DEUFF wrote: > > Hello, > > I have to rebuild a project with the makefile I join at the end. > I obtain this error : > makefile:71: *** Recursive variable `LIBS' references itself > (eventually). Stop > > Does anyone know a solution to this ? There are two types of assignments. LIBS= file.a Result in late evaluation. What is to the right of '=' is evaluated only when LIBS is referenced. With late evaluation a variable cannot reference itself - that the problem you see. Late evaluation is required when for example using the following: VAR = $@ What to realise is that the value of $@ differ with the context where the variable is used - therefore late evaluation is required. But most often this is not the case, so I generally prefer the second type of assignment in my makefiles. LIBS:= file.a Result in early evaluation. Here LIBS is immediately assigned the value of file.a. Use this type of assignment and your problem is solved. Sam ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: Mode_perl make test errrors
On Sun, Nov 02, 2003 at 12:46:24PM +, sudhakar Avirneni wrote: > > Server version: Apache/2.0.48 > Server built: Nov 1 2003 05:42:18 Hi Sudhakar. This mailing list is used to report bugs in make itself, not in the build process of Apache or similar tools. What you report looks like a bug in one of the perl scripts, or in the configuration. I will advise you to try some mailing list relevant for the tool you are building. Good luck! Sam ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: Enhancement request regarding make variable names
On Fri, Jan 09, 2004 at 01:41:45PM -0500, Dale R. Worley wrote: > It would be a useful thing if Make variable names were forbidden to > contain slash (`/'), as well as `:', `#', and `='. If you take a look at the linux 2.6 kernel you will see '/' used all over the place in variables. So my vote is definitively 'No'. Currently compiling 2.6.2 kernel located in a directory named "A=B". So far it looks OK. Sam ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: filter-out, very slow?
On Fri, Jan 30, 2004 at 12:34:50PM -0500, Daniel Shane wrote: > For users, that means that instead of > > $(filter-out $(str1), $(str2)) > > it woudl become > > $(filter-out ($sort $(str1)), ($sort $(str2))) That would in some usages have influence on linking order, which will be a disaster to track down. But any speed improvements in filter* functions would be most welcome. During a linux kernel compile 2 or more filter* functions is used for each single target visitited. On top of this a number of filter* functions is used for each Makefile. Yup, it's open source. But not enough time :-( Sam ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: Hi
On Tue, Mar 02, 2004 at 03:58:04PM +0700, Do Manh Hung wrote: > I'm installed Qt right way with threading support, I think so. > (configure -thread then make and make install) > But I can not install kdeverlop on Solaris9 x86 because of error : > configure:27069: error: Qt (>= Qt 3.0) (library qt-mt) not found. Please check your > installation! > For more details about this problem, look at the end of config.log. > Make sure that you have compiled Qt with thread support! What happens is that a check in the configure script is failing for some reasons. This is not a make related problem. Try a Qt related mailing list. Sorry, Sam ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: return codes
On Sun, Mar 07, 2004 at 11:27:38PM +, J. Grant wrote: > Greetings > > Could someone direct me to documentation on the various return codes > make returns please? I could not spot any so far in the man/info pages > or source code. info make Look for the menu "* Invoking make: Running." Sam ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: Using % in a variable name as a static pattern prereq?
On Thu, Mar 11, 2004 at 06:05:24PM -0800, Carl Miller wrote:
>
> $(filter %.a,$(TARGETLIBS)) : %.a : $(%_OBJS)
> $(AR) rc $@ $^
> $(RANLIB) $@
Form 'info make':
Reading Makefiles | How 'make' Reads a makefile
--
Rule Definition
---
A rule is always expanded the same way, regardless of the form:
IMMEDIATE : IMMEDIATE ; DEFERRED
DEFERRED
That is, the target and prerequisite sections are expanded
immediately, and the commands used to construct the target are always
deferred. This general rule is true for explicit rules, pattern rules,
suffix rules, static pattern rules, and simple prerequisite definitions.
--
So you are right in your observation, you cannot use the stem in the way you try to.
In your case you have to do the $(filter ...) twice.
Sam
>
> $(filter %.so,$(TARGETLIBS)) : %.so : $(%_OBJS)
> $(USELD) -shared $(if $(findstring 1,$(LD_USECC)),-Wl$(COMMA))-soname=$@
> $($*_SONAMESUFFIX) $< -o $@
> $(if $(strip $($*_SOFINALNAME)),cp -af $@ $($*_SOFINALNAME),true)
> $(if $(strip $($*_SOFINALNAME)),ln -sf $($*_SOFINALNAME) [EMAIL
> PROTECTED]($*_SONAMESUFFIX),true)
>
>
> This portion of the makefile is shared across many projects. If a project
> wants to build libfoo.a and libfoo.so, for example, its individual makefile
> could then just define:
>
> TARGETLIBS = libfoo.a libfoo.so
> libfoo_OBJS = foo1.o foo2.o foo3.o
> libfoo_SONAMESUFFIX = .0
> libfoo_SOFINALNAME = glibfoo-2.3.2.so
>
> which keeps things nice and simple in the per-project, per-directory
> makefiles. Unfortunately, when I try this, libfoo.a and libfoo.so end
> up with no prerequisites. It appears that the % in the prerequisites
> field of the static pattern is not recognized inside a variable name.
> I suspect it's using $(%_OBJS) with a literal % in the variable name as
> the prerequisites list instead of $(libfoo_OBJS) when that rule gets
> invoked to build libfoo.{a,so}.
>
> Could anyone confirm/deny my suspicion? If it's supposed to work in
> the manner I'm trying to use it, could anyone suggest troubleshooting
> approaches? And if it's performing "as expected" (this being an
> unexpected/unsupported use of %), could this be taken as a feature
> request to make it work as I'm attempting to use it in the next release?
>
> Thanks much!
>
>
>Carl Miller
>
>
> ___
> Bug-make mailing list
> [EMAIL PROTECTED]
> http://mail.gnu.org/mailman/listinfo/bug-make
--
___
Bug-make mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-make
Re: bugs fixed in -bk4
On Sat, Jun 26, 2004 at 04:18:06PM -0500, Boris Kolpackov wrote: > > Another patch, which I think you may be interested in, is > pattern-specific-expansion.patch. Here is the description: > > The following makefile prints 'B' instead of 'A'. > > a := A > > %bar : arg := $a > %bar : ; @echo $(arg) > > a := B > > foobar: > > > The patch adds additional expansion at pattern definition > point for simple variables (i.e. declared with :=). Also > note that you can inhibit this additional expansion if > you want to: > > > %bar : arg := $a $$a > > > With this change the makefile above prints 'A B'. > > >From info make: > Rule Definition --- A rule is always expanded the same way, regardless of the form: IMMEDIATE : IMMEDIATE ; DEFERRED DEFERRED That is, the target and prerequisite sections are expanded immediately, and the commands used to construct the target are always deferred. >>> Given the above information from info make I agree with Boris on this. Both 'a' and 'arg' should be considered IMMEDIATE according to the snippet included. Sam ___ Bug-make mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-make
Re: bugs fixed in -bk4
On Sat, Jun 26, 2004 at 05:17:55PM -0500, Boris Kolpackov wrote: > Sam Ravnborg <[EMAIL PROTECTED]> writes: > > > >From info make: > > >>>>>>>>>>>>>>>>>>>>> > > Rule Definition > > --- > > > >A rule is always expanded the same way, regardless of the form: > > > > IMMEDIATE : IMMEDIATE ; DEFERRED > > DEFERRED > > > >That is, the target and prerequisite sections are expanded > > immediately, and the commands used to construct the target are always > > deferred. > > >>>>>>>>>>>>>>>>>>>>>>> > > > > Given the above information from info make I agree with Boris on this. > > Both 'a' and 'arg' should be considered IMMEDIATE according to the snippet > > included. > > I am glad you agree with me ;-). To be precise, however, I must say that > the snippet you cited does not apply here since it is talking about rule > definition while I was talking about target specific variable definition. > I don't think there is a part in the manual that specifies at what point > target-specific variables get expanded so it is in some sense an > implementation-defined behavior which, I must say, gets very tricky when > it comes to target-specific variable inheritance, +=, etc. I think > immediate evaluation is less surprising, though. Agree with your observations - the above was the best match in info make. But subtle differences has hit me before. Only the other day I realised the difference between: %: and %:: Sam ___ Bug-make mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-make
Re: submake messages not perfect
On Sun, Aug 29, 2004 at 01:44:48AM -0400, Paul D. Smith wrote: > %% Dan Jacobson <[EMAIL PROTECTED]> writes: > > dj> The messages on submakes aren't perfect. > dj> make[1]: Entering directory `/tmp' > dj> make[1]: Leaving directory `/tmp' > dj> You mean "starting submake 1" and especially "ending submake[1]". > > I don't understand your comment. Maybe I did :-) This message appear when you do: make -C some/dir When using recursive make files you almost always uses 'make -C ...' so the original writer get the impression this is something printed only for make invoked from within make. What it tells is that make enter directory 'xxx' and uses normal rule-set to find a Makefile. Pretty clear when know the make machinery. And too many programs are dependent on this message for it to just change wording a bit. > > dj> In fact, if one did > dj> bla: > dj> make a& make b& > dj> then they would both be [1], > > Yes, because both of them are direct submakes of the top-level make. > > If you want to get up to two you have to have a sub-submake (the top > level make invokes a make which invokes another make). > > dj> so maybe even mention PID's. > > I don't see what PIDs have to do with anything. To be able to distingush between two different make instances? It's anyway insane^Wunsafe to have two make's running in parallel in same dir. Sam ___ Bug-make mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-make
