GNU bug report logs - #38140
ELPA needs a standard mechanism for single-package compilation

Previous Next

Full log

View this message in rfc822 format

From: Raffael Stocker <r.stocker <at> mnet-mail.de>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: 38140 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: bug#38140: ELPA needs a standard mechanism for single-package compilation
Date: Sat, 18 Jan 2020 16:30:40 +0100

(I cc'ed Stefan Monnier, as the bug report was on his request.)

Stefan Kangas writes:

> Raffael Stocker <r.stocker <at> mnet-mail.de> writes:
>
>> To compile a single ELPA package for tests or during development, it is
>> currently necessary to clone/pull the whole elpa.git.  This is wasteful
>> if only a single package is of interest.  ELPA should have a standard
>> mechanism that allows (pulling/)compiling/testing etc. of single
>> packages.  I request that such a mechanism be implemented.
>
> I don't think we want to split up elpa.git into many small ones to
> support this use case, since the other side of the coin is that it
> would make the job harder for the ELPA maintainers.

I agree.

> If you really want this, you could try "git clone --filter", but I'm
> not sure if the GNU repositories are configured to allow for that.

This is not so much about the amount of data.  The problem is that a
full "make" takes quite long (at least on my fairly slow machine) and
the output pertaining to the package of interest is easily overlooked.
I think it would be fine to do a "git clone" of the full repo but then a
"make <package>" or something to check compilation of just one package
in an otherwise clean worktree.  AFAIK this is not possible with the
current setup.

The idea is to have an easy and standard way of checking that a package
builds correctly.

> Note also that there is already the possibility in ELPA to use an
> external repository.  This is optional and only used when there is a
> specific need though, IIUC.

Yes, but does this solve the problem with making only one package?

Regards,
        Raffael

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.