help-guix
[Top][All Lists]
Advanced

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

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


From: wolf
Subject: Re: Development shell for diffutils does not appear to work - what am I doing wrong?
Date: Wed, 27 Sep 2023 18:25:47 +0200

On 2023-09-27 11:58:32 +0100, Daniel Littlewood wrote:
> 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.

I think your confusion here stems from not understanding how (not only, not all)
GNU project in general operate as far as release management goes.  Most GNU
project do provide something called release tarball, which is an archive
intended for consumption by distributions/end-users.  This archive is (for
autotools projects) created by running `make dist'.  This is the archive
distributions (including Guix) use for building the package.

The advantage of the archive is that it contains some already generated files.
For example, when building the archive, you usually start by running
`./configure', since that file is provided as part of the archive.  When
building from VCS, you usually start with some variant of `./bootstrap'.

The implication (and source of your problem) is that less software is required
for the build from the archive compared to the VCS.  And that is a good thing!
For example autotools can be sensitive quite a bit to the version (you need to
have the correct one).  However the generated configure script is insanely
portable, so you can (for example) build the project even on distributions that
do not package autotools 2.69 anymore.

So if you download the archive, and use the -D, you will be able to build it.
However, for VCS checkout you need to provide the additional packages yourself
(as you already figured out).

Hope this sheds some light on the cause.

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

Have a nice day,
W.

-- 
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.

Attachment: signature.asc
Description: PGP signature


reply via email to

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