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

[Paolo Bonzini]

> > 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)

True... I'd like to simplify this jungle sooner or later though.

We can keep trace-obj-y, but please do leave out qemu-timer-common.o

> > > 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.

We already use recursive make to compile each target.  I think the current QEMU
build system is a good balance between non-recursive and recursive make.

> > 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).

Yes, that would be it.  Even an autoconf conversion probably would have
to use separate configure scripts for the global project and for each
target.

> 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).

Doesn't need to use libtool.  Static libraries are just fine.  The problem
is that ar doesn't work well with constructors, which we use for module.c.
It is what QEMU used to use, but Andreas moved away a couple of years ago
and I think it is an improvement.

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

Yes.

Paolo