view po/Makefile.mingw @ 23995:85bed17fe5c1

The variable we use to keep track of the watcher of the ssl connection should be unsigned. This isn't really a problem in Pidgin, where we use glib's mainloop and GIOChannels because glib starts assigning the handle IDs sequentially starting from 1. But if an eventloop implementation ever returns a handle ID greater than the largest possible signed integer (2,147,483,647) then we won't be able to remove the watcher because purple_ssl_close() in sslconn.c only removes it if inpa > 0, and since it interprets inpa as a signed value then handles over 2,147,483,647 appear as negative numbers. I stumbled upon this when playing around with libevent, which can use epoll. My implementation generated a random handle ID which was sometimes greater than 2,147,483,647. I don't believe this breaks binary compatibility. And I don't think it breaks source compatibility, but I guess it might depend on what compiler you're using.

# Makefile.mingw
#
# Description: Makefile to generate mo files
#

PIDGIN_TREE_TOP := ..
include $(PIDGIN_TREE_TOP)/libpurple/win32/global.mak

PACKAGE = pidgin

.SUFFIXES:
.SUFFIXES: .po .gmo

##
## SOURCES, OBJECTS
##

CATALOGS = $(patsubst %.po,%.gmo,$(wildcard *.po))

##
## RULES
##

.po.gmo:
	rm -f $@ && $(GMSGFMT) --statistics -o $@ $<

##
## TARGETS
##

.PHONY: all install clean

all: $(CATALOGS)

install: all
	mkdir -p $(PURPLE_INSTALL_PO_DIR)
	@catalogs='$(CATALOGS)'; \
	for cat in $$catalogs; do \
	  cat=`basename $$cat`; \
	  lang=`echo $$cat | sed 's/\.gmo$$//'`; \
	  dir=$(PURPLE_INSTALL_PO_DIR)/$$lang/LC_MESSAGES; \
	  mkdir -p $$dir; \
	  if test -r $$cat; then \
	    cp $$cat $$dir/$(PACKAGE).mo; \
	    echo "installing $$cat as $$dir/$(PACKAGE).mo"; \
	  else \
	    cp $(PURPLE_PO_TOP)/$$cat $$dir/$(PACKAGE).mo; \
	    echo "installing $(PURPLE_PO_TOP)/$$cat as" \
		 "$$dir/$(PACKAGE).mo"; \
	  fi; \
	done

clean:
	rm -f *.gmo