although it's dumb that they don't just ship generated files in the tarball, we can at least restrict when it gets pulled in currently, systemd uses gperf for a few things: src/udev/keymap/keys-from-name.h src/core/syscall-from-name.h src/login/logind-gperf.gperf src/journal/journald-gperf.gperf the udev keymap code needs gperf (USE=keymap). the other three files are systemd specific and not compiled for udev. so the dep should get put behind keymap?(), and the src_configure can be tweaked to stop the hard fatal configure check: use keymap || export ac_cv_path_GPERF=true
It seems to work like that except it's very easy to miss it when version bumping since it will just return 0 and then generate empty(?) file. We might need check like done for secure_getenv: if ! [[ $(grep -i gperf Makefile.am | wc -l) -eq 24 ]]; then eerror "The line count of gperf failed, see bug #452760" die fi :-/
fixed in tree for -r4 and 9999
* The line count for secure_getenv() failed, see bug #443030 * ERROR: sys-fs/udev-9999 failed (prepare phase): * (no error message) # LC_ALL=C date --utc Mon Jan 21 17:37:09 UTC 2013 Just synced
Noticed this is not fixed in sys-fs/eudev, reassigning
I mean Comment #0
(In reply to comment #4) > Noticed this is not fixed in sys-fs/eudev, reassigning Fixed in eudev. Thanks for the report!
Upstream (git, after release of udev-205) made the dev-util/gperf dependency even harder to avoid: http://cgit.freedesktop.org/systemd/systemd/commit/?id=9d7d42bc406a2ac04639674281ce3ff6beeda790 I just made dev-util/gperf a hard DEPEND on sys-fs/udev-9999 again. I don't see gperf being a problematic dependency -- but there might be something I don't know. vapier?
i was trying to avoid stupid stuff on embedded setups. if it's not really feasible with the current code like it was before, then i guess there's not much to be done. ideally they'd include generated files like this in their tarballs, but i'm guessing their releng process sucks and can't cope.
(In reply to SpanKY from comment #8) > i was trying to avoid stupid stuff on embedded setups. if it's not really > feasible with the current code like it was before, then i guess there's not > much to be done. ideally they'd include generated files like this in their > tarballs, but i'm guessing their releng process sucks and can't cope. in eudev we only depend gperf for USE=keymap and we only test in configure.ac for gperf if --enable-keymap. I just grepped that source tree and I can't see any other reason for it. Comments on whether I'm missing anything?
(In reply to Anthony Basile from comment #9) > (In reply to SpanKY from comment #8) > > i was trying to avoid stupid stuff on embedded setups. if it's not really > > feasible with the current code like it was before, then i guess there's not > > much to be done. ideally they'd include generated files like this in their > > tarballs, but i'm guessing their releng process sucks and can't cope. > > in eudev we only depend gperf for USE=keymap and we only test in > configure.ac for gperf if --enable-keymap. I just grepped that source tree > and I can't see any other reason for it. > > Comments on whether I'm missing anything? that's specific to eudev. upstream udev (systemd) doesn't have the hwdb support optional, or the keymap (keyboard) hwdb rules separated from the overall hwdb support. it's always installed on every configuration you can throw the build-sys at. and as per upstream systemd ML from upstream's mouth, the hwdb data may or may not be used for essential functionality, and it may or may not cause undefined behavior when it's missing. so i don't think restoring the flag to retain it's optionality is either safe, sane or worth the effort of carrying custom #ifdef -patch forever. imho :)
(In reply to Samuli Suominen from comment #10) > (In reply to Anthony Basile from comment #9) > > (In reply to SpanKY from comment #8) > > > i was trying to avoid stupid stuff on embedded setups. if it's not really > > > feasible with the current code like it was before, then i guess there's not > > > much to be done. ideally they'd include generated files like this in their > > > tarballs, but i'm guessing their releng process sucks and can't cope. > > > > in eudev we only depend gperf for USE=keymap and we only test in > > configure.ac for gperf if --enable-keymap. I just grepped that source tree > > and I can't see any other reason for it. > > > > Comments on whether I'm missing anything? > > that's specific to eudev. > > upstream udev (systemd) doesn't have the hwdb support optional, or the > keymap (keyboard) hwdb rules separated from the overall hwdb support. it's > always installed on every configuration you can throw the build-sys at. > and as per upstream systemd ML from upstream's mouth, the hwdb data may or > may not be used for essential functionality, and it may or may not cause > undefined behavior when it's missing. > so i don't think restoring the flag to retain it's optionality is either > safe, sane or worth the effort of carrying custom #ifdef -patch forever. > imho :) do we have any known instance of badness here when hwdb is missing?
