Marcin Mikołajczak napisał(a):
> Otóż jestem bardzo zainteresowany przechwytywaniem debuga, co więcej,
> jestem nawet gotów zgłosić się na ochotnika i poprzerabiać kod, żeby
> handler dostawał gg_session* na sesję, której dotyczy dany komunikat
> (wtedy by to nawet było przydatne). Pod warunkiem oczywiście, że ktoś mi
> powie czym i jak potem wygenerować patcha, żeby sobie maintenerzy łatwo
> do CVS-a wrzucili :-)
Jeśli pobierasz kod z CVS, to wystarczy wydać polecenie:
cvs diff -u > plik.diff
Jeśli łatwiej Ci poprawiać kod z archiwów ze strony, skopiuj katalog
libgadu-1.7.0.orig do libgadu-1.7.0, popraw kod w libgadu-1.7.0, a potem
katalog wyżej wydaj polecenie:
diff -ur libgadu-1.7.0.orig libgadu-1.7.0 > plik.diff
Zwykle daje się parametry -uNr, które powodują dołączenie nowych plików,
ale Ty pewnie nowych nie utworzysz, a całe mnóstwo plików wygenerowanych
przez configure zaśmieciłoby patcha.
> W sensie żeby takie coś było:
>
> extern void (*gg_debug_handler)(gg_session* session, int level, const
> char *format, va_list ap);
>
> Tak, jestem świadom, że to wymaga poprawienia gg_debug i wszystkich jego
> wywołań. Więc gdybyśmy tu coś postanowili w sprawie przyszłości debuga w
> libgadu, to mogę być tym od czarnej roboty, który to wcieli w życie :-)
>
> Aha, czy tego używa ekg? Bo jest jeszcze kwestia kompatybilności wstecz...
Szczerze mówiąc, mimo ,,nieoficjalności'' gg_debug_handler, wolałbym
zachować istniejący interfejs i mieć osobną funkcję gg_debug_session()
do debugowania danej sesji, która wywoływałaby...
extern void (*gg_debug_handler_session)(struct gg_session* session,
int level, const char *format, va_list ap);
...a w razie braku powyższego, zwyczajne gg_debug_handler(). Podobnie
gg_debug() mogłoby spróbować wywołać gg_debug_handler_session() z NULL
zamiast sesji, a w razie braku zachowywać się jak do tej pory. Co Ty na to?
Pozdrawiam,
Wojtek
_______________________________________________
libgadu-devel mailing list
[email protected]
http://lists.ziew.org/mailman/listinfo/libgadu-devel
