From: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
To: Jan Beulich <JBeulich@suse.com>
Cc: a.p.zijlstra@chello.nl, mingo@elte.hu, paulus@samba.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] perf: adjust make rules
Date: Thu, 15 Mar 2012 14:28:30 -0300 [thread overview]
Message-ID: <20120315172830.GF9528@infradead.org> (raw)
In-Reply-To: <4F61EB380200007800078A79@nat28.tlf.novell.com>
Em Thu, Mar 15, 2012 at 12:14:32PM +0000, Jan Beulich escreveu:
> >>> On 14.03.12 at 20:17, Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
> wrote:
> > Em Thu, Mar 08, 2012 at 09:29:28AM +0000, Jan Beulich escreveu:
> >> Add rules to generate pre-processed files (just like are available for
> >> the normal kernel build), and adjust the rule to create assembly files
> >> from C ones to produce its output in the output directory rather than
> >> in the source tree.
> >>
> >> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> >
> > I'm trying to use it but hit this:
> >
> > [acme@sandy linux]$ make -C tools/perf/ O=/home/git/build/perf
> > /home/git/build/perf/perf.s
> > make: Entering directory `/home/git/linux/tools/perf'
> > CC /home/git/build/perf/perf.s
> > perf.c: In function ‘handle_options’:
> > perf.c:111: error: ‘PERF_HTML_PATH’ undeclared (first use in this function)
> > perf.c:111: error: (Each undeclared identifier is reported only once
> > perf.c:111: error: for each function it appears in.)
> > perf.c: At top level:
> > perf.c:238: error: ‘PERF_VERSION’ undeclared here (not in a function)
> > make: *** [/home/git/build/perf/perf.s] Error 1
> > make: Leaving directory `/home/git/linux/tools/perf'
> > [acme@sandy linux]
> >
> > Do I have to go to tools/perf and do it from there, trying...
>
> No. perf.c just is a bad example - perf.o has a special make rule,
> and hence the pattern rule for perf.s fails because the symbols
> defined for perf.o don't get also defined for perf.s. Those special
> rules look pretty strange anyway - as long as using GNU make is a
> requirement, they could be re-written to use the pattern rule, and
> then would be much easier to extend to cover .i and .s generation
> as well.
Feel free to provide patches if you have the time to improve this
situation.
IIRC these things came from the git sources, having them closer to the
kernel Makefile practices would be good.
> Using the rules added in this patch works fine for me for any of the
> source files that don't have custom .o rules (which is what I needed
> when I came up with this patch).
Ok, I just tried it with another target and it worked. Applying.
> Jan
>
> > [acme@sandy perf]$ make O=/home/git/build/perf /home/git/build/perf/perf.s
> > CC /home/git/build/perf/perf.s
> > perf.c: In function ‘handle_options’:
> > perf.c:111: error: ‘PERF_HTML_PATH’ undeclared (first use in this function)
> > perf.c:111: error: (Each undeclared identifier is reported only once
> > perf.c:111: error: for each function it appears in.)
> > perf.c: At top level:
> > perf.c:238: error: ‘PERF_VERSION’ undeclared here (not in a function)
> > make: *** [/home/git/build/perf/perf.s] Error 1
> > [acme@sandy perf]$ make O=/home/git/build/perf perf.s
> > make: *** No rule to make target `perf.s'. Stop.
> > [acme@sandy perf]$
> >
> > Same result, what am I doing wrong?
> >
> > - Arnaldo
> >
> >> ---
> >> tools/perf/Makefile | 6 +++++-
> >> 1 file changed, 5 insertions(+), 1 deletion(-)
> >>
> >> --- 3.3-rc6/tools/perf/Makefile
> >> +++ 3.3-rc6-perf-make-rules/tools/perf/Makefile
> >> @@ -706,10 +706,14 @@ $(OUTPUT)perf.o perf.spec \
> >>
> >> $(OUTPUT)%.o: %.c $(OUTPUT)PERF-CFLAGS
> >> $(QUIET_CC)$(CC) -o $@ -c $(ALL_CFLAGS) $<
> >> +$(OUTPUT)%.i: %.c $(OUTPUT)PERF-CFLAGS
> >> + $(QUIET_CC)$(CC) -o $@ -E $(ALL_CFLAGS) $<
> >> $(OUTPUT)%.s: %.c $(OUTPUT)PERF-CFLAGS
> >> - $(QUIET_CC)$(CC) -S $(ALL_CFLAGS) $<
> >> + $(QUIET_CC)$(CC) -o $@ -S $(ALL_CFLAGS) $<
> >> $(OUTPUT)%.o: %.S
> >> $(QUIET_CC)$(CC) -o $@ -c $(ALL_CFLAGS) $<
> >> +$(OUTPUT)%.s: %.S
> >> + $(QUIET_CC)$(CC) -o $@ -E $(ALL_CFLAGS) $<
> >>
> >> $(OUTPUT)util/exec_cmd.o: util/exec_cmd.c $(OUTPUT)PERF-CFLAGS
> >> $(QUIET_CC)$(CC) -o $@ -c $(ALL_CFLAGS) \
> >>
> >>
>
next prev parent reply other threads:[~2012-03-15 17:28 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-08 9:29 [PATCH] perf: adjust make rules Jan Beulich
2012-03-14 19:17 ` Arnaldo Carvalho de Melo
2012-03-15 12:14 ` Jan Beulich
2012-03-15 17:28 ` Arnaldo Carvalho de Melo [this message]
2012-03-19 19:55 ` [tip:perf/core] perf tools: Adjust " tip-bot for Jan Beulich
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120315172830.GF9528@infradead.org \
--to=acme@ghostprotocols.net \
--cc=JBeulich@suse.com \
--cc=a.p.zijlstra@chello.nl \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=paulus@samba.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox