This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH v3 00/17] Catch syscall group
- From: Pedro Alves <palves at redhat dot com>
- To: Sergio Durigan Junior <sergiodj at redhat dot com>, Gabriel Krisman Bertazi <gabriel at krisman dot be>
- Cc: gdb-patches at sourceware dot org, dje at google dot com
- Date: Mon, 11 May 2015 12:38:53 +0100
- Subject: Re: [PATCH v3 00/17] Catch syscall group
- Authentication-results: sourceware.org; auth=none
- References: <1430011521-24340-1-git-send-email-gabriel at krisman dot be> <553F6BC0 dot 9000905 at redhat dot com> <87r3r42e0v dot fsf at redhat dot com> <5540ABF8 dot 4000404 at redhat dot com> <87k2wpt6k6 dot fsf at krisman dot be> <554A275C dot 80204 at redhat dot com> <87r3qoi8n6 dot fsf at krisman dot be> <87wq0gtfxu dot fsf 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