I think that looks great. -Jason On Wed, Aug 17, 2011 at 10:40 AM, Aleksander Morgado <[email protected]>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: > git://gitorious.org/aleksander/modemmanager.git > > I'll keep on with libmm-glib based on that branch. > > Cheers, > > -- > Aleksander > > _______________________________________________ > networkmanager-list mailing list > [email protected] > http://mail.gnome.org/mailman/listinfo/networkmanager-list > >
_______________________________________________ networkmanager-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/networkmanager-list
