lo/core - LibreOffice 核心代码仓库

Age	Commit message (Collapse)	Author
2012-07-28	Revert "Avoid confusion in 10.7 SDK headers in at least Xcode45-DP3"	Tor Lillqvist
	Nah, don't bother going down this path for now, just require max-allowed to be equal to the SDK version... This reverts commit abf0ff683bc87fe6b2d88df0ae101d89740d6238. Change-Id: I0a3d765533866dad6bf604b1ebbfaef9e168f667
2012-07-23	Avoid confusion in 10.7 SDK headers in at least Xcode45-DP3	Tor Lillqvist
	When building with MAC_OS_X_VERSION_MAX_ALLOWED < MAC_OS_X_VERSION_10_7, <CoreData/NSFetchRequest.h> does #define NSPersistentStoreRequest NSObject (i.e. as a dummy) and does not import <CoreData/NSPersistentStoreRequest.h>. But <CoreData/NSIncrementalStore.h> doesn't do anything similar, it imports <CoreData/NSPersistentStoreRequest.h> unconditionally. So if <CoreData/NSFetchRequest.h> has already been included by then, it will end up quite confusing. Change-Id: I9de6885ea444a73bf5fd50aa6a3d132b9fcc2f31
2012-04-29	make gbuild the default assumption of build.pl	Bjoern Michaelsen
	this removes dmake completely out of the build for migrated modules build.pl now assumes modules to be gbuild, unless there is a prj/dmake file Change-Id: I674a036b182ee13c5ec093e83cb3d38133112d3b
2012-03-24	help XCode 2.5 resolve @loader_path/libfoo.dylib	Christian Lohmaier

2012-03-23	.lst files don't need executable bits	Michael Stahl

2012-03-21	chmod -x	Tor Lillqvist

2012-02-29	Simplify install name handling for external libraries on Mac OS X	Stephan Bergmann
	...by allowing our special @___... tokens anywhere within an install name, so that external modules can configure --prefix=/@___... etc. This removes the need for the special extshl and EXTRPATH=LOADER. Also, a new OUT2BIN_NONE can be used for external modules where the generated libraries need the default EXTRPATH=OOO, but generated executables are only used during the build and such need RPATH=NONE.
2011-10-03	Fix build against the MacOSX 10.6 SDK but with 10.4 as the highest used API	Tor Lillqvist

2011-08-31	Escaped non-ASCII characters from source files in pango	Takashi Nakamoto
	Building pango with VC++ 2008 Express Edition on Windows platform where the locale is Japanese (or maybe Korean, Chinese or others) fails because some files extracted from the pango tarball contains non-ASCII characters. This change escapes those non-ASCII characters with "\xff" expression.
2011-08-04	I'm sure I fixed this before	Caolán McNamara

2011-06-14	silence pango, get rid of $/ escapes, pass verbosity switches	Christian Lohmaier

2011-06-07	Add cross-compilation support	Tor Lillqvist

2011-06-03	Use unique Pango DLL names to avoid risk clashing with "official" DLLs	Tor Lillqvist

2011-06-03	Drop %_EXT% which was always empty	Tor Lillqvist

2011-05-31	Set also CXXFLAGS	Tor Lillqvist

2011-05-30	Propagate verbosity	Tor Lillqvist

2011-04-01	ooo340libs: needed patch changes for external libraries/using ↵	ka
	external/jpeg*.h again
2011-03-30	masterfix DEV300: #i10000# build fixes	Ivo Hinkelmann
	Notes: split repo tag: libs-extern-sys_ooo/DEV300_m105
2011-03-29	rsvglibs: final touches	Philipp Lohmann [pl]

2011-03-28	rsvglibs: adjustments for external library patches	ka

2011-03-28	rsvglibs: minor adjustments wrt. new/updated external libs	ka

2011-03-26	rsvglibs: corrected dependencies	ka

2011-03-26	rsvglibs: added external pango library	ka

2011-03-25	rsvglibs: adjusted makefiles to build external rsvglib dependencies	ka

2011-03-01	rsvglibs: add pango dependency	Philipp Lohmann [pl]