view libpurple/win32/rules.mak @ 30288:a81d44a11d99

If SASL authentication fails, we generally shouldn't be setting an error message, as the actual error was communicated via the "urn:ietf:params:xml:ns:xmpp-sasl" failure stanza. Setting an error means that jabber_auth_handle_failure() won't ever call jabber_parse_error() to extract the actual error message and interpretation. For example, if authentication fails, previously we would show "SASL authentication failed" and think it was a PURPLE_CONNECTION_ERROR_NETWORK_ERROR which is incorrect. Now, jabber_parse_error() gets a chance to return "Not Authorized", clear the saved password, and return PURPLE_CONNECTION_ERROR_AUTHENTICATION_FAILED. We should still set this error message if there is an internal SASL failure leading to SASL_BADPARAM or SASL_NOMEM.
author Evan Schoenberg <evan.s@dreskin.net>
date Tue, 04 May 2010 01:46:40 +0000
parents 1d6b962dea92
children 62f0988c666c
line wrap: on
line source

# Rules on how to make object files from various sources

%.o: %.c
	$(CC) $(CFLAGS) $(DEFINES) $(INCLUDE_PATHS) -o $@ -c $<

%.c: %.xs
	$(PERL) -MExtUtils::ParseXS -e 'ExtUtils::ParseXS::process_file(filename => "$<", output => "$@", typemap => "$(PURPLE_PERL_TOP)/common/typemap");'

%.o: %.rc
	$(WINDRES) -I$(PURPLE_TOP) -i $< -o $@