Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

>> BTW, I found myself being more focused on the "in place archive" use
>> case.
>
> I have no idea what "in-place archive" means here.  AFAIK none of the
> code lets you generate an archive without making copies of the files
> (i.e. it's not "in-place").

OK, wasn't sure what to call it.  I meant invoking "make archive", which
creates the archive in the elpa working directory, including local
changes.  Basically, I was doing:

   make externals
   make
   make archive

>> That's how I ended up invoking the process-archive target
>> directly which indirectly deleted .git (this is the one my patch now
>> prevents).
> [...]
>> Then one can test dependency resolution, byte-compilation and
>> compatibility on the "target Emacs" -- I test Emacs 24.1 through 24.5
>> and master.  Testing just against the default emacs on PATH (what "make"
>> does right now) is OK for development, but GNU ELPA should encourage
>> backward and forward compatibility.
>
> AFAIK "process-archive" won't byte-compile anything, so it's not very
> useful for that.  It just shuffles things around so they're in the place
> and form expected for package-install.

Agreed, didn't mean to confuse things with the reference to
"process-archive".  I only called it while I was experimenting with how
the build process works.  I don't call it directly normally.

But for byte-compilation testing, I do a package-install in each target
emacs, and check the byte-compilation results reported by the target
emacs.  For that step I point at the result of "make archive".

I consider this the "package compatibility testing" use case, where I
want to make local changes that, after a make invocation, are made
available as installable packages.  Running admin/update-archive.sh
after each change isn't what I want, because it does things like trying
to pull elpa.git.

> The purpose of the "in-place installation" method is so that those
> packages behave kind of like Emacs's bundled packages (except that you
> need to add the "packages" dir to your package-directory-list, so they
> won't appear in "emacs -Q" and after "cd .../emacs; make" you also have
> to do "cd .../elpa; make").  Just like Emacs's bundled packages, you
> don't need to "package-install" them, or even to choose which ones
> you want.

OK.  I haven't been using that (other than as a test of byte compilation
against the default Emacs) since I've been doing Excorporate feature
development in a standalone git repository.  But I may use this work
flow once I start doing feature development in elpa.git.  For now I'm
only doing packaging/compatibility work.

Speaking of which, I'd like to push the attached patch set, which makes
externals deletion safer and adds the first two core packages to GNU
ELPA (ntlm and soap-client).  Look OK?

Thanks,
Thomas