From mboxrd@z Thu Jan 1 00:00:00 1970 From: Amirouche Subject: Re: Trying to contribute packages: ./pre-inst-env doesn't work Date: Wed, 15 May 2019 18:33:48 +0200 Message-ID: References: <20190515080654.6g7gf7b2g5kx677v@NUC.doronbehar.com> <20190515094629.hcxxxddpgoirwhza@NUC.doronbehar.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([209.51.188.92]:60155) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hQwqz-0000lz-LZ for help-guix@gnu.org; Wed, 15 May 2019 12:34:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hQwqy-0005bA-94 for help-guix@gnu.org; Wed, 15 May 2019 12:34:05 -0400 In-Reply-To: <20190515094629.hcxxxddpgoirwhza@NUC.doronbehar.com> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-guix-bounces+gcggh-help-guix=m.gmane.org@gnu.org Sender: "Help-Guix" To: help-guix@gnu.org Cc: Help-Guix Welcome Dordon, On 2019-05-15 11:46, Doron Behar wrote: > On Wed, May 15, 2019 at 10:46:29AM +0200, Gábor Boskovits wrote: >> > >> It might be easier to first set up a channel with your packages only. >> You >> can find >> several examples out there. >> Here is one of my channels: >> https://gitlab.com/g_bor/nominatim-channel Here is mine: https://git.sr.ht/~amz3/guix-amz3-channel > >> > >> > - I ran ./configure inside /var/code/doron/guix >> > >> >> Did you specify your localstatedir to configure? > > Yes, I've given it the same flags I gave it when I've build it at > first. > >> Did you also run make? > > No! I was hoping I could avoid that as that's extremely CPU intensive.. > Is there a way to run make with only the relevant targets? That could > be > very helpful... That is up to you. Look up: compression.scm 1454: (replace 'build 1455- (lambda* (#:key (make-flags '()) #:allow-other-keys) 1456- (apply invoke "make" "generic_gcc" make-flags))) If you mean running a specific target in guix tree, I don't know about such thing. > Plus, do I have to run make after every change to a package > definition!? > Will it compile everything from the ground up after every such change? There is several way around that but I do not do it often (or at all): 1) You can run guix build -K -e "(@ (doron module) software-package)" Several things here: The -K flag will keep the build if it fails, lookup the documentation about it. From there you can recreate the environment and retry manually the build (almost?) as done by the builder. The -e will install the package that is returned by the eval'ed string that follow the flag. That thing: (@ (doron module) software-package) Read as "import 'software-package' from (doron module)". Usually you also rely on --load-path=DIR aka. -L so the complete command might look like the following: guix build -L $(pwd) -K -e "(@ (doron module) software-package)" There is also the option -f not as nice as -e once you get it. 2) The above technic is nice and good to know but it will not help to tweak and trick a lot of stuff. Another way to go, if you want to keep around the build and experiment with various settings. You can setup a profile that will gather all and only the dependencies for the build your are working on. Once you are confident with the steps required to execute the build your can *translate* that into a guix package. I never do that so I can not help much more. > I wish these technical details would have been documented... Maybe slow but sure thing :) > I'm running make while I'm writing this email and I must say that not > only it takes a lot of time and uses a lot of CPU power, I think, It use all the CPU available (maybe minus one) except if you disable parallel build in the package definition #:parallel-build? #f > it handles way too much irrelevant things such as translations. I don't understand why they show up in git status all the time. Last time I published a patch with those. > I also noticed it runs GUILEC - is it really necessary? I'm no Guile > expert and I wish I could avoid diving to the whole ecosystem of it > just > because I want to use Guix and contribute some packages! You can avoid that package definition compilation step, but it is not worthwhile. the way guix works is that, I think, it needs to lookup all definitions to be able to figure the one you want to install. So, anyway, guile/guix will go through all the packages that are defined. The compilation itself is linked to the fact that GNU Guile use a bytecode VM. > I talked about this subject in a different thread: The design choice of > putting all package definitions in the same repository as the package > manager it self is very uncommon in the Linux. monorepo(s) for the win! > I understand that almost > all of Guix is written in Guile so it must be linked somehow to the > package definitions but I think it makes it very hard to actually > contribute something to the packages definitions! It seems that we, > package maintainers, or to put it simply - the community, need to be > too > much involved in the source code of everything in order to help the > distributions. Not really, with channels you are free to do whatever you want. Most likely you will helpers defined in guix/ or refer to existing package definitions with guix edit sqlite3 or else... so in the end I think a monorepo is good for the time being, given there is channels. > I'd like to be convinced I'm wrong at least in this subject because as > I dive more and more into Guix I feel there have been made a lot of > poor > design choices in it..