Re: Preferred approach to inclusion of data in ELPA package

[Hugo Thunnissen <devel@hugot.nl>]

On 8/17/23 23:14, Philip Kaludercic wrote:
>
> Another idea is to have a Makefile generate the file, like the one you
> describe in option 2., that is generate whenever the package is built
> and bundled into a tarball for distribution.  That way you don't have to
> store a binary blob in your repository, and you can avoid burdening the
> user with additional computations at either compile or runtime.
>
> Does the generation require any special functionality/tools/code to be
> provided on the device the index is generated on?

The php function/class stubs are generated with a php script, but I'm 
checking the resulting stubs file into git. The index itself can be 
built with just my package based on the stubs file.

Some more context, as I built and bench-marked a prototype: The 
resulting index file is 3.1MB of s-expressions  which when compressed 
with gzip becomes a file of 172K (there's a lot of duplicate 
symbols/strings in there). Loading this file takes about 30% less time 
than building the index from scratch (300ms vs 430-450ms on my laptop 
with Core i5-8250U, byte compiled). I suppose this could be further 
optimized with a more efficient serialization format, but I don't want 
to spend much time on implementing that as I'm working towards an 
initial package release.

How would having a Makefile like you suggest work in practice? Would I 
need to request that the ELPA maintainers add my Makefile to the build 
process of my package somehow? Or is there a standard automated way to 
have Makefiles be executed during an ELPA build?

Also: If the former is the case, is the reduction in load time that this 
brings even significant enough to be worth the bother or should I just 
hold off on this while I look for a more efficient solution?