On Tue, 2010-08-03 at 13:24 +0100, Ian Campbell wrote:
> Thanks for looking over this.
> On Tue, 2010-08-03 at 13:07 +0100, Gianni Tedesco (3P) wrote:
> > On Tue, 2010-08-03 at 12:00 +0100, Ian Campbell wrote:
> > > LIBXL_OBJS-y = osdeps.o libxl_paths.o libxl_bootloader.o
> > > LIBXL_OBJS = flexarray.o libxl.o libxl_pci.o libxl_dom.o libxl_exec.o
> > > libxl_xshelp.o libxl_device.o libxl_internal.o xenguest.o libxl_utils.o
> > > $(LIBXL_OBJS-y)
> > > +LIBXL_OBJS += _libxl_types.c
> > uhm... _libxl_types.o ??
> Oops, yes indeed.
> > > AUTOINCS= libxlu_cfg_y.h libxlu_cfg_l.h
> > > AUTOSRCS= libxlu_cfg_y.c libxlu_cfg_l.c
> > > @@ -54,9 +55,10 @@ libxl_paths.c: _libxl_paths.h
> > >
> > > libxl.h: _libxl_types.h
> > >
> > > -_libxl_types.h: gentypes.py libxltypes.py
> > > - python gentypes.py __libxl_types.h
> > > +_libxl_types.h _libxl_types.c: gentypes.py libxltypes.py
> > > + python gentypes.py __libxl_types.h __libxl_types.c
> > > mv __libxl_types.h _libxl_types.h
> > > + mv __libxl_types.c _libxl_types.c
> > Something is still wrong in the dep tree that breaks a clean build. I
> > think part of the problem is that the build system cannot find what
> > depends on _libxl_types.h until the compile-time-generate dep files are
> > created. On the other hand, it can't create the dep files if the
> > _libxl_types.h is not there.
> > Solution is to manually tweak the dep tree, meh:
> I thought that the next patch in the series (which adds _libxl_types.c)
> also worked around the same problem so I didn't worry too much but I
> seem to have been mistaken.
> I wonder if this can be wildcarded at all, something like
> %.o: _libl_types.h
> (except not that because it doesn't actually work, AFAICT)
Hmm, probably conflicts with higher level Rules.mak thing. Not to
mention it may interact badly with $</$^ type of rules. Think my %.so
template is a lucky hack tbh. But as long as the dep is added at the
top-level (tho not topmost 'all' target level, due to parallelism) it
should be fine.
Xen-devel mailing list