On Wed, 2011-08-17 at 10:55 -0400, Jason Glasgow wrote: > I think that looks great. -Jason
Yeah, looks good to me too. Dan > 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
