Since all.xml is a built file these days, and will contain paths
relative to $(top_srcdir)/introspection even though it's not in
that directory, it seems we need to clue xsltproc into where the
other API XML files really are.
Apparently sometimes when doing the distcheck the generator can't
open the file for writing (gets ENOACCESS) presumably because there's
already a file there that's read-only. So remove any existing
settings spec before regenerating.
gtk-doc removes the 'html' directory as part of the build process
so we need to have spec.html generation depend on the gtk-doc html
target. Also, fix up the paths to make sure the generated spec.html
gets copied into the final 'html' directory.
These days more and more devices are showing up that support a
number of different access technology families in the same hardware,
like Qualcomm Gobi (CDMA and GSM), Pantech UM190 (CDMA and GSM),
Pantech UML290 (CDMA and LTE), LG VL600 (CDMA and LTE), Sierra
320U (GSM and LTE), etc. The previous scheme of having device
classes based on access technology family simply cannot handle
this hardware and attempting to add LTE to both the CDMA and GSM
device classes would result in a bunch of code duplication that
we don't want. There's a better way...
Instead, combine both CDMA and GSM device classes into a generic
"Modem" device class that provides capabilities indicating what
access technology families a modem supports, and what families
it supports immediately without a firmware reload. (Gobi devices
for example require a firmware reload before they can switch
between GSM and CDMA). This provides the necessary flexibility
to the client and allows us to keep the API stable when the
same consolidation change is made in ModemManager.
The current code doesn't yet allow multi-mode operation internally,
but the API is now what we want it to be and won't need to be
changed.
