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

[Doron Behar <doron.behar@gmail.com>]

Thanks for the quick reply!

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

Oh right, thanks. That's an excellent reference.

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

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? I
wish these technical details would have been documented...

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, it handles way
too much irrelevant things such as translations.

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!

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. 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. That's rather unfortunate IMHO. 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..

> 
> Are your packages in a separate file?
> If yes, did you add it to local.mk?

No, I've added new definitions to existing files.

> > -----
> >
> > Failing to do that and after looking for alternative ways to create new
> > packages, I read about the `--load-path` option of `guix build`. Is it
> > possible to use it for new packages testings? I tried to run the
> > following but I got all kinds of warnings and errors:
> >
> > guix build -L/var/code/doron/guix my-new-package
> >
> >
> I would not do that, the channel mechanism superseded this.

I see, makes sense.

> > Here is all of the output:
> > https://gist.github.com/doronbehar/38d31142522fd01a67e7da412b0cf5ed
> >
> > Since there were all of these "source file newer than compiled"
> >
> 
> These are actually harmless, they indicate that your .go files should be
> regenerated, as they are older than the .scm files. You can run make to
> get rid of these. (Have not looked at the error, tough)

Oh right, makes sense in accordance to your previous comment on running
make.

> 
> 
> > messages, I tried putting back my channels configuration from above and
> > run `guix pull` again but I got pretty much the same errors and
> > warnings.
> >
> > -----
> >
> > Any way, I'm very frustrated. Although I'm very excited as for the
> > genius design of Guix and it's flexibility and extensibility, I'm very
> > disappointed by it's UX for a simple thing as package contribution. but
> > this should be addressed in a separate discussion
> 
> .
> >
> 
> I am very sorry to hear that. I hope you can point us to the right
> directions
> to make this easier. Suggestions about documentation are also very welcome.

Oh right. When I'll actually understand everything hopefully with your
guidance, I hope I'll find the time to send some patches.

Doron.