Re: Development shell for diffutils does not appear to work - what am I doing wrong?

[Daniel Littlewood]

Hi Ekaitz, thanks for you reply!

Reading the docs a second time, I think I did misunderstand the
--development argument. The docs say
> Cause guix shell to include in the environment the dependencies of the 
> following package rather than the package itself.
and I took "dependencies" to mean "build dependencies". But perhaps it
just means the runtime ones?
So as you say, you could download the release tarball of diffutils and
be able to run it, but not necessarily to build it from the source.
I wonder why the flag is called "development" when it doesn't allow
you to develop the package. Perhaps it refers to developing guix?

I did exactly as you suggest yesterday and did manage to find all the
dependencies (although I didn't manage to build it in the end, but I
don't know the root cause yet). In fact the very next documented
config option looks like it may be able to build autotools. They give
an example for including the base packages:
guix shell -e '(@ (gnu) %base-packages)'
Perhaps there is a similar expression for importing everything in a
specific build system?

Since I was mixed up between building and installing, I also wonder
whether this is what `guix build` is for. Or, equally, if I copy the
definition of diffutils in base.scm and then do `guix shell -f
my-diffutils.scm` maybe it will build itself? It certainly seems to
have all the necessary information to do so.

I'll test those options later, thanks!
Dan

On Wed, Sep 27, 2023 at 11:08 AM Ekaitz Zarraga <ekaitz@elenq.tech> wrote:
>
>
>
>
>
> ElenQ Technology
>
>
> ------- Original Message -------
> On Tuesday, September 26th, 2023 at 08:08, Daniel Littlewood 
> <danielittlewood@gmail.com> wrote:
>
>
> > Hi guix help,
> >
> > I want to try out making a simple change to the program `diff`, which
> > is part of GNU diffutils:
> > https://packages.guix.gnu.org/packages/diffutils/3.8/
> > I'd like to set up a dev environment, patch diff.c, rebuild it and try
> > out the new binary. Maybe install it globally later, but I'm not there
> > yet.
> > I cloned the diffutils repo from
> > https://git.savannah.gnu.org/git/diffutils.git, and in that directory
> > ran
> > `guix shell git vim nnn -D diffutils` (but I think it's just the -D
> > diffutils I'm having trouble with). I believe that the
> > -D/--development argument should produce a shell within which I can
> > build `diff`.
> > The README says that the first step is to run `./bootstrap`, but that
> > fails because of several missing packages. I don't have the full list
> > right now, but I think autoconf was one, and texi2pdf was another.
> >
> > The packaging for diffutils clearly works (since I can install it), so
> > I wonder if it does something different from what I'm attempting? I
> > couldn't find the scheme file that defines diffutils, but I'm not sure
> > I'd be able to read it anyway (I'm really trying out guix for the
> > first time).
> >
> > Thanks for reading, please let me know if I can provide more info.
> > Dan
>
>
>
> Dan,
>
> I don't think you are doing anything wrong. I don't know why but
> when doing `-D package` guix is often not adding all the development
> dependencies as it doesn't load autotools and related things to
> the shell.
>
> You have to add them by hand.
>
> Also, diffutils downloads a tar.xz which probably has the bootstrap
> step already done because it is considered a release source code.
>
> You are working from development code I expect, which probably needs
> some extra tools.
>
> What I would do: go adding them to the shell one by one as the build
> system complains until it doesn't complain anymore. They will
> probably be `texinfo`, `automake`, `autoconf`, `libtool` and maybe
> I'm missing something... If you add them as you go you shouldn't
> leave anything out.
>
> Also, this is an interesting call. It might be cool to have a way to
> add those directly... I don't know what is best but probably with
> some kind of flag we should add all the deps from the build-system
> too.
> And also, have all the `autotools` in just one package because I
> always forget some of them.
>
> I may start another thread with that...
>
> Thanks for your question, it is a very valid one! It happened to me
> before, too, and it's pretty annoying.
>
> Hope this helps,
> Ekaitz