Re: feature/package-vc has been merged

[Stefan Monnier <monnier@iro.umontreal.ca>]

>>> I noticed recently that some external packages such as projectile where
>>> copied but not to the extend or why that they are useful.
>> I am afraid I don't understand the issue you are describing.  Could you
>> be more concrete?
> The package is copied but not as good because in the end it misses some
> features, it doesn't feel as polished. I don't have a direct example
> except missing features like no build system integration.
> It is just to bare bone.

I don't know what you mean by "The package is copied".  Then when you
say "not as good": as good as what?  Same for "as polished": as polished
as what?

I'm also not sure even what you mean by "the package": are you talking
about the tarball for `projectile` on NonGNU ELPA?

> First of all I Didn't know about these elpa-packages but there are two
> cases where I think custom commands could be needed such as packages
> with native modules or some that require bootstrapping their build
> system by means such as autotools.

All the packages I have found which used autotools were easy to convert
to rely on the normal build process for ELPA packages.

For those packages which require building other artifacts, such as
`pdf-tools` or `libpq`, the current build recipe does not support that
at all because it was designed for elpa.gnu.org where we don't
distribute binaries compiled for specific architectures.

So instead, the build needs to happen during `package-install` and that
depends on the ELPA protocol which does not include any special support
for that :-(
Luckily it can be solved by appropriate ELisp code in the package, which
can trigger compilation of the artifact either during `package-install`
or later when the package is actually used.

It's not ideal, admittedly, but given the requirement to have something
that can work across various packaging systems (`package-install`,
`package-vc-install`, and possibly others), it's not that bad.

I'm hoping that we'll develop a "standard" way to do it in the form of
some ELisp function/macro so that `pdf-tools`, `libpq`, etc... can
simply include a line or two of ELisp code which says how to compile
their artifact (possibly just running `make`, or `ninja`, ...).


        Stefan