Slavek/Tim, All,

  I don't know what the lifetime plans for 3.5.13 are, but given upcoming
automake 2.0 issues facing hal, if 3.5.13 will be around for more than a year or
so, it would make sense to bring hal/hal-info in-house while the updates to the
source tree are still manageable. (as done with Qt3) As of automake 1.14,
hundreds of warnings are generated regarding 'subdir-objects' being disabled in
automake and build fails due to obsolete macros.

  I have added the subdir-objects option to AM_INIT_AUTOMAKE in configure.in for
Archlinux builds and added 'autoupdate' to correct the obsolete macro build
failure. Hal then builds fine.

  Currently there are over 1M of patches applied to the hal 0.5.14 source. When
6 patch files encompassing over a megabyte of diffs are required, the chance for
subsequent patches breaking prior patches poses a real problem. If 3.5.13 will
be around for a while and still need hal/hal-info, it may make sense to bring
hal in-house and clean it up/apply the current patch sets and make it available
to those still working with 3.5.13. The last updates applied to the hal code
date back to 2011 - centuries ago in Linux terms.

  Hal and hal-info presently exist in a git repository. That may make it easier
to bring the code in-house for update.

  These are just thoughts I had after going though the process to update and
build hal yesterday. Here are the locations of the two git repositories.

  Git repositories:

git://anongit.freedesktop.org/hal

git://anongit.freedesktop.org/hal-info

  It may not be worth the effort, but for those distros on automake 1.14 that
will be moving to automake 2.0 when released, I doubt hal will build without
some significant updates. If 3.5.13 will continue to need hal and will be around
for a while, some planning and effort now (after R14 is out the door) may pay
dividends in the future...

  Apparently automake 2.0 will force object files to be produced in the current
directory deprecating the multiple subdirectory Makefile source references that
hal currently uses. E.g. from partutil/Makefile.am:

libpartutil_la_SOURCES = partutil.h partutil.c ../hald/logger.c

  ../hald/logger.c produces the subdir-objects warning that from my
understanding will cause failure in automake 2.0. If the
AM_INIT_AUTOMAKE([subdir-objects]) option will take care of this problem in 2.0,
then it isn't that much of a problem, but if not, then a bit of work will be
needed on hal. I am still not very clear on all the implications, but from
working through the build on automake 1.14, this was the impression I got. Think
about it, you all decide, I'm going to try R14 and nohal and see how it goes...

-- 
David C. Rankin, J.D.,P.E.