Re: [PATCH v3 00/17] Catch syscall group

[Sergio Durigan Junior <sergiodj@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 1715 bytes --]

On Sunday, May 10 2015, Gabriel Krisman Bertazi wrote:

> I noticed that the GDB build step currently doesn't depend on xsltproc.
> It is used only in gdb/features/Makefile to generate some .dat files,
> that are also included in the repository at gdb/regformat.  Am I right?

Yes.  This is a common practice inside GDB.

> At first, I intended to use xsltproc as a build step and only provide
> the *.xml.in files in the repository.  But that would have the side
> effect of forcing xsltproc to be available at build time, and I don't
> know if is acceptable.

I don't see any reason to make GDB depend on xsltproc.  You are
basically doing all this work because it makes things easier to
maintain, but there is no reason to force the user to install a XSLT
processor.

> Other possibility would be to also push the generated files to the
> repository.  We'd keep them in gdb/syscalls/generated/, or something
> like that, and have a script to update the xmls when needed.

There is no reason to regenerate the XML files every time we build GDB,
because they would be the same every time, unless someone makes a
modification on the .in files.  The same applies, for example, to
configure.ac or gdbarch.sh.

This is the modus operandi here: put the generated files in the tree,
along with the templates.  I am against creating a "generated/"
directory inside gdb/syscalls/.  Just put the template files (*.in) in
the gdb/syscalls/ dir, and that's all.  Don't forget to include a README
with instructions on how to regenerate the XML files.

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/

[-- Attachment #2: Type: application/pgp-signature, Size: 818 bytes --]