From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Mikael Djurfeldt Newsgroups: gmane.lisp.guile.devel Subject: Re: Officially require GNU Make to build Guile? (was Re: Bootstrap optimization) Date: Mon, 29 Oct 2018 11:33:01 +0100 Message-ID: References: <87y3aiam5q.fsf@netris.org> <87tvl58zvd.fsf_-_@netris.org> Reply-To: mikael@djurfeldt.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000009776a005795b989f" X-Trace: blaine.gmane.org 1540809082 16194 195.159.176.226 (29 Oct 2018 10:31:22 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 29 Oct 2018 10:31:22 +0000 (UTC) Cc: guile-devel To: Mark H Weaver Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Mon Oct 29 11:31:17 2018 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gH4pJ-00047u-8k for guile-devel@m.gmane.org; Mon, 29 Oct 2018 11:31:17 +0100 Original-Received: from localhost ([::1]:44579 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gH4rP-0001Iw-JO for guile-devel@m.gmane.org; Mon, 29 Oct 2018 06:33:27 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36492) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gH4rK-0001Ia-EQ for guile-devel@gnu.org; Mon, 29 Oct 2018 06:33:23 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gH4rH-0000nT-8h for guile-devel@gnu.org; Mon, 29 Oct 2018 06:33:22 -0400 Original-Received: from mail-ot1-f53.google.com ([209.85.210.53]:33430) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gH4rD-0000k5-CL for guile-devel@gnu.org; Mon, 29 Oct 2018 06:33:15 -0400 Original-Received: by mail-ot1-f53.google.com with SMTP id g25so7047732otl.0 for ; Mon, 29 Oct 2018 03:33:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc; bh=bqgEntXMQrPZ218Hm36O7Uvu15glKjrlVu4jSVzFfhg=; b=o41TT2/ZgV/eWGnnw9UfKzVHm8KjF4TJwe6wSS6ib7ZgizbM7qAK+qDY/p3rs63Q+R DalnCIOeKOxdm3rSvAxcRG0wZiHGKmoeTpeO5bcNWlj0WfvEFioQe1ftwhK0s754/rsO DCMELwr511cjhexgR2c+qhciRrCPuXX1fYqyi+zkRBMG60w/ahOsYRnT64czuWgUsq2C taBfmCVEcuEeKd5cGckg2iCjN0Gs3ddVBHD/Ztg/2yLRT4kRFQLgx+h5pBP0TeV/QaaC 8IPHpCTjhBiE+tXEfmR99LxslRAZP0BWB13U8r3aWS3C3Rr9Tfug67kqWGVrHLkw8o7e oy7g== X-Gm-Message-State: AGRZ1gJNYxmpue/Fj5Cmr0iH5PZ4MaF1ig3Ecb+fcpDTm6K2hnDS5FQn RfFoO6u32hLfXf+YArX4LptlN4PMrknV//uyJjQ= X-Google-Smtp-Source: AJdET5ejDtBMXmuW1DcO8b4RmGnaW8fgD0Yd/bsAdXFFk+7/Aro+7LXl9ed2oXh3sfyS+81L89aA6dGqAPosfA+mYkk= X-Received: by 2002:a9d:fe9:: with SMTP id m38mr7970956otd.2.1540809192599; Mon, 29 Oct 2018 03:33:12 -0700 (PDT) In-Reply-To: <87tvl58zvd.fsf_-_@netris.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 209.85.210.53 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: "guile-devel" Xref: news.gmane.org gmane.lisp.guile.devel:19696 Archived-At: --0000000000009776a005795b989f Content-Type: text/plain; charset="UTF-8" On Sun, Oct 28, 2018 at 11:34 PM Mark H Weaver wrote: > I'm still inclined to consider it a bug, but maybe we can have the best > of both worlds here. I see that Automake has conditionals: > > https://www.gnu.org/software/automake/manual/automake.html#Conditionals > > How hard would it be to test for GNU Make in our configure script, and > then to use your improved Makefile rules only when GNU Make is present? > I don't think that it is hard in itself. However, it is hard for me in this case since I don't know how you have been thinking with regard to the structure of the build system. E.g., I don't know why there's an am/ bootstrap.am which is included in bootstrap/Makefile.am rather than having that material in Makefile.am. In addition, I think it is better that I spend the little time I have in other ways---sorry. But, as you concluded, Guile currently uses GNU Make specific functionality. $(filter-out ...) in bootstrap/Makefile.am is such a case and also the vpath and %-thingies in am/bootstrap.am. Probably, you should start out by making an inventory of the various uses of GNU Make functionality and for each case evaluate how much work would be required to make it standard. First then it is possible to decide if it is worth to do it. However, note that applying my suggested patch would not really change the situation much in this respect since that piece of functionality already now depends on the GNU Make specific $(filter-out ...), such that when GNU Make specifics get handled, having applied my patch doesn't really increase the amount of work in any way. Best regards, Mikael --0000000000009776a005795b989f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, Oct 28, 2018 at 11:34 PM Mark H Weaver <mhw@netris.org> wrote:
I'm still inclined to consider it a bug, but maybe we can have the best=
of both worlds here.=C2=A0 I see that Automake has conditionals:

=C2=A0 https://www.gnu.org/so= ftware/automake/manual/automake.html#Conditionals

How hard would it be to test for GNU Make in our configure script, and
then to use your improved Makefile rules only when GNU Make is present?
=

I don't think that it is hard in itsel= f. However, it is hard for me in this case since I don't know how you h= ave been thinking with regard to the structure of the build system. E.g., I= don't know why there's an am/boots= trap.am which is included in bootstrap/Makefile.am rather than having t= hat material in Makefile.am. In addition, I think it is better that I spend= the little time I have in other ways---sorry.

But, as you concluded, Guile currently uses GNU Make specific functionalit= y. $(filter-out ...) in bootstrap/Makefile.am is such a case and also the v= path and %-thingies in am/bootstrap.am.= Probably, you should start out by making an inventory of the various uses = of GNU Make functionality and for each case evaluate how much work would be= required to make it standard. First then it is possible to decide if it is= worth to do it.

However, note that applying my su= ggested patch would not really change the situation much in this respect si= nce that piece of functionality already now depends on the GNU Make specifi= c $(filter-out ...), such that when GNU Make specifics get handled, having = applied my patch doesn't really increase the amount of work in any way.=

Best regards,
Mikael
--0000000000009776a005795b989f--