qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] build: Use separate makefile for "trace/"


From: Lluís Vilanova
Subject: Re: [Qemu-devel] [PATCH] build: Use separate makefile for "trace/"
Date: Thu, 13 Dec 2012 15:38:22 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)

Paolo Bonzini writes:
[...]
>>>> -
>>>> -$(trace-obj-y): $(GENERATED_HEADERS)
>>>> +trace-obj-y += trace/
>> 
>>> Please just put it into oslib-obj-y.
>> 
>> You mean line "trace-obj-y += trace/"?

> Yeah, make it

> oslib-obj-y += trace/

> and get rid of trace-obj-y.

Mmm, but according to Makefile.objs:

  oslib-obj-y is code depending on the OS (win32 vs posix)


[...]
>> "trace-obj-y" is required by some binaries other than QEMU itself, as they 
>> use
>> routines that require the tracing infrastructure (e.g., qemu-img, which only
>> includes "qemu-timer-common.o" as a dependency through "tools-obj-y").

> Yes, but they all use oslib-obj-y too.  qemu-timer-common.o is part of
> oslib-obj-y.

Removed. Still, see above.


>> I'm not sure how the subdir magic treats paths, but mapping all paths in 
>> final
>> vars into their respective absolute path should simplify things.

> Difficult to do in make. :(

Among many other things, AFAIR the linux kernel build system uses absolute
paths, but I think it also uses make to get into each subdirectory (as opposed
to QEMU), which I simplifies coding such a build system.


>> In any case, compiling with backends none, stderr, and stdout turns up no
>> linking problems.

> And simple too?  (I suppose stdout is a typo for simple).

Yes, sorry.


>>>> +ifeq ($(TRACE_BACKEND),dtrace)
>>>> +TRACE_H_EXTRA_DEPS=trace/generated-dtrace.h
>>>> +endif
>>>> +trace.h: trace.h-timestamp $(TRACE_H_EXTRA_DEPS)
>>>> +trace.h-timestamp: $(SRC_PATH)/trace-events $(BUILD_DIR)/config-host.mak
>>>> +  $(call quiet-command,$(TRACETOOL) \
>>>> +          --format=h \
>>>> +          --backend=$(TRACE_BACKEND) \
>>>> +          < $< > $@,"  GEN   trace.h")
>>>> +  @cmp -s $@ trace.h || cp $@ trace.h
>>>> +
>>>> +
>>>> +trace/generated.c: trace/generated.c-timestamp
>> 
>>> Please use $(obj)/generated.c, and similarly for everything else.
>> 
>> Tried it, but "obj" is set to ".", although looking at "rules.mak" that 
>> should
>> not be the case...
>> 
>> Inserting "$(error obj=$(obj))" in "trace/Makefile.objs" shows "./trace", but
>> echoing "obj" in any of the rules shows ".".

> In the rules it is, because the rules expand variables later when the
> command runs.  But in the targets it should be evaluated correctly,
> because the targets expand variables earlier when they are read.  As
> long as you use $@ and $< and $^ in the rules, you're safe.  Anyway,
> this can be done later.

Ok, done. But this behaviour easily leads to errors. It might be safer to switch
into a per-directory call to $(MAKE), although this would for sure be a
completely different patch.


>> BTW, can I extend the GENERATED_HEADERS variable contents right from
>> "trace/Makefile.objs" even though it's not explicitly included from the
>> top-level makefile?

> Hmm, risky. :)  Need to look at the actual patch, let's do one thing at
> a time.

For now I'll leave it just as it is.


>> I'm sure this has already been previously discussed to the point of 
>> extenuation,
>> but what are the reasons for not using autotools?

> Autoconf -> no point, but someone needs to do the work.

> Automake -> the build system is just too different.

> Libtool -> using it already. :)


Ok, so it's not something against the suite per-se, but about porting work.

The thing I like about automake is that it provides a clear set of vars to
manage the per-dir builds, thanks to using a per-dir $(MAKE); but I'm not sure
how the per-target build would be managed (except by having a separate
configure+make for each of them).

This could also be provided by having the QEMU build infrastructure use $(MAKE)
to enter into each directory, and having it produce an ar file (or a set of 
them)
with a "standard" name as a result (using libtool).

But I'm not sure how well would that work when building in Windows (is libtool
available there?).


Thanks,
  Lluis

-- 
 "And it's much the same thing with knowledge, for whenever you learn
 something new, the whole world becomes that much richer."
 -- The Princess of Pure Reason, as told by Norton Juster in The Phantom
 Tollbooth



reply via email to

[Prev in Thread] Current Thread [Next in Thread]