[PATCH] Allow disabling the build of all of systemd, leaving just udev

[Bryan Kadzban]

Add a new ./configure arg (--disable-systemd) that causes the build
system to build, test, and install only udev.

Allows udev to be built on a system with many fewer of the build-time
dependencies present.

Signed-Off-By: Bryan Kadzban <***@kadzban.is-a-geek.net>

----

Possible points of discussion:

Should this flag be called --disable-systemd, as I did? (That follows
the autoconf docs, which say --disable-* should only ever turn stuff
off, and --enable-* should only ever turn stuff on.) Or are the
autoconf docs irrelevant, and this should be called --enable-udev-only
or something, instead? The flag name isn't terribly important to me.

(Note that the flag is set to *enable* systemd by default. Disabling it
is probably not to be done lightly, and a bunch of other stuff needs to
be turned off as well for this to actually build.)

Also, a few notes on usage. First, to fully avoid installing systemd
stuff, a bunch of directories need to be set to the empty string at
"make install" time, or they'll be created and left empty.
("pkgdatadir= polkitpolicydir= bashcompletiondir= pkgsysconfdir=
userunitdir= tmpfilesdir= sysctldir= systemunitdir= pkgincludedir=
systemgeneratordir=" is the full list.)

Second, "make check" fails in the po/ directory if systemd was not
enabled at configure time, because intltool was skipped. The udev tests
all succeed though, so "make SUBDIRS=. check" works.

Third, "make distdir" also require systemd to be enabled, otherwise some
of the .policy.in files don't make it into the directory (and so
"dist-xz" won't put them into the generated tarball). But that's not
likely to be an issue, considering who does the releases.

Last, on the changes to configure.ac. The intltool and m4 path checks
are not needed anymore if only udev is being built. Neither is gperf,
so skip the "no gperf found" error message in that case. No need to
check pkg-config for dbus-1. cap_init and sys/capability.h are no
longer required either, so skip them as well. Finally, none of the
--with-{dbus,pam}*dir args need a default value for a udev-only build.

[William Hubbs]

Hi Bryan,

this looks good to me, but there are still pieces being installed which
should not be installed for a udev-only build afaik.

You might want to look at removing those also.

Thanks,

William

[Bryan Kadzban]

Post by William Hubbs
this looks good to me, but there are still pieces being installed
which should not be installed for a udev-only build afaik.
You might want to look at removing those also.

Which pieces?

The only things that get installed in my case are the rules, udev.conf,
systemd-udevd, udevadm, the helper binaries, the manpages, libudev, the
udev and libudev pkg-config files, and stuff in /usr/share/doc. Though
I do use a lot of the existing ./configure knobs to turn other systemd
things off; maybe that's related.

Unless you mean the directories that are getting created, as in the
previous message -- but I don't see a way to stop automake from doing
that. Well, other than setting them to nothing in the Makefile.am if
!ENABLE_SYSTEMD; duh, I should have done that. But that still seems a
bit cosmetic to me.

(One thing I need to do today is fix this so that "make distdir" works
even with --disable-systemd. Should be able to pull the EXTRA_DIST
stuff out of the conditionals to do that. So I'll probably look into
setting these directories to nothing in that case as well.)
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Bryan Kadzban]

Post by Bryan Kadzban
Unless you mean the directories that are getting created, as in the
previous message -- but I don't see a way to stop automake from doing
that.

Digging a bit (the initial attempt at setting directories to "" resulted
in several warnings from automake about conditionally changing pkg*dir
variables), recent versions of automake no longer create empty
directories. Upgrading my system to 1.12.1 (most recent) and rerunning
"autoreconf --force" removed almost all of the requirements to set these
directories to the empty string.

I still need to set "pkgincludedir= pkgsysconfdir=", and that looks like
a too-simple check for no files (it doesn't work if there's only
whitespace). But I don't think it's a huge deal either.

Post by Bryan Kadzban
(One thing I need to do today is fix this so that "make distdir"
works even with --disable-systemd.)

This is now done, just without the directory changes, since a newer
automake fixes that. v2 patch (including header) attached.

Still wondering which bits of systemd got installed in your setup
though. :-)

[William Hubbs]

Post by Bryan Kadzban

Post by William Hubbs
this looks good to me, but there are still pieces being installed
which should not be installed for a udev-only build afaik.
You might want to look at removing those also.

Which pieces?
The only things that get installed in my case are the rules, udev.conf,
systemd-udevd, udevadm, the helper binaries, the manpages, libudev, the
udev and libudev pkg-config files, and stuff in /usr/share/doc. Though
I do use a lot of the existing ./configure knobs to turn other systemd
things off; maybe that's related.

Maybe it is, because I get the following things that would also be
installed:

etc/bash_completion.d
etc/systemd
usr/include/systemd
usr/lib/sysctl.d
usr/lib/systemd/system-generators
usr/lib/systemd/user
usr/share/man/man1
usr/share/man/man3
usr/share/man/man5
usr/share/polkit-1
usr/share/polkit-1/actions
usr/share/systemd

Post by Bryan Kadzban
Unless you mean the directories that are getting created, as in the
previous message -- but I don't see a way to stop automake from doing
that. Well, other than setting them to nothing in the Makefile.am if
!ENABLE_SYSTEMD; duh, I should have done that. But that still seems a
bit cosmetic to me.

Yes, I am referring to empty directories and I can see how you might
see it as cosmetic, but would you consider not creating the
directories?

Post by Bryan Kadzban
(One thing I need to do today is fix this so that "make distdir" works
even with --disable-systemd. Should be able to pull the EXTRA_DIST
stuff out of the conditionals to do that. So I'll probably look into
setting these directories to nothing in that case as well.)

Ok, that may do it.

One more thing though, thinking about it, is that we will need the
systemd-tmpfiles tool because udev is not going to support the
/lib/udev/devices directory any longer for creating custom devices, so
you might want to still build and install all of the parts of that for a
standalone udev build if doing so doesn't bring in more dependencies.

Thanks,

William

[Bryan Kadzban]

Post by William Hubbs

Post by Bryan Kadzban
Which pieces?

etc/bash_completion.d
etc/systemd
usr/include/systemd
usr/lib/sysctl.d
usr/lib/systemd/system-generators
usr/lib/systemd/user
usr/share/man/man1
usr/share/man/man3
usr/share/man/man5
usr/share/polkit-1
usr/share/polkit-1/actions
usr/share/systemd

Those are all the empty directories that a newer automake will get rid
of, except two. You can suppress those at install time with:

make pkgincludedir= pkgsysconfdir= install

I can't fix pkgincludedir without warnings from automake (since it's
unconditionally set to $(includedir)/$(PACKAGE), and overriding it in
different branches of a conditional generates warnings), so I didn't fix
either of them.

Post by William Hubbs
One more thing though, thinking about it, is that we will need the
systemd-tmpfiles tool because udev is not going to support the
/lib/udev/devices directory any longer for creating custom devices, so
you might want to still build and install all of the parts of that for a
standalone udev build if doing so doesn't bring in more dependencies.

I'd rather not replace "cp -a /lib/udev/devices/* /dev" in a boot script
with a binary that nothing else uses, plus its configuration (which
doesn't use nodes in /lib/udev/devices like what has been the udev ABI
for *years*, but instead uses a list of device descriptions), plus any
systemd-level libraries it may or may not need in the future.

If a system is already running systemd, then systemd-tmpfiles may or may
not be the best place to do this (the ABI change is a problem for those
systems, unless I'm missing something in the *tmpfiles* manpages). But
if systemd is not running, then sticking to the previous ABI explicitly
is the right way to go I think.

(Previously, packages could dump a device node into /lib/udev/devices
and it would show up on every boot. Now, they have to describe the
device node and dump a file into $(tmpfilesdir), wherever that happens
to be. This is obviously an interface change.)
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[William Hubbs]

Post by Bryan Kadzban

Post by William Hubbs
One more thing though, thinking about it, is that we will need the
systemd-tmpfiles tool because udev is not going to support the
/lib/udev/devices directory any longer for creating custom devices, so
you might want to still build and install all of the parts of that for a
standalone udev build if doing so doesn't bring in more dependencies.

I'd rather not replace "cp -a /lib/udev/devices/* /dev" in a boot script
with a binary that nothing else uses, plus its configuration (which
doesn't use nodes in /lib/udev/devices like what has been the udev ABI
for *years*, but instead uses a list of device descriptions), plus any
systemd-level libraries it may or may not need in the future.

Actually other things could use it because of /tmp and /run and
creating/removing files/directories there on bootup.

Post by Bryan Kadzban
If a system is already running systemd, then systemd-tmpfiles may or may
not be the best place to do this (the ABI change is a problem for those
systems, unless I'm missing something in the *tmpfiles* manpages). But
if systemd is not running, then sticking to the previous ABI explicitly
is the right way to go I think.

Unless you don't have a previous abi. Gentoo relies on udev copying
things from /lib/udev/devices, which is gone with this version of udev,
so we need the new abi.

So, how about an extra switch --enable-tmpfiles-d that will toggle on or
off whether that is built on a standalone udev build?

William

[Bryan Kadzban]

Post by William Hubbs

Post by Bryan Kadzban
I'd rather not replace "cp -a /lib/udev/devices/* /dev" in a boot
script with a binary that nothing else uses, plus its configuration
(which doesn't use nodes in /lib/udev/devices like what has been
the udev ABI for *years*, but instead uses a list of device
descriptions), plus any systemd-level libraries it may or may not
need in the future.

Actually other things could use it because of /tmp and /run and
creating/removing files/directories there on bootup.

Possibly, but the full functionality will require systemd anyway. The
program still has to be run by something; simply installing it won't do
anything useful. Plus it will have to depend on having mounted the
various temporary filesystems that it changes.

Post by William Hubbs

Post by Bryan Kadzban
If a system is already running systemd, then systemd-tmpfiles may
or may not be the best place to do this (the ABI change is a
problem for those systems, unless I'm missing something in the
*tmpfiles* manpages). But if systemd is not running, then sticking
to the previous ABI explicitly is the right way to go I think.

Unless you don't have a previous abi.

Except that udev-182 and earlier *provided* an ABI. "Put files in
/lib/udev/devices and they'll be copied to /dev at boot time" was the
rule, just like "put programs in /lib/udev and refer to them in rules
you install with IMPORT{program}="" or RUN+="" without a path" was the
rule.

Now that rule has apparently been changed, so programs are going to have
to expend effort coping. Unless I'm missing some functionality of
systemd-tmpfiles when I read the docs.

Post by William Hubbs
Gentoo relies on udev copying things from /lib/udev/devices, which is
gone with this version of udev, so we need the new abi.

I think you need something in the bootscripts somewhere that implements
the *old* ABI. Adding a line to the udev start script that does the
copy will give you that.

Building and installing systemd-tmpfiles will not, unless you also add a
bootscript that runs it. But then you also need to add configuration
files for it, and teach all the other programs that your users want to
run how to adapt to using the new configuration instead of the old
static tree.

(See man/tmpfiles.d.xml for the docs I'm looking at. There is no way to
describe "copy this tree over to this other root", only "create this
file", "write this data to this file", "create this character device",
"create this block device", "delete this file", etc.)
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[William Hubbs]

Post by Bryan Kadzban

Post by William Hubbs

Post by Bryan Kadzban
I'd rather not replace "cp -a /lib/udev/devices/* /dev" in a boot
script with a binary that nothing else uses, plus its configuration
(which doesn't use nodes in /lib/udev/devices like what has been
the udev ABI for *years*, but instead uses a list of device
descriptions), plus any systemd-level libraries it may or may not
need in the future.

Actually other things could use it because of /tmp and /run and
creating/removing files/directories there on bootup.

Possibly, but the full functionality will require systemd anyway. The
program still has to be run by something; simply installing it won't do
anything useful. Plus it will have to depend on having mounted the
various temporary filesystems that it changes.

I agree that just installing it does nothing. But, it can be run at the
appropriate time by your boot scripts, so the other concerns you mention
here would be taken care of that way.

Post by Bryan Kadzban

Post by William Hubbs

Post by Bryan Kadzban
If a system is already running systemd, then systemd-tmpfiles may
or may not be the best place to do this (the ABI change is a
problem for those systems, unless I'm missing something in the
*tmpfiles* manpages). But if systemd is not running, then sticking
to the previous ABI explicitly is the right way to go I think.

Unless you don't have a previous abi.

Except that udev-182 and earlier *provided* an ABI. "Put files in
/lib/udev/devices and they'll be copied to /dev at boot time" was the
rule, just like "put programs in /lib/udev and refer to them in rules
you install with IMPORT{program}="" or RUN+="" without a path" was the
rule.
Now that rule has apparently been changed, so programs are going to have
to expend effort coping. Unless I'm missing some functionality of
systemd-tmpfiles when I read the docs.

It has definitely been changed. See the systemd NEWS file. That is
exactly why I think we need the systemd-tmpfiles executable and man
page.

There are several tools in the systemd build that can be used on
non-systemd systems. Maybe those don't belong as part of the udev
ebuild, but as a separate --enable/--disable-tools switch or something
like that.

Post by Bryan Kadzban

Post by William Hubbs
Gentoo relies on udev copying things from /lib/udev/devices, which is
gone with this version of udev, so we need the new abi.

I think you need something in the bootscripts somewhere that implements
the *old* ABI. Adding a line to the udev start script that does the
copy will give you that.

Also it will allow users to copy any kind of file they please into /dev,
just by putting it in /usr/lib/udev/devices.

William

[Bryan Kadzban]

Post by William Hubbs

Post by Bryan Kadzban

Post by William Hubbs
Actually other things could use it because of /tmp and /run and
creating/removing files/directories there on bootup.

Possibly, but the full functionality will require systemd anyway.
The program still has to be run by something; simply installing it
won't do anything useful. Plus it will have to depend on having
mounted the various temporary filesystems that it changes.

I agree that just installing it does nothing. But, it can be run at
the appropriate time by your boot scripts, so the other concerns you
mention here would be taken care of that way.

Why put effort into bootscripts that run a random other tool, when
instead we can resurrect the single line cp from a few years back?

It's somewhat annoying that we have to do anything, but that's what happens.

Post by William Hubbs

Post by Bryan Kadzban
Except that udev-182 and earlier *provided* an ABI. "Put files in
/lib/udev/devices and they'll be copied to /dev at boot time" was
the rule, just like "put programs in /lib/udev and refer to them in
rules you install with IMPORT{program}="" or RUN+="" without a
path" was the rule.
Now that rule has apparently been changed, so programs are going to
have to expend effort coping. Unless I'm missing some
functionality of systemd-tmpfiles when I read the docs.

It has definitely been changed. See the systemd NEWS file. That is
exactly why I think we need the systemd-tmpfiles executable and man
page.

But see, the thing about ABIs is that they're not supposed to change.

What I will be doing in my own bootscripts is adding back the
single-line copy, to allow programs that are still using the old
interface to continue to work. (Like old versions of the nvidia driver,
which dumped the nvidia0 / nvidia1 / nvidiactl character device files in
that directory, when they couldn't use the sysfs class functions in the
kernel directly. It's been a while since that was happening, of
course.)

If you want to try to get systemd-tmpfiles to work, and figure out which
extra dependencies are needed (like, oh for instance, selinux or
libcap), feel free; that patch shouldn't be too hard to apply on top of
this one, if this gets committed.

Post by William Hubbs

Post by Bryan Kadzban

Post by William Hubbs
Gentoo relies on udev copying things from /lib/udev/devices,
which is gone with this version of udev, so we need the new abi.

I think you need something in the bootscripts somewhere that
implements the *old* ABI. Adding a line to the udev start script
that does the copy will give you that.

Also it will allow users to copy any kind of file they please into
/dev, just by putting it in /usr/lib/udev/devices.

Well, /lib/udev/devices; there is no such thing as /usr/lib/udev unless
you're also buying into merging /usr, which I'm not yet. And if your
system build has done it, then /lib/udev/devices will continue to work
as well. That's the (previously-)accepted path.

But ignoring that -- yes, exactly, good point. Some software (sysvinit,
sysklogd, gpm) puts named pipes or sockets in /dev -- although they do
it without support from the udev bootscript, so not supporting those
files would be OK for them. I don't know what's running in the wild
that has relied on this behavior in the past, though.
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[William Hubbs]

Hi Bryan,

Post by Bryan Kadzban
If you want to try to get systemd-tmpfiles to work, and figure out which
extra dependencies are needed (like, oh for instance, selinux or
libcap), feel free; that patch shouldn't be too hard to apply on top of
this one, if this gets committed.

I spoke with Kay on irc, and he expressed doubts that it will be
committed. However, I did get another suggestion from one of the guys
there.

Automake supports includes, so it would be good to break up Makefile.am
into several modules. That way it would be easy to include them based
on condissionals.

I have started breaking things apart, but if you want, I can send you
the patch as I have it so far and we can collaborate on it. :-)

William

[Bryan Kadzban]

Post by William Hubbs
I spoke with Kay on irc, and he expressed doubts that it will be
committed.

Not being terribly inclined to set up an IRC client, were there any
issues with the patch itself? Or does he just not like the idea at all
for some reason? (Er, Kay? Maybe I should ask you directly. :-) )

Post by William Hubbs
However, I did get another suggestion from one of the guys there.
Automake supports includes, so it would be good to break up
Makefile.am into several modules. That way it would be easy to
include them based on condissionals.
I have started breaking things apart, but if you want, I can send you
the patch as I have it so far and we can collaborate on it. :-)

Sure, we can start poking at it off-list. Though I don't have more than
a few hours a day to put into it. :-)

(That does sound like a lot less-invasive of a change, once the files
are split.)
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Bruce Dubbs]

Post by Bryan Kadzban

Post by William Hubbs
I spoke with Kay on irc, and he expressed doubts that it will be
committed.

Not being terribly inclined to set up an IRC client, were there any
issues with the patch itself? Or does he just not like the idea at all
for some reason? (Er, Kay? Maybe I should ask you directly. :-) )

Post by William Hubbs
However, I did get another suggestion from one of the guys there.
Automake supports includes, so it would be good to break up
Makefile.am into several modules. That way it would be easy to
include them based on condissionals.
I have started breaking things apart, but if you want, I can send you
the patch as I have it so far and we can collaborate on it. :-)

I'm interested in this too. However, I'm not sure what you are
referring to when you mention modules. Do you mean the automake
instruction 'include'?

The problem with udev as it's currently embedded in systemd is that the
udev programs require several systemd .c utility programs, although they
all build without the problematic libraries required by systemd
(intltool, d-bus, etc). These object files could be combined into each
of the udev programs without problems, but I'm having a problem
understanding the concept of what is acceptable.

AFAICT, there still needs to be a change to configure.ac to optionally
avoid all the extras that systemd needs. That seems to be where to
start, but we need support from upstream to get these changes into the
main distribution.

-- Bruce
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[William Hubbs]

Post by Bruce Dubbs

Post by Bryan Kadzban

Post by William Hubbs
I spoke with Kay on irc, and he expressed doubts that it will be
committed.

Not being terribly inclined to set up an IRC client, were there any
issues with the patch itself? Or does he just not like the idea at all
for some reason? (Er, Kay? Maybe I should ask you directly. :-) )

Post by William Hubbs
However, I did get another suggestion from one of the guys there.
Automake supports includes, so it would be good to break up
Makefile.am into several modules. That way it would be easy to
include them based on condissionals.
I have started breaking things apart, but if you want, I can send you
the patch as I have it so far and we can collaborate on it. :-)

I'm interested in this too. However, I'm not sure what you are
referring to when you mention modules. Do you mean the automake
instruction 'include'?

Yes, that's correct. I am thinking we can break up the makefile using
includes then include them based on configure switches.

Post by Bruce Dubbs
AFAICT, there still needs to be a change to configure.ac to optionally
avoid all the extras that systemd needs. That seems to be where to
start, but we need support from upstream to get these changes into the
main distribution.

Yes, there will also be changes to configure.ac as well to make this
work.

My thought is to make the makefile use includes as the first stage of
this then work on the changes to configure.ac.

William

[Dan Nicholson]

Post by William Hubbs
Hi Bryan,

If you want to try to get systemd-tmpfiles to work, and figure out w=

hich

Post by William Hubbs

extra dependencies are needed (like, oh for instance, selinux or
libcap), feel free; that patch shouldn't be too hard to apply on top=

of

Post by William Hubbs

this one, if this gets committed.

=C2=A0I spoke with Kay on irc, and he expressed doubts that it will b=

e

Post by William Hubbs
=C2=A0committed. However, I did get another suggestion from one of th=

e guys

Post by William Hubbs
=C2=A0there.
=C2=A0Automake supports includes, so it would be good to break up Mak=

efile.am

Post by William Hubbs
=C2=A0into several modules. That way it would be easy to include them=

based

Post by William Hubbs
=C2=A0on condissionals.

Breaking up the Makefile.am into several files is probably cleaner,
but it doesn't actually change the problem you're trying to solve
here. You still have to wrap large parts of the build in
AM_CONDITIONALs. That doesn't change whether it's in one file or many.
The include happens at automake time, not build time, so conditionally
including the file won't do anything different for you. Everything
will get merge into the toplevel Makefile.in.

--
Dan
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug=
" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[William Hubbs]

Post by Dan Nicholson
Breaking up the Makefile.am into several files is probably cleaner,
but it doesn't actually change the problem you're trying to solve
here. You still have to wrap large parts of the build in
AM_CONDITIONALs. That doesn't change whether it's in one file or many.
The include happens at automake time, not build time, so conditionally
including the file won't do anything different for you. Everything
will get merge into the toplevel Makefile.in.

If the am_condissionals are controlled by configure switches, we can set
things up so that the packager or user who is building udev or systemd
has control over what gets built. If they want to build udev only, or
systemd, or just the tools in the distribution that don't require
systemd, they will be able to.

This is where I want to go once we have the Makefile broken up. This
will also require some work in configure.ac, but I think it will be
worth that because it will give packagers the flexability to build what
they want.

include Makefile-shared.am
if ENABLE_UDEV
include Makefile-udev.am
endif
if ENABLE_TOOLS
include Makefile-tools.am
endif
if ENABLE_SYSTEMD
include Makefile-systemd.am
endif

The first stage of this will be breaking up Makefile.am and using
includes without condissionals. Once everything builds cleanly in that
setup, we can do the work in configure.ac and add condissionals to
Makefile.am.

William

[Bruce Dubbs]

Post by William Hubbs
This is where I want to go once we have the Makefile broken up. This
will also require some work in configure.ac, but I think it will be
worth that because it will give packagers the flexability to build what
they want.
include Makefile-shared.am
if ENABLE_UDEV
include Makefile-udev.am
endif
if ENABLE_TOOLS
include Makefile-tools.am
endif
if ENABLE_SYSTEMD
include Makefile-systemd.am
endif

With this type of setup, ENABLE_SYSTEMD must imply ENABLE_TOOLS and
ENABLE_UDEV.

Post by William Hubbs
The first stage of this will be breaking up Makefile.am and using
includes without condissionals. Once everything builds cleanly in that
setup, we can do the work in configure.ac and add condissionals to
Makefile.am.

The first thing that will have to be done is to break up
libsystemd_shared_la_SOURCES in Makefile.am. That definition combines
files incompatible with udev-only with files required by udev. udev needs:

log
label
mkdir
cgroup-util
strv
path-util
conf-files
hashmap
set
exit-status
util
dev-setup

but does not need:

cgroup-show
conf-parser
hwclock
pager
ratelimit
socket-util
spawn-ask-password-agent
spawn-polkit-agent
specifier
utf8
virt
watchdog

Basically all of the above are combined into libsystemd-core.la and that
needs to be split into two. I'd just split the first group into
libudev-core.la.

To link, udev also needs the file in libsystemd_daemon_la_SOURCES
(sd-daumon) for udevd, but that probably could be removed with some
appropriate ifdefs in udevd.c.

-- Bruce
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[William Hubbs]

Post by Bruce Dubbs
With this type of setup, ENABLE_SYSTEMD must imply ENABLE_TOOLS and
ENABLE_UDEV.

What I want is for all of the enable_* options to be true by default so
that we don't affect the result of the build unless a packager requests
it by disabling portions.

My goal for the tools option is to find the things in the distribution
that can be useful whether or not your distro is using systemd and set
up so you can build those separately from systemd and udev if you aren't
quite ready to make the jump to systemd.

Post by Bruce Dubbs
The first thing that will have to be done is to break up
libsystemd_shared_la_SOURCES in Makefile.am. That definition combines
log
label
mkdir
cgroup-util
strv
path-util
conf-files
hashmap
set
exit-status
util
dev-setup
cgroup-show
conf-parser
hwclock
pager
ratelimit
socket-util
spawn-ask-password-agent
spawn-polkit-agent
specifier
utf8
virt
watchdog
Basically all of the above are combined into libsystemd-core.la and that
needs to be split into two. I'd just split the first group into
libudev-core.la.

I'm confused here because you first refer to
libsystemd_shared_la_SOURCES then libsystemd_core.la. What about
libsystemd_shared.la? Also, there is already a libudev-core.la. I will
look at it and see what it includes.

Post by Bruce Dubbs
To link, udev also needs the file in libsystemd_daemon_la_SOURCES
(sd-daumon) for udevd, but that probably could be removed with some
appropriate ifdefs in udevd.c.

I'''m not seeing where udev needs this off the top of my head. Actually
I just ran "git grep -i sd.daumon" on the tree and that turns up
nothing.


Thanks,

William

[Dan Nicholson]

Post by Dan Nicholson
Breaking up the Makefile.am into several files is probably cleaner,
but it doesn't actually change the problem you're trying to solve
here. You still have to wrap large parts of the build in
AM_CONDITIONALs. That doesn't change whether it's in one file or man=

y.

Post by Dan Nicholson
The include happens at automake time, not build time, so conditional=

ly

Post by Dan Nicholson
including the file won't do anything different for you. Everything
will get merge into the toplevel Makefile.in.

If the am_condissionals are controlled by configure switches, we can =

set

things up so that the packager or user who is building udev or system=

d

has control over what gets built. If they want to build udev only, or
systemd, or just the tools in the distribution that don't require
systemd, they will be able to.
This is where I want to go once we have the Makefile broken up. This
will also require some work in configure.ac, but I think it will be
worth that because it will give packagers the flexability to build wh=

at

they want.
include Makefile-shared.am
if ENABLE_UDEV
include Makefile-udev.am
endif
if ENABLE_TOOLS
include Makefile-tools.am
endif
if ENABLE_SYSTEMD
include Makefile-systemd.am
endif
The first stage of this will be breaking up Makefile.am and using
includes without condissionals. Once everything builds cleanly in tha=

t

setup, we can =C2=A0do the work in configure.ac and add condissionals=

to

Makefile.am.

What do you know, that works. I had thought automake didn't support
that, but it works nicely. The one thing I was trying to do when I was
starting this patch was keep dist working regardless of your configure
flags. Usually that just mean leaving EXTRA_DIST out of the
conditionals. That's painful, though, and you can probably just bring
out a big hammer during dist. I have something like this in
pkg-config:

if !ENABLE_SYSTEMD
dist-hook:
@echo "error: you need to enable systemd for dist"
@exit 1
endif

--
Dan
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug=
" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html