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

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

On Wed, May 15, 2019 at 12:41:45PM +0200, Gábor Boskovits wrote:
> > > 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...
> >
> >
> No, you don't need to do that. Guix will interpret the changed sources, and
> it will add a warning that the source file is newer.

I've finally succeeded in setting up my environment for building and
contributing packages. Thanks for making it clear that `make` is needed.
This is certainly not explicitly mentioned in the docs as far as I can
see.

> 
> 
> > 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
> >
> 
> The channels mechanism actually makes it possible to split off any
> part of the packages. So there is no limitations in moving most of
> the packages definitions out of guix. I am not familiar enough to
> tell if all package definitions could be moved into channels, but for
> most of them this could be done.
> 
> Could you elaborate on the benefits of doing that?
> I guess this could be a great topic of discussion.

Well I guess that wouldn't have mattered that much if there was a known
way to run `make` only for the packages and not for the whole code base
which is huge.

I'm not sure. The problem for me was that I ran `make clean` under the
source tree and then I couldn't figure out why packages weren't loaded
anymore from my tree. I still don't understand really why these scheme
files aren't loaded dynamically. Do I need these `.go` files to exist?