public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Doug Evans <dje@google.com>
To: Gabriel Krisman Bertazi <gabriel@krisman.be>
Cc: Sergio Durigan Junior <sergiodj@redhat.com>,
	Pedro Alves <palves@redhat.com>,
		gdb-patches <gdb-patches@sourceware.org>
Subject: Re: [PATCH v4 4/5] Include group information in xml syscall files.
Date: Sat, 16 May 2015 00:33:00 -0000	[thread overview]
Message-ID: <001a1135b496ab0cf80516281a97@google.com> (raw)

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

             reply	other threads:[~2015-05-16  0:33 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-16  0:33 Doug Evans [this message]
  -- 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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=001a1135b496ab0cf80516281a97@google.com \
    --to=dje@google.com \
    --cc=gabriel@krisman.be \
    --cc=gdb-patches@sourceware.org \
    --cc=palves@redhat.com \
    --cc=sergiodj@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).