[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Trying to contribute packages: ./pre-inst-env doesn't work

From: Amirouche
Subject: Re: Trying to contribute packages: ./pre-inst-env doesn't work
Date: Wed, 15 May 2019 18:33:48 +0200
User-agent: Roundcube Webmail/1.3.8

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:

Here is mine:

> - 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:

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

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

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..

reply via email to

[Prev in Thread] Current Thread [Next in Thread]