From debbugs-submit-bounces@debbugs.gnu.org Mon May 24 09:38:17 2021 Received: (at 48463) by debbugs.gnu.org; 24 May 2021 13:38:17 +0000 Received: from localhost ([127.0.0.1]:42585 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1llAme-0003MA-QD for submit@debbugs.gnu.org; Mon, 24 May 2021 09:38:17 -0400 Received: from m42-5.mailgun.net ([69.72.42.5]:10908) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1llAmZ-0003Lt-No for 48463@debbugs.gnu.org; Mon, 24 May 2021 09:38:15 -0400 DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=mg.wilsonb.com; q=dns/txt; s=krs; t=1621863494; h=Content-Transfer-Encoding: Content-Type: MIME-Version: Message-Id: In-Reply-To: References: From: Subject: Cc: To: Date: Sender; bh=PzXlBkfxE7SBTd6LUovlC4UTxaWh4/CGNB8gMT3YtSs=; b=sQErGkZZJrn/lE+nUEe8sKjR60YcrWkWDiPqTiY5uN7f3QUHdRb1YErWP1bj8moNYGh+U7+h cRTs316u2owvOl/H+0OhxmvcJSkGFKG0GThyBk3OqVcsWO8jigMHPxc4QzV7Rr9EYjHw5jfc iU7h78X1KcVvpShlS0GTf8Eqg74YuPnf70a3htLD/vRWsgmy42NmxiPuUtlDXD99tTO9NUR6 LmfK/6W4VZMOzhPrjx6UnooAhsK5YZM+x289bxuLXkaEo3gEXoNEe9t17QcTPWB4JPqNa7GG YZXhlkBoPYVO/tSJDV3/WLpQvttKSB7p6obsxf9YqLuwq7krYNg3aA== X-Mailgun-Sending-Ip: 69.72.42.5 X-Mailgun-Sid: WyJjZGI4NCIsICI0ODQ2M0BkZWJidWdzLmdudS5vcmciLCAiMDg1NDdhIl0= Received: from wilsonb.com (wilsonb.com [104.199.203.42]) by smtp-out-n03.prod.us-west-2.postgun.com with SMTP id 60abac2a67d156359ac485d4 (version=TLS1.3, cipher=TLS_AES_128_GCM_SHA256); Mon, 24 May 2021 13:37:46 GMT Received: from localhost (ac134152.dynamic.ppp.asahi-net.or.jp [183.77.134.152]) by wilsonb.com (Postfix) with ESMTPSA id B5B4CA2FB1; Mon, 24 May 2021 13:37:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wilsonb.com; s=201703; t=1621863464; bh=PzXlBkfxE7SBTd6LUovlC4UTxaWh4/CGNB8gMT3YtSs=; h=Date:To:Cc:Subject:From:References:In-Reply-To:From; b=mLT+qxXK20D8CnIlSbhbTVCDoktFyfaZBS2dmEbPduOVvo3aD3E0FkwnjcULw4xtX R9i+maj22INcmejlQXxxyEdIWPfOBC12w8QRFRiE12wFS8KvKSm61WLs2DNwGBHfFm 5vR1IDXTWtUm4JKr9mhD2a7TS8EuEz1NDISxSnG58VP/KrkW3rjzt2S+hUiDT51kfx SSfMJg6JV/4kLYNdYRWFdt9wLAQYsfbGeTlm/iUXiVVVc9aQWikqY1TgfBddH6ENsr wokDzvPdZ53U03wnUzBvJqd44LIpzUeb0TdSF+1G6MbtzYbIQMsTXAoRmCk2OYizz7 926Z2/JkFBCcp6KgcavKBAQMl5acbuAkuoe1IJagayXe3p4qAZGXjtg6vW7Xlc6bqF QTdNGsaIe7k0P77VoxrK+GqMvefXGCQj9acbtFlm11A6bvkmsbda2bpdF+d4DDHKRQ lJE2saaFxJK5ny4CN9glEKl9wr1hJn8r6feKYkPsEbRENeHDPCwa7ninnqyzOjGV4L mJVAfDK8+H+J7vyAayRBaS7cvd5mci3+LdgVfM+UZ24HsLv1cbKG+57+WYtSEJhVUy GQkFrnA7YCrn3Dxuxk95qC2O8oYfTkG3U5mwbfSGGOchAyxYznibp9+1R/MwfJkJlr rGlJl6jTuXVR4OQmmymqcwsg= Date: Mon, 24 May 2021 22:37:41 +0900 To: Leo Prikler Subject: Re: gnu: Add j. From: elaexuotee@wilsonb.com, x@wilsonb.com References: <3LOAUDT0FLL4U.2SOD925YP915T@wilsonb.com> <8b853d0585505ce29c9afc638b644fa34805e6c0.camel@student.tugraz.at> In-Reply-To: <8b853d0585505ce29c9afc638b644fa34805e6c0.camel@student.tugraz.at> Message-Id: <293L8YPQS4CLB.3VK1B1A36XNAY@wilsonb.com> User-Agent: mblaze/1.1 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 48463 Cc: 48463@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Thanks for taking a look! Leo Prikler wrote: > That should be fine, we provide multiple versions for other packages > where applicable as well. Do note, that we should try to keep the > number limited, though. You may perhaps want to export make-jlib, so > that the user can build their own. Cool. I like the idea of exporting the build procedures. > Are fat binaries the accepted HPC way? I'm not up-to-date to this. I believe so? Don't quote me on that though. For this particular package th= e overhoad is just ~8MB, so I don't think it's much of an issue either way. I= t would probably be more of a hassle to split j into a package for each varia= nt. > Both sound like good ideas, although I'm a little less sure about the > texlive one. Would a meta-package like gnome also be acceptable? A metapackage is certainly practical. The entire set of J addons currently weighs in at a whopping 50MB. hehe. However, there are about 125 addons in total, so it simply feels "more correct" to let the user also choose just t= he addons they want, which I think would require something like jsoftware-unio= n. That said, either way, an "all batteries include" package would be good to have, and since this is way easier than packaging the addons separately, I'= ll definitely work on the metapackage first. > As above, I'd prefer if it was one procedure and one package pointing > to the latest j80x, assuming all of our added patches can also be > applied to earlier versions. Yeah, that would definitely be ideal. Unfortunately, it's not so straigthforward. The the "major versions" are th= e xxx part of jxxx-y, with large changes between each, e.g. j902 introduced a= nd non-compatible API change over j901. So, from a pure J user perspective, ha= ving all jxxx versions available is ideal. However, each version seems to require its own set of build flags and somet= imes version-specific patches (like in the j901 case). We probably don't want to= push those settings out into user manifest specs. On the other hand, there are already 10 versions from j801 to j903. > > +(define make-jlib > > + (match-lambda > > + (($ > > + builder jversion revision hash type patches extra-inputs > > extra-envars) > Please try to use keyword arguments. Actually, maybe these "build configuration" records could solve the above "too many versions" problem. We could offer only the latest J (and J beta?)= packages in the repo, but let (gnu packages jsoftware) export a set of "def= ault configurations" for old versions to be used with the make-j procedure. Any particular reason to avoid using records though? Currently, its letting= us share configuration options between j902 and j903 that don't work in j901. Personally, I thought this felt like a nice declarative, scheme-y way to go= , but my Scheme is still very amateurish. Definitely wanting to rectify any strange ideas I may have. > > + (properties `((jversion . ,jversion) > > + (jrevision . ,revision) > > + (jtype . ,type))) > Are those used anywhere? Can jversion and jrevision not be parsed from > (package-version jlib)? The make-j procedure uses them. We'd have to parse out these from both the version string and package name with a what's essentially the inverse of th= e jname procedure. I found it a lot more readable and less hassle to just propagate this data directly. However, if there's a particular reason why using properties is problematic= , I'll try to see what I can do.