Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
* Re: [PATCH v4 4/5] Include group information in xml syscall files.
@ 2015-05-16  0:33 Doug Evans
  0 siblings, 0 replies; 5+ messages in thread
From: Doug Evans @ 2015-05-16  0:33 UTC (permalink / raw)
  To: Gabriel Krisman Bertazi; +Cc: Sergio Durigan Junior, Pedro Alves, gdb-patches

Gabriel Krisman Bertazi writes:
  > Doug Evans <dje@google.com> writes:
  >
  > > I would have expected syscalls/Makefile.in,
  > > with requisite changes to generate Makefile in some configure.ac file.
  >
  > Hi Doug,
  >
  > I saw your other message and I'll surely answer and apply your
  > suggestions as soon as I can, but let me make a quick question and
  > comment on my design here :)
  >
  > I tried to follow the exact same design we have in gdb/Features.  There,
  > we only have a Makefile that doesn't depend on the configure script.  If
  > I understand correctly, all it takes to generate the files is a simple
  > 'make blah'.  I tried to reproduce this behavior here.

Ugh.  I see.
Well I guess I can't ask for more here.

Note that all I'm asking for (effectively) is that
your Makefile get renamed as Makefile.in,
and that the real Makefile get created at build time
in the build directory along with the other makefiles.
That does mean that the makefile has to cope with
being in the buildir and not srcdir, but that's doable.

All the --enable-maintainer-mode switch does is turn
on dependencies so that all I have to do is edit
one of those source files and then the normal make
will DTRT to regenerate the files and then
continue with the rest of the build.
IOW, with maintainer mode turned on there is no
extra separate manual step to regenerate the files.

  > Even though I understand the obvious benefits of using the configure
  > script, is there any actual differences between the expected behavior in
  > gdb/Features/Makefile that justifies it being a simple Makefile?  If
  > not, I'll probably work on a follow-up patch adjusting it, as well.

The benefit is that the build continues to Just Work,
even when modifying these files (whereas otherwise one might not notice
that these source files are special and have to spend time figuring
out why one can't just edit the file and type "make").

Obviously, we don't, necessarily, want to impose on everyone
building from trunk to require the additional dependencies
(e.g., xsltproc), and thus the configure switch.

btw,
I can imagine keying this off of --enable-maintainer-mode
could annoy someone who mostly works with binutils
but still builds gdb. I'd be happy with --enable-gdb-maintainer-mode.
I'd say no need to change to use it now, and we can switch to
using the configure switch later.
But the more we wait the more inertia we have to overcome.

  > Btw, can any of you guys provide me with more information about the
  > maintainers mode?  I couldn't find many explanations in the Internals
  > wiki.  I can update the wiki once I have a better understanding of
  > it.

I doubt there is more documentation than this:

http://www.gnu.org/software/automake/manual/html_node/maintainer_002dmode.html#maintainer_002dmode


^ permalink raw reply	[flat|nested] 5+ messages in thread
* Re: [PATCH v3 00/17] Catch syscall group
@ 2015-05-10 19:01 Sergio Durigan Junior
  2015-05-11  0:28 ` [PATCH v4 0/4] catch " Gabriel Krisman Bertazi
  0 siblings, 1 reply; 5+ messages in thread
From: Sergio Durigan Junior @ 2015-05-10 19:01 UTC (permalink / raw)
  To: Gabriel Krisman Bertazi; +Cc: Pedro Alves, gdb-patches, dje

[-- 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 --]

^ permalink raw reply	[flat|nested] 5+ messages in thread
end of thread, other threads:[~2015-05-16  0:33 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-05-16  0:33 [PATCH v4 4/5] Include group information in xml syscall files Doug Evans
  -- strict thread matches above, loose matches on Subject: below --
2015-05-10 19:01 [PATCH v3 00/17] Catch syscall group Sergio Durigan Junior
2015-05-11  0:28 ` [PATCH v4 0/4] catch " Gabriel Krisman Bertazi
2015-05-11  0:28   ` [PATCH v4 4/5] Include group information in xml syscall files Gabriel Krisman Bertazi
2015-05-12 21:42     ` Doug Evans
2015-05-13  1:17       ` Gabriel Krisman Bertazi
2015-05-13 10:43     ` Pedro Alves

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox