This reverts commit e5934962bd55970c54b399351559e90d02b75b6b.
It never worked on 10.5 (but worked for >10.5) actually due to xsltproc
and make's "Circular dependency dropped" issues.
Change-Id: I8770d99a86deb5276bf28dc38da8a5165426e1ef
Reviewed-on: https://gerrit.libreoffice.org/9958
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
Use $FRAMEWORKSHOME instead of /Developer/SDKs/MacOSX${with_macosx_sdk}.sdk/System/Library/Frameworks.
As of Xcode 5.0, Python has been moved outside the SDK, so it doesn't provide the Python framework.
Now we have to use common unix parameters unlike older versions of Xcode.
It is described in the technical note TN2328.
Change-Id: Ib2a010e7c3839a8906acb2453c90ef2bd2f258d7
Reviewed-on: https://gerrit.libreoffice.org/9926
Reviewed-by: Norbert Thiebaud <nthiebaud@gmail.com>
Tested-by: Norbert Thiebaud <nthiebaud@gmail.com>
/usr/libexec/java_home helps to set the current JDK_HOME.
Actually JDK_HOME should NOT be set where java (/usr/bin/java) is located.
AC_PATH_PROG(JAVAINTERPRETER, $with_java) returns /usr/bin/java.
/usr/bin/java -> /System/Library/Frameworks/JavaVM.framework/Versions/Current/Commands/java.
Change-Id: Ie3166731c1525f5b44414fa4dda642edb9408757
Reviewed-on: https://gerrit.libreoffice.org/9960
Tested-by: Norbert Thiebaud <nthiebaud@gmail.com>
Reviewed-by: Norbert Thiebaud <nthiebaud@gmail.com>
We prolly need to look at iODBC and how to carry the headers
as 'external'
Note the dylib for runtime are still in 10.9
Change-Id: I6cad2b90fcb61b5787c0599e40d48a74b8ff917a
(What I have on OS X 10.9 $FRAMEWORKSHOME/JavaVM.framework/Headers, but that
should already be covered by the preceding
$FRAMEWORKSHOME/JavaVM.framework/Versions/Current/Headers.)
Also, fix up 359ba1dfdf8de1f2cff185f16ec21b6dc88feac9 "OS X: JDK include path
for JDK 1.8" to not set JAVAINC twice.
Change-Id: I83c0cdc33ada897fcf8b79fb8df737af26687aa6
Reviewed-on: https://gerrit.libreoffice.org/9931
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
Building:
- The new tarball has reasonable build system so
build libgltf as external package instead of compiling
source files directly.
- Freetype dependancy is removed
Improvements comes with the new libgltf
- Can rotate the models too (orbit mode)
- Two camera handling mode: walkthrough and orbit
(press M to change).
- gltf_animation_set_time() works
- FPS can be displayed without freetype (press F)
Additional notes:
- There were some bugs/regressions which are fixed
during the integration (see patches).
- License files are uddated now.
- libgltf building is enabled only on those platforms
on which gltf support actually works (windows and linux)
Change-Id: Ia6c9c4da53a9b4fedba0d73aa5791489f8ad424b
Reviewed-on: https://gerrit.libreoffice.org/9895
Reviewed-by: Zolnai Tamás <zolnaitamas2000@gmail.com>
Tested-by: Zolnai Tamás <zolnaitamas2000@gmail.com>
apache commons-lang 3.3.1 and commons-codec 1.9 are for use
only with JDK 1.6 and higher
see commits:
1731f6e692bb0a07a2bca4b1b190163f209d2b9e "bump apache-commons-lang to 3.3.1"
3dad9b1019bebcc6db63a424afa146e007f768d2 "bump apache-commons-codec to 1.9"
Change-Id: I3e71f6474becafe6c91836bbac5c6a8b7ca3442c
Reviewed-on: https://gerrit.libreoffice.org/9312
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
It won't be used for now, anyway, as libgltf is used only in avmedia and we
don't build any avmedia for Android. But just to make sure the code stays
portable.
Change-Id: I7a4e5ee3d22f28a407d400a65a1704c23dcb1107
Fix build error on windows with --enable-dbgutil autogen.sh option.
We need to link freetype248_D.lib,when we use --enable-dbgutil option.
(Suffix "_D" is needed.)
Change-Id: Ib2927e777d9b9bb615e1df62e428cf17cc8bc26e
Reviewed-on: https://gerrit.libreoffice.org/9248
Tested-by: Michael Stahl <mstahl@redhat.com>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
plus further work in i18npool to make that build
adapt i18npool to ICU 53 upgrade, fdo#77071
Korean charset collator can't be built from ko_charset.txt because of
"The runtime code decomposes Hangul syllables on the fly, with recursive
processing but without making the Jamo pieces visible for matching. It
does not work with certain types of contextual mappings."
"While handling a Hangul syllable, contractions starting with Jamo L or
V would not see the following Jamo of that syllable." (this is where we
bail out already with the first syllable of ko_charset.txt)
Another condition to fail is described as "A contraction ending with
Jamo L or L+V would require generating Hangul syllables in
addTailComposites() (588 for a Jamo L), or decomposing a following
Hangul syllable on the fly, during contraction matching."
Excluded the file from the build for ICU >=53 and hope that ICU in the
mean time handles Korean collation correctly.
Additionally, ICU 53 took ages (if it would had finished at all) to
build the collator from zh_TW_charset.txt because of the \u#### escaped
notation. Converted the file's content to characters using
http://www.rishida.net/tools/conversion/
Change-Id: I64213214b4870e7077f72b95fee1ddc9782c2b21
Reviewed-on: https://gerrit.libreoffice.org/9204
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Eike Rathke <erack@redhat.com>
