To demonstrate, I attached a modified PKGBUILD file that also packages the development files.

It doesn't install some of the files that the original package does. I'll leave it up to the package maintainer to tweak it as he sees fit.

EDIT: This PKGBUILD is outdated, see the one I submitted below

This sounds like a good idea to me. Issues I see with the proposed PKGBUILD:

No need for the build dir, just build in $pkgname/cmake. Why make things more complicated than they need to be?
Doesn't install custom license. This is required with BSD licensed packages.
The executable will have a different name on x86_64 and i686.

I think the lz4 executable was redundant, anyway, so not building/installing that shouldn't be a problem.

> I think the lz4 executable was redundant, anyway, so not building/installing that shouldn't be a problem.
Redundant? Not really... The lz4 executable has an interface more similar to tools like gzip, bzip2, and xz.

https://code.google.com/p/lz4/issues/detail?id=83&can=1

mkinitcpio will rely on it.

If mkinitcpio needs (or will need) it, obviously it's a problem to not build/install it. I don't see an option for it in cmake, so this may be a non-starter until it's updated.

Hmm, looks like the only difference is "-DDISABLE_LZ4C_LEGACY_OPTIONS", so it shouldn't be hard to patch in.

Somewhat related upstream issue https://code.google.com/p/lz4/issues/detail?id=96 They try to add autotools support that suppose to fix current issue as well.

I have used PKGBUILD file provided by Mika and it works fine for me. I was able to compile/run infinisql binaries that use lz4.so

New release (r109). I mailed author to figure if we can improve this upstream.

It's just odd that the pre-made Makefile will build lz4, but will not shared libs; while cmake will build shared libs but not lz4.

No reason for autotools, cmake fills that roll just fine.

Answer from Yann Collet:

<quote>
I don't exactly maintain the cmake file, because I don't know how it works.
...
I would prefer if possible to embed this capability directly into makefile. I don't know yet how to do it, but I guess it's possible to learn that part.
...
So here we are. I will try to have a look at it in the following days. My time availability is extremely low though, so I can't commit to get this out quickly.
</quote>

Please, send a patch upstream to have library, headers (and possibly man page) into the upstream Makefile.

I see no reason to force this downstream for now.

Hello, OP here.
I created and submitted a patch upstream to fix various issues with the CMake build, and make it work as intended for building the Arch Linux lz4 package.
I also created an updated package, along with the patch. Now it should build the package as expected.

This is what I should have done originally, but I guess I was lazy. I apologize.

See the upstream issue here: https://code.google.com/p/lz4/issues/detail?can=2&start=0&num=100&q=&colspec=ID%20Type%20Status%20Priority%20Milestone%20Owner%20Summary&groupby=&sort=&id=100

News: It seems that the patch has been accepted. The maintainer has attached a version with my modifications for testing purposes. I'll attach a modified PKGBUILD that builds from that attachment if anyone would like to test.

Please note this answer: https://code.google.com/p/lz4/issues/detail?id=100#c6

If you want library and development files be included, please provide an upstream patch to the official Makefile.
The cmake build is not supported by upstream, so, I will not switch to the cmake build system.

Unfortunately, I am not familiar with traditional makefiles to the extent that I could create such a patch.
Instead, I will submit a liblz4 package to the AUR that only contains the development files.
Thank you for your time.

> Instead, I will submit a liblz4 package to the AUR that only contains the development files.
Adding further fragmentation and supporting an essentially unmaintained library is going to result in Bad Things™ down the road. Upstream accepted a patch which declares a stable interface (which is now his responsibility whether he likes it or not) without wanting to maintain it. It's brainless to rely on an interface which has no stability promise, and one which will break silently on upgrade.

Please don't support the cmake buildsys if upstream isn't interested in it.

Upstream agree to add your request in the official makefile: https://code.google.com/p/lz4/issues/detail?id=103.