On Sat, Oct 17, 2015 at 1:59 AM, Simon Marchi <[email protected]> wrote: > On 16 October 2015 at 15:53, Jérémie Galarneau > <[email protected]> wrote: >> Hi Nathan, >> >> This should be fixed as of: >> >> commit d620c28807ba2f9d0b97582384915f6a452a3375 >> Author: Jérémie Galarneau <[email protected]> >> Date: Fri Oct 16 15:31:28 2015 -0400 >> >> Fix: missing includes break the out-of-tree build >> >> Addresses out-of-tree build breakage introduced by >> commit 3842465694945829d76452ff83924aa0103c6293 >> >> Reported-by: Nathan Lynch <[email protected]> >> Signed-off-by: Jérémie Galarneau <[email protected]> >> >> Thanks for reporting! >> Jérémie > > Hi Sir Galarneau, > > I have been investigating a build failure of the babeltrace code on > Launchpad, and the following change caught my attention: > > -libctf_parser_la_CFLAGS = $(AM_CFLAGS) -include ctf-scanner-symbols.h > +libctf_parser_la_CFLAGS = $(AM_CFLAGS) > > Is it possible that it was wrongfully included in the aforementioned > changeset? It is part of the formats/ctf/metadata/Makefile.am file > artifact. Removing it causes the bt_yy_* symbols to go back to yy_* (I > don't think that was the intention). >
My very dear Simon, That is a very just and astute observation. I'll make sure this part of the change is duly reverted and a comment added to explain the purpose of this explicit include directive. > Also, I'll take this opportunity to discuss another part of the > changeset: At a few places, it is possible to use > > -I$(srcdir) instead of -I$(top_srcdir)/formats/ctf/metadata > > and > > -I$(builddir) instead of -I$(top_builddir)/formats/ctf/metadata > > This allows one to have less hardcoded path in their build description > file. If top_srcdir and top_builddir were willfully chosen, then > please ignore this comment. > As for the rest of the changes, I propose this patch on top of master [1]. It's the only way I can get the out of tree build to work. Shall the aforementioned fix not be to your utmost satisfaction, I'll gladly accept an alternative solution as I may have failed to address the problem in the most efficient way. All the very best, Sir Galarneau [1] https://gist.githubusercontent.com/jgalar/6a8e8404e507db37fc2c/raw/1e66f1fbf1155f5867862bee2e9574c5d303a8f6/gistfile1.txt > Best Regards, > > Simon Marchi -- Jérémie Galarneau EfficiOS Inc. http://www.efficios.com _______________________________________________ lttng-dev mailing list [email protected] http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
