> > > 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. -- Aleksander _______________________________________________ networkmanager-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/networkmanager-list
