I see vpath seems to have become broken in 2.5.41 build.
How now can I build the oprofile.o target from two directories ?
Namely,
arch/i386/oprofile/Makefile:
vpath %.c = . $(TOPDIR)/drivers/oprofile
obj-$(CONFIG_OPROFILE) += oprofile.o
DRIVER_OBJS = \
oprof.o cpu_buffer.o buffer_sync.o \
event_buffer.o oprofile_files.o \
oprofilefs.o oprofile_stats.o
oprofile-objs := $(DRIVER_OBJS) init.o timer_int.o
ifdef CONFIG_X86_LOCAL_APIC
oprofile-objs += nmi_int.o op_model_athlon.o op_model_ppro.o
endif
include $(TOPDIR)/Rules.make
with the DRIVER_OBJS sources in drivers/oprofile/
Since this was intentional, I assume I have to move my arch-dependent
parts back into drivers/ Kai ?
thanks
john
--
"I will eat a rubber tire to the music of The Flight of the Bumblebee"
On Tue, 8 Oct 2002, John Levon wrote:
> I see vpath seems to have become broken in 2.5.41 build.
>
> How now can I build the oprofile.o target from two directories ?
I see in the patch you mailed later that you got it figured out already,
using a relative path.
And yeah, it's not particularly beautiful. But I do not see any nice and
easy way, either. What would help a lot, of course, would be to split this
into two modules, one generic one, one arch-specific one. Have you
considered doing that?
--Kai
On Mon, Oct 07, 2002 at 08:39:46PM -0500, Kai Germaschewski wrote:
> > How now can I build the oprofile.o target from two directories ?
>
> I see in the patch you mailed later that you got it figured out already,
> using a relative path.
> And yeah, it's not particularly beautiful. But I do not see any nice and
> easy way, either.
OK. If you say that the vpath support is troublesome, I will believe
you :)
> What would help a lot, of course, would be to split this
> into two modules, one generic one, one arch-specific one. Have you
> considered doing that?
I think I said to you before that implementing a runtime solution to a
build time problem is a little bizarre IMHO. I would *much* rather have
4 lines of slightly icky Makefile than complicate *any* runtime code.
I suppose it would not be much more complicated than a request_module()
inside oprofile_init(), but it's still more code for next-to-zero
benefit ...
regards
john
--
"I will eat a rubber tire to the music of The Flight of the Bumblebee"
On Mon, 7 Oct 2002 20:39:46 -0500 (CDT),
Kai Germaschewski <[email protected]> wrote:
>On Tue, 8 Oct 2002, John Levon wrote:
>> I see vpath seems to have become broken in 2.5.41 build.
>> How now can I build the oprofile.o target from two directories ?
>
>I see in the patch you mailed later that you got it figured out already,
>using a relative path.
>And yeah, it's not particularly beautiful. But I do not see any nice and
>easy way, either.
This is one of the problems that kbuild 2.5 was designed to handle, to
cope with modules built from code in multiple directories. I support
what the developer wants to do, not restrict the developer to what the
kernel build can handle.
Pity that Linus thinks that there are no kbuild problems that require
kbuild 2.5 ...
On Tue, 8 Oct 2002, Keith Owens wrote:
> >On Tue, 8 Oct 2002, John Levon wrote:
> >> I see vpath seems to have become broken in 2.5.41 build.
> >> How now can I build the oprofile.o target from two directories ?
>
> This is one of the problems that kbuild 2.5 was designed to handle, to
> cope with modules built from code in multiple directories. I support
> what the developer wants to do, not restrict the developer to what the
> kernel build can handle.
So would you mind telling me what arch/i386/drivers/Makefile.in would
look like for a module which is built from sources in arch/i386/drivers
and drivers/oprofile ?
(And no, I won't get into another general kbuild-2.5 flamewar, just in
case this should start one again).
--Kai
On Tue, 8 Oct 2002 09:35:56 -0500 (CDT),
Kai Germaschewski <[email protected]> wrote:
>On Tue, 8 Oct 2002, Keith Owens wrote:
>> This is one of the problems that kbuild 2.5 was designed to handle, to
>> cope with modules built from code in multiple directories. I support
>> what the developer wants to do, not restrict the developer to what the
>> kernel build can handle.
>
>So would you mind telling me what arch/i386/drivers/Makefile.in would
>look like for a module which is built from sources in arch/i386/drivers
>and drivers/oprofile ?
Do you really expect me to help you sort out the mess you have made of
kernel build? So you can pick more ideas and bug fixes from kbuild 2.5
and claim the credit for them? Forget it!