WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [PATCH 7 of 8] libxl: generate destructors for each libx

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

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.

Gianni


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>