From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 71741 invoked by alias); 10 May 2015 19:01:47 -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 71725 invoked by uid 89); 10 May 2015 19:01:46 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=4.4 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,KAM_VERY_BLACK_DBL,SPF_HELO_PASS,T_RP_MATCHES_RCVD,URIBL_BLACK,URIBL_DBL_SPAM autolearn=no version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Sun, 10 May 2015 19:01:45 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t4AJ1c3c017470 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Sun, 10 May 2015 15:01:38 -0400 Received: from localhost (unused-10-15-17-126.yyz.redhat.com [10.15.17.126]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t4AJ1bWB021269 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA256 bits=256 verify=NO); Sun, 10 May 2015 15:01:37 -0400 From: Sergio Durigan Junior To: Gabriel Krisman Bertazi Cc: Pedro Alves , gdb-patches@sourceware.org, dje@google.com Subject: Re: [PATCH v3 00/17] Catch syscall group References: <1430011521-24340-1-git-send-email-gabriel@krisman.be> <553F6BC0.9000905@redhat.com> <87r3r42e0v.fsf@redhat.com> <5540ABF8.4000404@redhat.com> <87k2wpt6k6.fsf@krisman.be> <554A275C.80204@redhat.com> <87r3qoi8n6.fsf@krisman.be> X-URL: http://blog.sergiodj.net Date: Sun, 10 May 2015 19:01:00 -0000 In-Reply-To: <87r3qoi8n6.fsf@krisman.be> (Gabriel Krisman Bertazi's message of "Sun, 10 May 2015 15:34:37 -0300") Message-ID: <87wq0gtfxu.fsf@redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" X-IsSubscribed: yes X-SW-Source: 2015-05/txt/msg00231.txt.bz2 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Content-length: 1679 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. --=20 Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible http://sergiodj.net/ --=-=-= Content-Type: application/pgp-signature Content-length: 818 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJVT6sNAAoJENDrdihl/F42dAMP/1JA8/0CMQ3i0nuraUkgVmU0 2d8sS1b9sEOmk5YyRKke0JuaYGu1KMx3OhNWXShNxXDwZpQknrwUX7VCliNdUp00 m3CNbloF7fM4hebwR448RfHfU2PjhwixmD20+3m+XiJXASmPfMDwEkatrjRvYU4W OOTapUlyk25aZzK0UoA4H7jf96jshy0AO9QuttwHMq1wbSJlym5j7WIZ7gRF/JgK UcGM0CECcqFoudlJldLpXM1U63wPY6zEvLJMt+KlLWa8u64JfcdlrOx3tBAEr9z9 nr+fpKe8rsflBn9HW4qE9Zo4qQWKipoFakuWmZazXqxVhvGHYdC1BzW/WBF5VOv1 pUdQ2pTyzqrAdhYIEwlYUXTFzJkPO6e52zKCNkl55oa7ZyR8C+I2R6qmr9d6dSqR 0HfvKS6ECnPS6oUjeIx7TP4o/FdkhqmvEr6XhFoCcKMunRQWYvl1Af18t26theuf FbA8SezrhmY8jbtd6+E6IlS05o9UhXHfKNmt+92+gtUoEsoBa8CBLZHTfgT28L2R RNeIYKxFufkjIje8SX1SFGMJNXkfgj2LkSzW1Y2daSXVOqVJ/ThHuzzKOVE8yYLd 1Tx3dSW/iX3oaMpHY3gPL4P3ljodIEBkve03Hp5xEm0leZm4OJ73LvsAUcy5t28y zzw7jN8gAaQy9ufMbgoE =9q69 -----END PGP SIGNATURE----- --=-=-=--