Re: [PATCH v4 0/4] catch syscall group

Sergio Durigan Junior
2015-05-12T22:02:38Z

On Tuesday, May 12 2015, Doug Evans wrote:

> > Also, this patch series *does not* include the generated files because
> > they are too big and can get in the way of code review. Reviewers must
> > generate those files by hand by entering the gdb/syscalls directory and
> > running the makefile there. Build will fail if reviewer don't do this!
> > Once we get this approved, I'll make sure to include the generated files
> > in the commit before pushing. Hopefully this will make code review
> > easier.
>
> This sounds like something we should key off of --enable-maintainer-mode.
> [we *could* use a different option if people are wedded to
> --enable-maintainer-mode affecting only autogen files, but
> that seems like overkill]

What exactly are you refering to? Generating the XML files using
xsltproc when compiling GDB? I will assume this in the rest of the
message, but if that's not what you meant, then please disconsider.

> IIRC we don't do that for, e.g., gdbarch.sh -> gdbarch.[ch], but
> that's a mistake IMO. Let's get it right here.

Sorry, but what is the point of regenerating files that do not change
every time we compile GDB? I fail to see that.

> It will mean that configuring with --enable-maintainer-mode
> will now require xsltproc, but that's the price of going down
> this path, let's not hide it.
> [maybe that's a good reason to use something other than
> --enable-maintainer-mode, but
> 1) how often do people configure with --enable-maintainer-mode, and
> 2) maintainers are expected to know and accept these dependencies]

They will know and accept the dependencies if they really need to
regenerate the files, of course. Other than that, I still don't see any
practical reason to impose this on anyone who is compiling GDB, whether
this person is a GDB developer or not.

I don't necessarily oppose hooking the XML generation into the
--enable-maintainer-mode option, but I'm having the impression that we
are bloating this feature more and more, without much gain. Unless I'm
really blind to some benefit, in which case I apologize in advance.

Thanks,

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