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

[Pedro Alves <palves at redhat dot com>]

On 05/10/2015 08:01 PM, Sergio Durigan Junior wrote:
> 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.
> 

Agreed.

Thanks,
Pedro Alves