From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ricardo Wurmus Subject: Re: New build-system quest (premake4 t-engine) Date: Tue, 25 Jul 2017 23:18:32 +0200 Message-ID: <87fudk6wrb.fsf@elephly.net> References: <87shi6fxf0.fsf@gmail.com> <878tjjfe82.fsf@elephly.net> <87fudllezz.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:46776) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1da7E8-0004Om-M6 for guix-devel@gnu.org; Tue, 25 Jul 2017 17:18:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1da7E4-0005zI-Fb for guix-devel@gnu.org; Tue, 25 Jul 2017 17:18:48 -0400 Received: from sender-of-o51.zoho.com ([135.84.80.216]:21015) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1da7E4-0005xk-6R for guix-devel@gnu.org; Tue, 25 Jul 2017 17:18:44 -0400 In-reply-to: <87fudllezz.fsf@gmail.com> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Oleg Pykhalov Cc: guix-devel@gnu.org, =?utf-8?Q?Sol=C3=A8ne?= Rapenne Hi Oleg, > Ricardo Wurmus writes: > >> Have you tried using the “gnu-build-system” and replacing the configure >> phase with your invocation of premake4? > > I did it like you wrote. > > But the problem was tome4 (t-engine) wants config=release. I’m not sure what this means, but if this is an argument to “make” you can pass it to the build phase with the #:make-flags field of the build system arguments. If it’s about the invocation of premake you would just do that in your replaced configure phase: (zero? (system* "premake4" "config=release" …)) > Firstly I thought that it will be good to have a different build system > for premake in future, so we don't need always to overwrite configure > phase. > > May be I'm wrong and it's OK to do all the time, I'm not sure. It might be useful, but I don’t know how often that would be needed. Our build systems so far each cover a very large number of packages. If it turns out that many more packages would need to do the same steps I think it would be fine to add a new build system. >> One difference between “guix build” and “guix environment” is that the >> latter builds a profile first, so environment variables for libraries or >> headers really only have to be set to a single directory >> (e.g. $GUIX_ENVIRONMENT/lib or $GUIX_ENVIRONMENT/include). >> >> “guix build”, on the other hand, builds up long chains of directories as >> the values for these environment variables. > > Hm, do they both produce kinda the same environment in native? It’s similar, but not the same. Some applications cannot really deal with a search path that involves multiple directories. PyQt, for example, only looks in a single hard-coded directory for extensions, so it would find them inside of “guix environment” but not in a build environment. -- Ricardo GPG: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC https://elephly.net