build fails when gperf is not installed

[rofl0r]

experienced with the latest release tarball

checking for gperf... no
configure: error: *** gperf not found

is gperf even used somewhere ? if not the dependency should be removed

if yes, the generated C files should be distributed as part of the "make dist" process, so that the user does not need having gperf installed just to generate a single file

[rofl0r]

this seems the only real occurence

./src/udev/Makefile.in:@ENABLE_KEYMAP_TRUE@     $(AM_V_GPERF)$(GPERF) -L ANSI-C -t -N keyboard_lookup_key -H hash_key_name -p -C < $< > $@

[rofl0r]

with --disable-keymap it can be circumvented but is still annoying

[blueness]

keyboard-keys-from-name.gperf is generated on the fly form keyboard-keys.txt and the Makefile. Its not so easy to remove. Any suggested patches?

[rofl0r]

yes my suggestion is to create the file on your box as part of the "make dist" process and include it in release tarballs. that way the makefile target can stay but dependency is already fulfilled so it's not called.

[axs-gentoo]

This sounds doable.. I'll look into adding the necessary bits to the makefile.

[rofl0r]

cool thanks

[axs-gentoo]

Are you using the distfile from http://dev.gentoo.org/~blueness/ or are you using the one generated by the github download link on the tag?? If the latter, there's nothing we can do about this.

[rofl0r]

i'm using proper tarballs, i.e. not the github https crap

[axs-gentoo]

OK so here's the issue in detail:

keyboard-keys.txt is generated from linux headers, specifically from linux/input.h. This file is (as has already been mentioned) fed into gperf to generate keyboard-keys-from-name.gperf , which in turn is processed to create keyboard-keys-from-name.h. The previous keyboard-keys.txt is also used to create keyboard-keys-to-name.h

We don't want to tie the source tarballs to linux headers, and if a binary package is going to be rolled from this then it should really be rolled against the linux headers currently in use on that platform. As such, yes, gperf is a dependency.

That said, if you have a use case that needs this, we -could- look into wrapping the bits in src/udev/Makefile.am related to BUILT_SOURCES and CLEANUP, so that you yourself could easily roll a tarball via 'make dist' with these files included, if you were so inclined. This would mean you yourself still need gperf but others using your tarball wouldn't.

[rofl0r]

"We don't want to tie the source tarballs to linux headers"

wait a sec, so you mean that you will get different files for kernel 3.2 vs kernel 3.11 ?
i'm quite sure there's no difference, since the kernel ABI is rock stable.

the only thing i could imagine is that if you use a really old kernel like 2.6.0 the generated file may have a handful lines less.

[axs-gentoo]

I haven't actually decoded what the process is, but from what I can tell with my brief look it's grabbing the values that are #define'd for the various keys, and using those in order to have its mappings. And yes, it looks like those change fairly often (there's big differences in input.h between 3.5 and 3.10 for instance). I don't think these #define's are part of the "rock stable" API, at least, whatever values the macros are being #define'd to wouldn't be.

[rofl0r]

ok but if you use the latest kernel to generate the list, it should be as complete as it can get, no ?

[axs-gentoo]

I honestly don't know.. Probably, but I don't know what happens if the end-user systems are running older kernels or have system-installed linux/input.h that differs from these keyboard maps.

Too many unknowns, needs testing/experimentation to confirm... is it that worthwhile of an endeavour just so a packager/builder doesn't need to install gperf? there might be a bit of a cost/benefit scenario here to deal with...

Blueness, what do you think? Design decision; i defer to you :)

[rofl0r]

"Probably, but I don't know what happens if the end-user systems are running older kernels or have system-installed linux/input.h that differs from these keyboard maps."

in that case, even shipping a pre-compiled version of eudev could cause breakage - so i guess it's very unlikely

[axs-gentoo]

well, usually if you're shipping a binary package, you have controls on what the version of the systems' linux headers and/or kernel are going to be, and you build for that environment, right? For instance, if the current stable linux headers is 3.2 on a distro, it's unlikely that you're going to build eudev for distribution against 3.12...

if we go this route (ie we do the testing and confirm there aren't going to be conflicts), I expect we will do it in a similar way to how the hwids files are cached -- that is, we'll keep them in git and update semi-regularly.

[rofl0r]

that sounds like a good plan, yes.

[blueness]

"Blueness, what do you think? Design decision; i defer to you :)"

I'm for the status quo. Avoiding gperf is not worth the risk of shipping bad maps.

"in that case, even shipping a pre-compiled version of eudev could cause breakage - so i guess it's very unlikely"

no, because binary based distros (eg debian) are uniform in what they ship per release. so all debian wheezy, say, have the same kernel headers etc. as Ian said in the previous comment.

[rofl0r]

well, but isn't gentoo all about customization ? i could imagine that quite a few ppl install a custom kernel. that's even possible on distros such as debian. it would be very unfriendly if stuff like that would simply break.
in my experience, the keymaps shipped by "kbd" (and its loadkeys command) work with any kernel.

[axs-gentoo]

"well, but isn't gentoo all about customization ? i could imagine that quite a few ppl install a custom kernel."

Yes, it is -- but the linux headers are installed to the system separately from the kernel sources on Gentoo, specifically so that the rest of the packages that are installed have a standard and controlled set of common headers to use.

[axs-gentoo]

If you'd like to test, you can cherry-pick commit id 079b412 and run ./configure --enable-gtk-doc --with-generated-code-distribution , and the build system will then let you roll a tarball with those *.h files included.

Note i didn't check yet if gperf is a hard dep in configure.ac and provide a way to disable it if it is.

[rofl0r]

sigh my work desktop has only gtk-doc 1.15 available.

configure: error: You need to have gtk-doc >= 1.18 installed to build eudev

is the gtk-doc part strictly needed for the experiment ?

and after configure, running "make dist" i suppose ?

[axs-gentoo]

it is, since a dist tarballl needs to include the docs it might normally install.

however I don't know if we actually need 1.18 for our docs. you might get away with using the version you have if you mod configure.ac

[rofl0r]

ok, after running make dist it seems the gperf stuff is successfully generated

make[2]: Entering directory `/tmp/eudev/src/udev'
  GEN    keyboard-keys.txt
  GEN    keyboard-keys-from-name.gperf
/usr/bin/gperf -L ANSI-C -t -N keyboard_lookup_key -H hash_key_name -p -C < keyboard-keys-from-name.gperf > keyboard-keys-from-name.h
  GEN    keyboard-keys-to-name.h

but later on:

  DOC   Scanning header files
make  \
  top_distdir="../../eudev-1.3" distdir="../../eudev-1.3/docs/libudev" \
  dist-hook
make[3]: Entering directory `/tmp/eudev/docs/libudev'
cp: cannot stat `./html/*': No such file or directory
make[3]: *** [dist-hook] Error 1
make[3]: Leaving directory `/tmp/eudev/docs/libudev'

i suspect that's due to the old gtk-doc version

[rofl0r]

ok, i fixed that by creating the html dir by hand and touching foo.html inside it.
after that a tarball containing keyboard-keys-from-name.h was successfully generated - nice.

[rofl0r]

i tested the tarball on a system without gperf, and the configure check for gperf failed as expected. so this test would need to be removed as well.

using a fake gperf executable (containg #!/bin/true), it tries to generate the header anyway:

make[3]: Entering directory `/src/build/eudev/eudev-1.3/src/udev'
  GEN    keyboard-keys.txt
  GEN    keyboard-keys-from-name.gperf
  GEN    keyboard-keys-to-name.h
./gperf -L ANSI-C -t -N keyboard_lookup_key -H hash_key_name -p -C < keyboard-keys-from-name.gperf > keyboard-keys-from-name.h
/bin/sh: ./gperf: not found

i'm not sure why it tries to regenerate that file.

[axs-gentoo]

I need to think this through some more. My original idea assumed (much like you did) that if the files existed they wouldn't be rebuilt, but that seems not to be the case -- I think i need to somehow save a flag when running 'make dist' which will tell the build system what to do.

Or we'll have to just always distribute these .h files.

[axs-gentoo]

..OK, so i've tried a few different experiments and so far I have been unable to find a way to allow Makefile.am to generate these .h files only when they are missing. Patches welcome, but at this stage I think we're going to have to just rely on gperf as a dep.

[rofl0r]

hmm what happens when you touch the file after extracting the dist tarball ?
i think this is likely some timestamp problem

[fjaell]

in eudev 3.0 the configure option --disable-keymap has been removed, so it's no longer possible to bypass the gperf issue.
That means eudev depends on gperf now! Not very nice, would be really helpful if we could find a way to avoid this.

[blueness]

Good point. Right now I have to follow upstream more closely for the kdbus cuttover, so I'm been dropping some of the legacy stuff. I wasn't thinking of gperf dependency.

Any suggestions?

[bbonev]

gperf is a hard dependency since quite a long time. No suggestion came for changing that during the last 6+ years, so closing.