This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH v4 4/5] Include group information in xml syscall files.


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]