Building in a tree with read-only source files failed because the flex/ bison generated files are left in place. All of the source files (instead of all of the object files) were depending on libxl.h (in particular forcing the needless re-generation of the flex/bison generated files). For _libxl_types.[ch] a single non-pattern rule was used. For non- pattern rules with multiple targets, other than for pattern ones, the body gets executed once for each target, causing problems when building with -j<n>, <n> >= 2. Convert this rule to a pattern one. The flex/bison generated headers pointlessly depended on the corresponding source files. Use multiple-target pattern rules instead. It would also have been nice if the minimal flex/bison versions needed to successfully build libxl were documented: neither flex 2.5.31 nor bison 2.1 (as found e.g. on SLE10) is sufficient. Signed-off-by: Jan Beulich <jbeulich@novell.com> --- 2010-09-20.orig/tools/libxl/Makefile 2010-09-20 14:23:28.000000000 +0200 +++ 2010-09-20/tools/libxl/Makefile 2010-09-20 14:24:20.000000000 +0200 @@ -42,18 +42,15 @@ XL_OBJS = xl.o xl_cmdimpl.o xl_cmdtable. all: $(CLIENTS) libxenlight.so libxenlight.a libxlutil.so libxlutil.a \ $(AUTOSRCS) $(AUTOINCS) -$(AUTOINCS): $(AUTOSRCS) - -#%_y.h: %_y.c -#%_l.h: %_l.c - $(LIBXLU_OBJS): $(AUTOINCS) -%.c: %.y - $(BISON) --output=$@ $< - -%.c: %.l - $(FLEX) --header-file=$*.h --outfile=$@ $< +%.c %.h: %.y + @rm -f $*.[ch] + $(BISON) --output=$*.c $< + +%.c %.h: %.l + @rm -f $*.[ch] + $(FLEX) --header-file=$*.h --outfile=$*.c $< genpath-target = $(call buildmakevars2file,_libxl_paths.h) $(eval $(genpath-target)) @@ -66,12 +63,12 @@ libxl_paths.c: _libxl_paths.h libxl.h: _libxl_types.h -$(LIBXL_OBJS:%.o=%.c) $(LIBXLU_OBJS:%.o=%.c) $(XL_OBJS:%.o=%.c): libxl.h +$(LIBXL_OBJS) $(LIBXLU_OBJS) $(XL_OBJS): libxl.h -_libxl_types.h _libxl_types.c: libxl.idl gentypes.py libxltypes.py - $(PYTHON) gentypes.py libxl.idl __libxl_types.h __libxl_types.c - mv __libxl_types.h _libxl_types.h - mv __libxl_types.c _libxl_types.c +_libxl_%.h _libxl_%.c: libxl.idl gen%.py libxl%.py + $(PYTHON) gen$*.py libxl.idl __libxl_$*.h __libxl_$*.c + mv __libxl_$*.h _libxl_$*.h + mv __libxl_$*.c _libxl_$*.c libxenlight.so: libxenlight.so.$(MAJOR) ln -sf $< $@ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Mon, Sep 20, 2010 at 02:33:24PM +0100, Jan Beulich wrote:> Building in a tree with read-only source files failed because the flex/ > bison generated files are left in place. > > All of the source files (instead of all of the object files) were > depending on libxl.h (in particular forcing the needless re-generation > of the flex/bison generated files). > > For _libxl_types.[ch] a single non-pattern rule was used. For non- > pattern rules with multiple targets, other than for pattern ones, the > body gets executed once for each target, causing problems when building > with -j<n>, <n> >= 2. Convert this rule to a pattern one. > > The flex/bison generated headers pointlessly depended on the > corresponding source files. Use multiple-target pattern rules instead. > > It would also have been nice if the minimal flex/bison versions needed > to successfully build libxl were documented: neither flex 2.5.31 nor > bison 2.1 (as found e.g. on SLE10) is sufficient. >There''s a note about this on the Xen4.0 wiki page ("release notes"), but it could be made more clear, stating the actual versions etc. So what is actually the required version of flex? Should this be written also to some file in the xen source tree? -- Pasi _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>>> On 20.09.10 at 15:38, Pasi Kärkkäinen<pasik@iki.fi> wrote: > On Mon, Sep 20, 2010 at 02:33:24PM +0100, Jan Beulich wrote: >> It would also have been nice if the minimal flex/bison versions needed >> to successfully build libxl were documented: neither flex 2.5.31 nor >> bison 2.1 (as found e.g. on SLE10) is sufficient. >> > > There''s a note about this on the Xen4.0 wiki page ("release notes"), > but it could be made more clear, stating the actual versions etc. > > So what is actually the required version of flex?On top of what I wrote already, I can only state that (surprise, surprise) current upstream works.> Should this be written also to some file in the xen source tree?Yes, this is what I was after. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 20/09/2010 14:44, "Jan Beulich" <JBeulich@novell.com> wrote:>> There''s a note about this on the Xen4.0 wiki page ("release notes"), >> but it could be made more clear, stating the actual versions etc. >> >> So what is actually the required version of flex? > > On top of what I wrote already, I can only state that (surprise, > surprise) current upstream works. > >> Should this be written also to some file in the xen source tree? > > Yes, this is what I was after.Even nicer if the OA would modify the flex input to not need whatever new feature it currently uses. Seems the world has managed to struggle along okay without that feature for a good long time. Then we wouldn''t need the generated output checked into the tree either. -- Keir> Jan > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jan Beulich writes ("[Xen-devel] [PATCH] fix libxl build
issues"):> The flex/bison generated headers pointlessly depended on the
> corresponding source files. Use multiple-target pattern rules instead.
Your Makefile changes look sensible. I''ll test them.
> It would also have been nice if the minimal flex/bison versions needed
> to successfully build libxl were documented: neither flex 2.5.31 nor
> bison 2.1 (as found e.g. on SLE10) is sufficient.
I have no idea why SLE10 is using a version of flex which is
SEVEN YEARS OLD.
We haven''t used features of flex and bison gratuitously. The features
we have used are those which are necessary to produce lexers and
parsers which are 1. reentrant and 2. do not pollute the namespace of
the resulting library. I think that it''s quite reasonable to say that
if you want to modify the parser/lexer you need tools which are less
than five years old, say.
That if you don''t it doesn''t build properly even with the
existing
files is a bug.
I do know that the versions of bison and flex in Debian stable are
good enough: that''s bison 2.3 (June 2006) and flex 2.5.35 (August
2008). It is very likely that substantially earlier versions will
work. If someone wants to do a systematic test they are very welcome
to document the results but for now how about "not ancient" ?
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel