From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 103177 invoked by alias); 16 May 2015 00:33:09 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 103163 invoked by uid 89); 16 May 2015 00:33:09 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mail-qk0-f202.google.com Received: from mail-qk0-f202.google.com (HELO mail-qk0-f202.google.com) (209.85.220.202) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Sat, 16 May 2015 00:33:07 +0000 Received: by qkan20 with SMTP id n20so1259666qka.0 for ; Fri, 15 May 2015 17:33:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:message-id:date:subject:from:to:cc :content-type; bh=mq6cS6WyHZ9C8+PuhH/SibFpJGmirLHIXp6+B1+jBg4=; b=OArO8SyxfOL1ZskaecVPkt/NgY8mC2Yd/Shaas6VpZRxXVfJM/IMOMY3PCiwVsRrBT ek1WPcLmtmhd6JRMNx6zZRAQEEqWxB4TkpYLgVcQ0XZIY1f2TQibK4Somljq7VHiZiNe 6tmmdVzA65Un+VQfUl3w4XZ3xwmGJER/e5yUKDNra6tfAP51zZY5InuKW88EGN/qvVR9 BT/aJGoWfST+/V96AE7nm2HAn+gDKLsmH74MjTiPlhJdvbURpWKRqYsx527KVhAgzNDz nMzjscsaAwQ0ezErZ6y3ASgJabRgxDi9PbgbRmg0P8gP4bmUWcOnnhSaKqswYTzwjHIV lldA== X-Gm-Message-State: ALoCoQkj/kojoHoTEa+DAJuTAyp58eJTqbOa8QA5WR7Kjvt/FAJCei1GzTyanq5zDygRxd1j4JHg MIME-Version: 1.0 X-Received: by 10.140.238.201 with SMTP id j192mr16931109qhc.14.1431736385458; Fri, 15 May 2015 17:33:05 -0700 (PDT) Message-ID: <001a1135b496ab0cf80516281a97@google.com> Date: Sat, 16 May 2015 00:33:00 -0000 Subject: Re: [PATCH v4 4/5] Include group information in xml syscall files. From: Doug Evans To: Gabriel Krisman Bertazi Cc: Sergio Durigan Junior , Pedro Alves , gdb-patches Content-Type: text/plain; charset=UTF-8; format=flowed; delsp=yes X-IsSubscribed: yes X-SW-Source: 2015-05/txt/msg00423.txt.bz2 Gabriel Krisman Bertazi writes: > Doug Evans 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