strange dependancy generation bug?
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
On Jun 03 2003, Sam wrote:
...
Quoted 13 lines
But the real question is why you start seeing the invocation of fixdep. I do not see it on my machine.
I asssume that you see fixdep invocation even with "make V=0". This is a bug!Counting this one I have now three independent reports where kbuild displayed the invocation of fixdep.
I have tried to narrow down the root cause.
Both users were running debian unstable.
Different shells.
GNU make 3.80
Quoted 5 lines
I tried to install GNU make 3.80 - but I still do not see the problem. What happens is that within Makefile.build there is used multi line definition, where each new-line causes make to launch a new sub-shell. The command for the second sub-shell is echoed, even though make is told not to do so.
I beg to differ. Since make launches a new subshell, the commands in the second subshell is _not_ told to shut up, and thus is echoed. No?
Stig
Signature · 1 line
brautaset.org
Quoted 7 lines · Stig Brautaset
Quoted 4 lines
What happens is that within Makefile.build there is used multi line definition, where each new-line causes make to launch a new sub-shell. The command for the second sub-shell is echoed, even though make is told not to do so.
I beg to differ. Since make launches a new subshell, the commands in the second subshell is _not_ told to shut up, and thus is echoed. No?
In make a so-called "canned command sequence" is generated. Quote from 'info make':
On the other hand, prefix characters on the command line that refers to a canned sequence apply to every line in the sequence. So the rule:
frob.out: frob.in
@$(frobnicate)
does not echo _any_ commands.
In kbuild this is exactly what happens.
So according to make info the command for the second sub-shell should not be echoed.
Sam
Quoted 18 lines · Sam
Quoted 7 lines · Stig Brautaset
Quoted 4 lines
What happens is that within Makefile.build there is used multi line definition, where each new-line causes make to launch a new sub-shell. The command for the second sub-shell is echoed, even though make is told not to do so.
I beg to differ. Since make launches a new subshell, the commands in the second subshell is _not_ told to shut up, and thus is echoed. No?
In make a so-called "canned command sequence" is generated. Quote from 'info make':
On the other hand, prefix characters on the command line that refers to a canned sequence apply to every line in the sequence. So the rule:
frob.out: frob.in
@$(frobnicate)
Quoted 6 lines
does not echo _any_ commands.
In kbuild this is exactly what happens.
So according to make info the command for the second sub-shell should not be echoed.
Indeed. It seem I haven't read the docs carefully enough. I was just looking at cause and effect -- not how it's _supposed_ to work. ;)
Here, with two subshells, the latter part is echoed, with one it is not. However, in the light of this (to me) new information I'm at a loss as to what causes this to happen.
Stig
Signature · 1 line
brautaset.org
Quoted 8 lines · Sam Ravnborg
In make a so-called "canned command sequence" is generated. Quote from 'info make':
On the other hand, prefix characters on the command line that refers to a canned sequence apply to every line in the sequence. So the rule:
frob.out: frob.in
@$(frobnicate)
(I seriously cannot believe there needs to be a protracted debate about
what's broken and who's at fault -- make or Makefile. What we see is what we get and it's a 5 second fix. Beyond that, it's a problem for the GNU Make maintainers, not lkml.)
Weither make is using 1 shell or 10 doesn't matter. Make is the thing emitting the command to the console as well as feeding the shell. It's a matter of one command or more than one command.
The Kbuild system is rather complex. If you look deep enough, you'll see where the '@' is being applied. What is actually happening looks like this:
define rule_for_act_of_frobnication stuff_that_should_be_one_line \ but_isn't endef frobnicate = @set -e; \ $(rule_for_act_of_frobnication); frob.out: frob.in $(call frobnicate)
There's a big difference in @$(call frobnicate) and $(call frobnicate). Both ultimately resovle to two line of text. In the first case, all of it hidden. In the second, only the lines explicitly hidden will be hidden.
Make isn't broken. Makefile.build is. To me, this was immediately obvious and confirmed after a few seconds searching for the "@". (It looks like someone hit [enter] where they shouldn't have.)
--Ricky