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

[Sergio Durigan Junior <sergiodj at redhat dot com>]

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
http://sergiodj.net/