Re: Common ModemManager.h



I think that looks great. -Jason

On Wed, Aug 17, 2011 at 10:40 AM, Aleksander Morgado <aleksander lanedo com> wrote:
Hi hi,

> > > > I'm not sure why it is better to manually maintain the file rather
> > > > than auto generating it (other than XSLT being a difficult language),
> > > > but I certainly agree with using enum types instead of #defines.
> > > >
> > >
> > > It actually depends on what we want to have in that common header. If we
> > > just want to define the DBus API symbols and types, then autogeneration
> > > is good enough (some XSLT magic just needed to get enums instead of
> > > #defines). But if the header ends up needing additional things not
> > > coming from the DBus API, then it probably makes more sense to have it
> > > manually maintained. At the end the API is not supposed to change that
> > > often... although it will completely change in 0.6 :-)
> > >
> > > Probably someone with experience in NM can give any reason why
> > > NetworkManager.h is manually maintained and not autogenerated from the
> > > DBus API?
> >
> > Because nobody has written the code to autogenerate it :)  Plus then I
> > think we'd lose some of the comments that are used when generating the
> > documentation unless we write gtkdoc glue for the XSLT thing too, which
> > wouldn't be bad idea.  Don't use NetworkManager.h as the gold standard
> > here.  Lets do what we think is best for MM regardless of how NM does
> > things since there's lots of historical baggage that hasn't been
> > important enough to fix up yet.
> >
>
> I see :-) I will try to improve the XSLT in order to generate the enums,
> and polish a bit the generated header file. I guess it will never be too
> late to go back to manually maintained one, if we ever need it.
>

Ok, so I hacked the XSLT to generate enums instead of defines where
appropriate, and reworked the build so that the ModemManager.h header is
used by the daemon and plugins themselves. Attaching to the email the
example header generated.

I skipped the generation of _LAST values for enums, as it's probably not
a good idea to have those in a public header. This shouldn't be a big
deal, as long as we take care of changing the threshold checks (as in
gobject property max values) when we add a new item to the enumeration.

I didn't touch the MM_ERROR_MODEM values. This is currently the only
thing that is kind of duplicated: in the introspection API and in the
daemon code itself (actually, found that the errors in the API are
outdated w.r.t the ones in the core). Will see if I can find an easy way
of maintaining all in a single place.

The work is ready for review in the 'common-header-autogenerated' branch
in the following git repo:
I'll keep on with libmm-glib based on that branch.

Cheers,

--
Aleksander

_______________________________________________
networkmanager-list mailing list
networkmanager-list gnome org
http://mail.gnome.org/mailman/listinfo/networkmanager-list




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]