Age | Commit message (Collapse) | Author |
|
Change-Id: I28e4d96fb48420a19e51d52b89895625e7f9ba93
|
|
Change-Id: I0b370ac227bbd833078804d8a276b48666df734c
|
|
Change-Id: I39c880e8615b164a66eb900c11b26da9d6489e02
|
|
Change-Id: I I7d0de9bc04c26e71c6bd915a659a15c3e1f712d2
|
|
Change-Id: I08897ea5527e7ac56b37855b740a3dc1c8ddb544
|
|
... the output of "svninfo" in a directory that doesn't contain a .svn
changed
Change-Id: I16b132663a7c8d9fd60eafafecfc7f9e82b69b29
|
|
Change-Id: I6a178f7ff9c8306e15bcfa847ad1e5e4f8476504
|
|
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
|
|
|
|
|
|
...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.
|
|
pyuno.dylib)"
This reverts those parts of commit f892f979ce17c70ccff5c802db17f24129628504
that add .dylib as an extension for native Python modules, which in turn was
obsoleted by 2ea723e8ce4077c7efa957d278637c4d9f32cf14 "Revert 'Mac OS X uses
.dylib and not .so for python modules.'" (and I verified on Mac OS X 10.6.8
that both LO's internal Pyton 2.6.1 and MacPort's python3.2 indeed import a
pyuno.so just fine).
There were additional modifications regarding pyversion stuff in the original
commit f892f979ce17c70ccff5c802db17f24129628504 that appear unrelated and which
I left intact.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
fixes #i111496# (meta), #i111498# & #i111500#
(along with the similar commits to the other repos)
|
|
please guys'n'gals:
Use dmake create_patch when updating/creating new patches. And when
replacing patches instead of adding ones, use solenv/bin/patch_sanitizer.pl
|
|
|
|
I don't know if this is the right thing to do. The --disable-python
switch is documented to "Disable build of Python 2.x UNO API". Does
that mean that it should disable use of Python at run-time completely?
What about use of Python tools at build-time, do we have such? Will
--disable-python then disable their use, too?
|
|
|
|
Conflicts:
berkeleydb/makefile.mk
|
|
|
|
Conflicts:
python/makefile.mk
zlib/makefile.mk
|
|
|
|
Conflicts:
graphite/makefile.mk
libxml2/makefile.mk
|
|
|
|
trick python configure into thinking it sees Solaris 10
(transplanted from 6402ce7b0667b255e70c517c4320ecaee2682c56)
|
|
Conflicts:
boost/aliasing.patch
boost/makefile.mk
cairo/cairo/makefile.mk
cairo/pixman/makefile.mk
dictionaries/da_DK/README_th_da_DK.txt
dictionaries/da_DK/description.xml
dictionaries/da_DK/dictionaries.xcu
dictionaries/da_DK/makefile.mk
dictionaries/da_DK/th_da_DK.dat
dictionaries/de_AT/th_de_AT_v2.idx
dictionaries/de_CH/th_de_CH_v2.idx
dictionaries/de_DE/COPYING
dictionaries/de_DE/COPYING_GPLv2
dictionaries/de_DE/COPYING_GPLv2.txt
dictionaries/de_DE/README_extension_owner.txt
dictionaries/de_DE/README_th_de_DE_v2.txt
dictionaries/de_DE/makefile.mk
dictionaries/de_DE/th_de_DE_v2.idx
icu/makefile.mk
moz/makefile.mk
python/makefile.mk
|
|
|
|
|
|
When building (in the LibreOffice sense) for Windows with debug=t, use
the Debug solution configuration, but make the Debug project
configutations produce identically named executables as the Release
ones, and also use the normal runtime library.
Use same executables names
|
|
Don't bother commenting out stuff we don't want in the pcbuild.sln
file. Instead just remove it. Don't bother patching files specific for
older MSVS versions that we don't support any more.
|
|
|
|
|
|
+ backported two fixes from newer python:
+ close the file even if an exception occurs (py#5536)
+ urllib doesn't correct server returned urls (py#918368)
+ thanks karolus <karlooforum at arcor dot de> for analyzing and suggesting
the fix
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|