Re: [ft-devel] Time for a new FreeType release

[Felipe Sanches]

Fell free to do so. I did that quickly as a sketch. I'm sure it can be
improved a lot. But the whole point is that meson seems to make it all
pretty much straightforward and easy to read / understand / maintain.
That's where its real value seems to be. :-)

2018-04-09 20:57 GMT-03:00 Nikolaus Waxweiler :

> If I feel like it, I may soup up Felipe's meson file.
>
> ___
> Freetype-devel mailing list
> Freetype-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/freetype-devel
>
>
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Time for a new FreeType release

[Nikolaus Waxweiler]

If I feel like it, I may soup up Felipe's meson file.
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Time for a new FreeType release

[Parth Wazurkar]

On Tue, Apr 3, 2018 at 8:34 PM, Werner LEMBERG  wrote:

>
>
> > why not uing meson ?
>
> >If someone is contributing Meson support...
>
Are there any plans of using Meson for FreeType?

>
> Werner
>
> ___
> Freetype-devel mailing list
> Freetype-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/freetype-devel
>

‌
[image: Mailtrack]

Sender
notified by
Mailtrack

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Time for a new FreeType release

[Werner LEMBERG]

> Oh and, how do you want me to commit the stuff? One big commit or all
> nicely broken up?

As Alexei answered already: It's basically up to you.  However, you've
shown us small chunks, which is good, so simply use them.

> And by ChangeLog you mean the file, not that I should rewrite my
> commit messages?

Both.  The normal way is to write a ChangeLog entry, then using it as
a commit message (removing leading whitespace, and without name and
e-mail address) while doing `git commit'.

I know it's extra work to write ChangeLog entries, but it ensures that
the entries have a good quality.  It's far too easy to write `git
commit', entering a sloppy commit message.


Werner

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Time for a new FreeType release

[Werner LEMBERG]

> By the way, is the "Require.private" thing in the pkg-config file
> strictly required?

Yes.  It ensures that you get all dependencies for static linking.


Werner

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Time for a new FreeType release

[Alexei Podtelezhnikov]

On Sun, Apr 8, 2018 at 6:15 PM, Nikolaus Waxweiler 
wrote:

> Oh and, how do you want me to commit the stuff? One big commit or all
> nicely broken up?
>
> And by ChangeLog you mean the file, not that I should rewrite my commit
> messages?


We always duplicate commit messages in the ChengeLog, which should be
strictly formatted. If you like the path you took to your final
CMakeList.txt, then commit it with better logging, or take a different
path. Your call.
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Time for a new FreeType release

[Nikolaus Waxweiler]

Oh and, how do you want me to commit the stuff? One big commit or all 
nicely broken up?


And by ChangeLog you mean the file, not that I should rewrite my commit 
messages?


___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Time for a new FreeType release

[Nikolaus Waxweiler]

You've apparently registered two names, according to the Savannah user
management...


Oh. Yes, I vaguely remember something.

By the way, is the "Require.private" thing in the pkg-config file 
strictly required?


___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Time for a new FreeType release

[Werner LEMBERG]

>> Nikolaus, I've just given you write permission to the FreeType
>> repositories (user `madleser').  Please commit the CMake stuff,
>> together with proper ChangeLog entries.
> 
> Uh, but my Savannah user name is "morksig"?

You've apparently registered two names, according to the Savannah user
management...

Changed to `morksig'.


Werner

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Time for a new FreeType release

[Nikolaus Waxweiler]

Nikolaus, I've just given you write permission to the FreeType
repositories (user `madleser').  Please commit the CMake stuff,
together with proper ChangeLog entries.


Uh, but my Savannah user name is "morksig"?

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Time for a new FreeType release

[Tom Kacvinsky]

What I was thinking of doing is finalizing the work necessary to get a
symbol versioning linker script in place, but it is not necessary for this
release.  It is just a "nice to have"

So I'd say the lack of such feature won't delay the release.

On Sun, Apr 8, 2018 at 11:37 AM, Nikolaus Waxweiler 
wrote:

> Do you mean there's something else to do for versioning?
>
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Time for a new FreeType release

[Nikolaus Waxweiler]

Do you mean there's something else to do for versioning?
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Time for a new FreeType release

[Tom Kacvinsky]

Hi,

I dropped the ball.  I meant to get to the symbol versioning stuff we
talked about so we'd have it for this release, but I've been swamped
with work.

Tom

On Sun, Apr 8, 2018 at 9:21 AM, Werner LEMBERG  wrote:

>
> > Got it working :) Tested with CMake 3.10.2 on Win 10 x64. Version
> > and copyright information was shown in the details tab of the file
> > properties dialog.
>
> Great!
>
> Nikolaus, I've just given you write permission to the FreeType
> repositories (user `madleser').  Please commit the CMake stuff,
> together with proper ChangeLog entries.
>
>
> Werner
>
> ___
> Freetype-devel mailing list
> Freetype-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/freetype-devel
>
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Time for a new FreeType release

[Werner LEMBERG]

> Got it working :) Tested with CMake 3.10.2 on Win 10 x64. Version
> and copyright information was shown in the details tab of the file
> properties dialog.

Great!

Nikolaus, I've just given you write permission to the FreeType
repositories (user `madleser').  Please commit the CMake stuff,
together with proper ChangeLog entries.


Werner

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Time for a new FreeType release

[Nikolaus Waxweiler]

Got it working :) Tested with CMake 3.10.2 on Win 10 x64. Version and
copyright information was shown in the details tab of the file
properties dialog.


0001-CMakeLists.txt-Use-ftver.rc-on-Windows.patch
Description: Binary data
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Time for a new FreeType release

[Nikolaus Waxweiler]

This is still bloody recent (four years) compared to the currently
needed version 2.6 (nine years)...


Given that you don't have to provide support for contributed build 
systems, that shouldn't be too bad :)


The GNUInstallDirs macro became available only in 2.8.5. It is 
unfortunate that CMake only became good in the last few years, but such 
is life.


___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Time for a new FreeType release

[Werner LEMBERG]

> Fun fact: CMake 2.8.11 doesn't know about the C_VISIBILITY_PRESET
> property, so you'd have to specify the compiler flags yourself.  I
> don't want to bother.  The property came with 2.8.12.

This is still bloody recent (four years) compared to the currently
needed version 2.6 (nine years)...

> I think I'm simply going to raise the minimum to 2.8.12. That way, I
> can also get rid of some ifelse.

OK.


Werner

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Time for a new FreeType release

[Alexei Podtelezhnikov]

On Sat, Apr 7, 2018 at 5:29 PM, Nikolaus Waxweiler 
wrote:

> What's that ftver.rc file even for? Is it needed?
>

It decorates DLL with a resource so that its version and copyright is
displayed in File Properties or when you hover over the file in Windows.
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Time for a new FreeType release

[Nikolaus Waxweiler]

Continued and tested on CMake 2.8.12.
>From d7f090759a0389ef9da2bcce684c30ff0e35e38e Mon Sep 17 00:00:00 2001
From: Nikolaus Waxweiler 
Date: Sun, 8 Apr 2018 01:29:28 +0100
Subject: [PATCH 1/3] FindHarfBuzz.cmake: Make work on CMake 2.8.12; export
 library on >= 3.1

Modern CMake Find* files export a library that targets can be simply
linked against without messing with definitions, include directories,
etc. Make such a library available in CMake >= 3.1 should we switch to
it one day.
---
 builds/cmake/FindHarfBuzz.cmake | 20 
 1 file changed, 16 insertions(+), 4 deletions(-)

diff --git a/builds/cmake/FindHarfBuzz.cmake b/builds/cmake/FindHarfBuzz.cmake
index c8444d325..96ecfd9a2 100644
--- a/builds/cmake/FindHarfBuzz.cmake
+++ b/builds/cmake/FindHarfBuzz.cmake
@@ -54,16 +54,28 @@ if (HARFBUZZ_INCLUDE_DIRS)
 endif ()
 endif ()
 
-if ("${Harfbuzz_FIND_VERSION}" VERSION_GREATER "${HARFBUZZ_VERSION}")
+if ("${harfbuzz_FIND_VERSION}" VERSION_GREATER "${HARFBUZZ_VERSION}")
 message(FATAL_ERROR "Required version (" ${Harfbuzz_FIND_VERSION} ") is higher than found version (" ${CAIRO_VERSION} ")")
 endif ()
 
 include(FindPackageHandleStandardArgs)
-FIND_PACKAGE_HANDLE_STANDARD_ARGS(Harfbuzz REQUIRED_VARS HARFBUZZ_INCLUDE_DIRS HARFBUZZ_LIBRARIES
-   VERSION_VAR HARFBUZZ_VERSION)
+FIND_PACKAGE_HANDLE_STANDARD_ARGS(
+harfbuzz 
+REQUIRED_VARS HARFBUZZ_INCLUDE_DIRS HARFBUZZ_LIBRARIES
+VERSION_VAR HARFBUZZ_VERSION)
 
 mark_as_advanced(
 HARFBUZZ_INCLUDE_DIRS
 HARFBUZZ_LIBRARIES
-HARFBUZZ_ICU_LIBRARIES
 )
+
+# Allows easy linking as in 
+#   target_link_libraries(freetype PRIVATE Harfbuzz::Harfbuzz)
+if (NOT CMAKE_VERSION VERSION_LESS 3.1)
+if (HARFBUZZ_FOUND AND NOT TARGET Harfbuzz::Harfbuzz)
+add_library(Harfbuzz::Harfbuzz INTERFACE IMPORTED)
+set_target_properties(
+Harfbuzz::Harfbuzz PROPERTIES
+INTERFACE_INCLUDE_DIRECTORIES "${HARFBUZZ_INCLUDE_DIRS}")
+endif ()
+endif ()
-- 
2.14.3

>From 06501fad9fa6fb94e869c8ae72d22492d7ba2c1c Mon Sep 17 00:00:00 2001
From: Nikolaus Waxweiler 
Date: Sun, 8 Apr 2018 01:30:04 +0100
Subject: [PATCH 2/3] CMakeLists.txt: Remove package_source reference

We removed source packaging.
---
 CMakeLists.txt | 4 
 1 file changed, 4 deletions(-)

diff --git a/CMakeLists.txt b/CMakeLists.txt
index 63caaac7e..1503551a9 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -47,10 +47,6 @@
 #
 #   cmake --build build --config Release --target package
 #
-# A source distribution can be made with
-#
-#   cmake --build build --target package_source
-#
 # Please refer to the cmake manual for further options, in particular, how
 # to modify compilation and linking parameters.
 #
-- 
2.14.3

>From e427681d95d99701ef67c65ea0216eaeef30e807 Mon Sep 17 00:00:00 2001
From: Nikolaus Waxweiler 
Date: Sun, 8 Apr 2018 01:33:44 +0100
Subject: [PATCH 3/3] CMakeLists.txt: Raise minimum version to 2.8.12

The first version to support the  C_VISIBILITY_HIDDEN property.
Necessary for a shared object that only exports explicitly marked APIs.
CMake >= 3.3 will also allow to set the property on static builds.

Minor clean-up of target_link_libraries() as 2.8.12 allows PRIVATE.

Minor clean-up of target_include_directories() as 2.8.12 allows the
INSTALL_INTERFACE generator expression.
---
 CMakeLists.txt | 41 ++---
 1 file changed, 18 insertions(+), 23 deletions(-)

diff --git a/CMakeLists.txt b/CMakeLists.txt
index 1503551a9..0470168e8 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -79,14 +79,16 @@
 #   (this is compatible with the same CMake variables in zlib's CMake
 #   support).
 
-# FreeType is build as part of the Python binding freetype-py. Python
-# extensions for Linux are usually compiled against the manylinux1 target (PEP
-# 513); the Manylinux1 Docker container provided by PyPa happens to contain a
-# CentOS 5.11 with cmake 2.8.11.2 installed. Raising the minimum version makes
-# sure this requirement is actually tested.
-cmake_minimum_required(VERSION 2.8.11.2)
-# Allow symbol visibility settings also on static libraries.
-cmake_policy(SET CMP0063 NEW)
+# FreeType explicitly marks the API to be exported and relies on the compiler
+# to hide all other symbols. CMake supports a C_VISBILITY_PRESET property
+# starting with 2.8.12.
+cmake_minimum_required(VERSION 2.8.12)
+
+if (NOT CMAKE_VERSION VERSION_LESS 3.3)
+  # Allow symbol visibility settings also on static libraries. CMake < 3.3
+  # only sets the propery on a shared library build.
+  cmake_policy(SET CMP0063 NEW)
+endif ()
 
 include(CheckIncludeFile)
 
@@ -345,6 +347,9 @@ target_include_directories(
   freetype
 PRIVATE "${PROJECT_SOURCE_DIR}/include")
 
+target_include_directories(
+  freetype
+PUBLIC $)
 
 if (BUILD_FRAMEWORK)
   set_property(SOURCE ${PUBLIC_CONFIG_HEADERS}
@@ -358,32 +363,22 @@ if (BUILD_FRAMEWORK)
   )
 endif ()
 
-if (NOT CMAKE

Re: [ft-devel] Time for a new FreeType release

[Nikolaus Waxweiler]

Fun fact: CMake 2.8.11 doesn't know about the C_VISIBILITY_PRESET 
property, so you'd have to specify the compiler flags yourself. I don't 
want to bother. The property came with 2.8.12.


I think I'm simply going to raise the minimum to 2.8.12. That way, I can 
also get rid of some ifelse.


___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Time for a new FreeType release

[Nikolaus Waxweiler]

Nice :)

1. I found that I can use 'bzip2' as a dependency on Fedora 27. Saves 
the external module.

2. Why explicitly a static_library? This should be a user option.

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Time for a new FreeType release

[Nikolaus Waxweiler]

Still missing: pkg-config file

Alexei: What's that ftver.rc file even for? Is it needed?
>From 428af497d42d3d34c85c4b04dda250f983b55bec Mon Sep 17 00:00:00 2001
From: Nikolaus Waxweiler 
Date: Sat, 7 Apr 2018 21:34:24 +0100
Subject: [PATCH 01/19] Add build/ to .gitignore

Used in the CMake invocation examples.
---
 .gitignore | 1 +
 1 file changed, 1 insertion(+)

diff --git a/.gitignore b/.gitignore
index b5db9d874..a47f568e6 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,2 +1,3 @@
 config.mk
 objs/vc2010/
+build
-- 
2.14.3

>From f87f9ed99129db26c6dcad6677bd417bcf1c82af Mon Sep 17 00:00:00 2001
From: Nikolaus Waxweiler 
Date: Sat, 7 Apr 2018 21:35:10 +0100
Subject: [PATCH 02/19] Update FindHarfBuzz.cmake: Do not look for and link
 against icu library

---
 builds/cmake/FindHarfBuzz.cmake | 45 +++--
 1 file changed, 21 insertions(+), 24 deletions(-)

diff --git a/builds/cmake/FindHarfBuzz.cmake b/builds/cmake/FindHarfBuzz.cmake
index f394b82bf..c8444d325 100644
--- a/builds/cmake/FindHarfBuzz.cmake
+++ b/builds/cmake/FindHarfBuzz.cmake
@@ -31,42 +31,39 @@
 # HARFBUZZ_LIBRARIES - containg the HarfBuzz library
 
 include(FindPkgConfig)
+pkg_check_modules(PC_HARFBUZZ QUIET harfbuzz)
 
-pkg_check_modules(PC_HARFBUZZ harfbuzz>=0.9.7)
-
-find_path(HARFBUZZ_INCLUDE_DIRS NAMES hb.h
-HINTS ${PC_HARFBUZZ_INCLUDE_DIRS} ${PC_HARFBUZZ_INCLUDEDIR}
+find_path(HARFBUZZ_INCLUDE_DIRS
+NAMES hb.h
+HINTS ${PC_HARFBUZZ_INCLUDEDIR}
+  ${PC_HARFBUZZ_INCLUDE_DIRS}
+PATH_SUFFIXES harfbuzz
 )
 
 find_library(HARFBUZZ_LIBRARIES NAMES harfbuzz
-HINTS ${PC_HARFBUZZ_LIBRARY_DIRS} ${PC_HARFBUZZ_LIBDIR}
+HINTS ${PC_HARFBUZZ_LIBDIR}
+  ${PC_HARFBUZZ_LIBRARY_DIRS}
 )
 
-# HarfBuzz 0.9.18 split ICU support into a separate harfbuzz-icu library.
-if ("${PC_HARFBUZZ_VERSION}" VERSION_GREATER "0.9.17")
-if (HarfBuzz_FIND_REQUIRED)
-set(_HARFBUZZ_REQUIRED REQUIRED)
-else ()
-set(_HARFBUZZ_REQUIRED "")
-endif ()
-pkg_check_modules(PC_HARFBUZZ_ICU harfbuzz-icu>=0.9.18 ${_HARFBUZZ_REQUIRED})
-find_library(HARFBUZZ_ICU_LIBRARIES NAMES harfbuzz-icu
-HINTS ${PC_HARFBUZZ_ICU_LIBRARY_DIRS} ${PC_HARFBUZZ_ICU_LIBDIR}
-)
-if (HARFBUZZ_ICU_LIBRARIES)
-list(APPEND HARFBUZZ_LIBRARIES "${HARFBUZZ_ICU_LIBRARIES}")
+if (HARFBUZZ_INCLUDE_DIRS)
+if (EXISTS "${HARFBUZZ_INCLUDE_DIRS}/hb-version.h")
+file(READ "${HARFBUZZ_INCLUDE_DIRS}/hb-version.h" _harfbuzz_version_content)
+
+string(REGEX MATCH "#define +HB_VERSION_STRING +\"([0-9]+\\.[0-9]+\\.[0-9]+)\"" _dummy "${_harfbuzz_version_content}")
+set(HARFBUZZ_VERSION "${CMAKE_MATCH_1}")
 endif ()
-set(_HARFBUZZ_EXTRA_REQUIRED_VAR "HARFBUZZ_ICU_LIBRARIES")
-else ()
-set(_HARFBUZZ_EXTRA_REQUIRED_VAR "")
+endif ()
+
+if ("${Harfbuzz_FIND_VERSION}" VERSION_GREATER "${HARFBUZZ_VERSION}")
+message(FATAL_ERROR "Required version (" ${Harfbuzz_FIND_VERSION} ") is higher than found version (" ${CAIRO_VERSION} ")")
 endif ()
 
 include(FindPackageHandleStandardArgs)
-FIND_PACKAGE_HANDLE_STANDARD_ARGS(HarfBuzz DEFAULT_MSG HARFBUZZ_INCLUDE_DIRS
-HARFBUZZ_LIBRARIES ${_HARFBUZZ_EXTRA_REQUIRED_VAR})
+FIND_PACKAGE_HANDLE_STANDARD_ARGS(Harfbuzz REQUIRED_VARS HARFBUZZ_INCLUDE_DIRS HARFBUZZ_LIBRARIES
+   VERSION_VAR HARFBUZZ_VERSION)
 
 mark_as_advanced(
-HARFBUZZ_ICU_LIBRARIES
 HARFBUZZ_INCLUDE_DIRS
 HARFBUZZ_LIBRARIES
+HARFBUZZ_ICU_LIBRARIES
 )
-- 
2.14.3

>From a411396242fb000334eb136ac30397811f69721a Mon Sep 17 00:00:00 2001
From: Nikolaus Waxweiler 
Date: Sat, 7 Apr 2018 21:36:44 +0100
Subject: [PATCH 03/19] CMakeLists: Update invocation examples

Use platform- and build system agnostic examples for configuration and
building.
---
 CMakeLists.txt | 41 +
 1 file changed, 25 insertions(+), 16 deletions(-)

diff --git a/CMakeLists.txt b/CMakeLists.txt
index 32006d3c7..901e3b5bb 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -12,35 +12,44 @@
 # fully.
 #
 #
-# As a preliminary, create a compilation directory and change into it, for
-# example
+# The following will 1. create a build directory and 2. change into it and
+# call cmake to configure the build with default parameters as a static
+# library.
 #
-#   mkdir ~/freetype2.compiled
-#   cd ~/freetype2.compiled
-#
-# Now you can say
-#
-#   cmake 
-#
-# to create a Makefile that builds a static version of the library.
+#   cmake -E make_directory build
+#   cmake -E chdir build cmake ..
 #
 # For a dynamic library, use
 #
-#   cmake -D BUILD_SHARED_LIBS:BOOL=true 
+#   cmake -E chdir build cmake -D BUILD_SHARED_LIBS:BOOL=true ..
 #
 # For a framework on OS X, use
 #
-#   cmake -D BUILD_FRAMEWORK:BOOL=true -G Xcode 
-#
-# instead.
+#   cmake -E chdir build cmake -G Xcode -D BUILD_FRAMEWORK:BOOL=true ..
 #
 # For an iOS static library, use
 #
-#   cmake -D IOS_PLATFORM=OS -G Xcode 
+#   cmake -E chdir b

Re: [ft-devel] Time for a new FreeType release

[Werner LEMBERG]

> I do have an experimental set of meson.build files that I quickly
> wrote and that enable me to build freetype on GNU/Linux

Nice!

> If anyone would like to take a look, I can publish it in my own git
> repo for a review and surely some further improvements.

Thanks.  Note that someone would have to maintain it, and this person
is not me.  In other words, meson build files would be marked as
contributed stuff, to be used at the risk of the user.


Werner

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Time for a new FreeType release

[Werner LEMBERG]

>> Can you be specific which cmake problems you "cleaning up"?
> 
> 1. Add optional external libraries as option()s, more idiomatic than
>just using some defines
> 2. Set some properties not globally, but on the freetype library
>target.  That's neater.
> 3. Minor, mostly cosmetic changes to the CPack options.
> 4. Minor things like using list(append list something) instead of
>set(list $list something)
> 5. Slight changes to the creation of ftconfig.h and ftoptions.h, no
>"-new" file now.
> 6. Adjustments to the installation rules, now uses the
>GNUInstallDirs macro so you can define libdir, includedir
>etc. installation targets like with Autotools.  Should correctly
>install to lib64 now if that's the distro default.

As far as I can see, some of those things can be fixed immediately,
without the need of being discussed.  It would be nice if you could
provide such changes as small, logical patches that I can commit;
doing so would make it *much* easier to understand the remaining, more
controversial adjustments.


Werner

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Time for a new FreeType release

[Felipe Sanches]

here it is ;-)

https://github.com/felipesanches/freetype2/commits/meson_build

2018-04-05 19:29 GMT-03:00 Nikolaus Waxweiler :

> If anyone would like to take a look, I can publish it in my own git repo
>> for a review and surely some further improvements.
>>
>
> I suppose posting it won't hurt :)
>
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Time for a new FreeType release

[Nikolaus Waxweiler]

This is not good. Have you found any difference in actual compile/link 
flags,

or included components, or HarfBuzz integration?


Found the issue: The CMake build did not use -O2 :D Size is now almost 
the same.


It also linked against harfbuzz and harfbuzz-icu.

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Time for a new FreeType release

[Nikolaus Waxweiler]

If anyone would like to take a look, I can publish it in my own git repo 
for a review and surely some further improvements.


I suppose posting it won't hurt :)

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Time for a new FreeType release

[Felipe Sanches]

I do have an experimental set of meson.build files thatthat I quickly wrote
and that enable me to build freetype on GNU/Linux

It may work on Windows as well, but I haven't tested it. And there's surely
lots of other features of the current build system that are still lacking
in this experimental port.

If anyone would like to take a look, I can publish it in my own git repo
for a review and surely some further improvements.

cheers,
felipesanches
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Time for a new FreeType release

[Nikolaus Waxweiler]

(Oh yeah, and the ftver.rc thing and include/freetype/tttags.h are
missing from the source package)


I don't understand this remark.  Please elaborate.


I still need to look at the ftver.rc issue Alexie pointed out. The 
tttags.h file does not show up in the source package you can generate 
with CPack.


___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Time for a new FreeType release

[Nikolaus Waxweiler]

Can you be specific which cmake problems you "cleaning up"?


1. Add optional external libraries as option()s, more idiomatic than 
just using some defines
2. Set some properties not globally, but on the freetype library target. 
That's neater.

3. Minor, mostly cosmetic changes to the CPack options.
4. Minor things like using list(append list something) instead of 
set(list $list something)
5. Slight changes to the creation of ftconfig.h and ftoptions.h, no 
"-new" file now.
6. Adjustments to the installation rules, now uses the GNUInstallDirs 
macro so you can define libdir, includedir etc. installation targets 
like with Autotools. Should correctly install to lib64 now if that's the 
distro default.


This is not good. Have you found any difference in actual compile/link 
flags,

or included components, or HarfBuzz integration?


So far, I have no idea where the difference comes from. I guess I need 
to dig into binutils...



Nobody is going to replace autotools with cmake for any of these tasks.
Please do not bother.


Okay. Is anybody using the CPack thing to make binary or source 
distributions? Otherwise, I can axe that too.



___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Time for a new FreeType release

[Werner LEMBERG]

> (Oh yeah, and the ftver.rc thing and include/freetype/tttags.h are
> missing from the source package)

I don't understand this remark.  Please elaborate.


Werner

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Time for a new FreeType release

[Vincent Torri]

On Wed, Apr 4, 2018 at 1:23 AM, Nikolaus Waxweiler  wrote:
>> Theoretically yes.  However, relying on `FT_CHAR_BIT' is not as reliable as 
>> using the `SIZEOF_INT' and `SIZEOF_LONG' autoconf tests.
>
> Hm. So to unify this, I'd have to use a generic "FT_SIZEOF_LONG == (64
> / FT_CHAR_BIT)" and replace the line wholesale while configureing with
> CMake or Autoconf.

note that on Windows, a long int is always 4 bytes long, contrary to
unix where it depends on the architecture.

Vincent Torri

>
> Please have a look at
> https://github.com/madig/freetype2/commits/modernize-cmake-build.
> Attached is a patch that cleans up quite a bit.
>
> The main differences are that the Autotools build produces 300-400 KB
> smaller shared objects and making a source package will not include
> the reference and obviously the generated Autotools files. A `refdoc`
> and `devel` target are also still missing, as does a pkg-config file.
>
> ___
> Freetype-devel mailing list
> Freetype-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/freetype-devel
>

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Time for a new FreeType release

[Nikolaus Waxweiler]

(Oh yeah, and the ftver.rc thing and include/freetype/tttags.h are
missing from the source package)

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Time for a new FreeType release

[Nikolaus Waxweiler]

> Theoretically yes.  However, relying on `FT_CHAR_BIT' is not as reliable as 
> using the `SIZEOF_INT' and `SIZEOF_LONG' autoconf tests.

Hm. So to unify this, I'd have to use a generic "FT_SIZEOF_LONG == (64
/ FT_CHAR_BIT)" and replace the line wholesale while configureing with
CMake or Autoconf.


Please have a look at
https://github.com/madig/freetype2/commits/modernize-cmake-build.
Attached is a patch that cleans up quite a bit.

The main differences are that the Autotools build produces 300-400 KB
smaller shared objects and making a source package will not include
the reference and obviously the generated Autotools files. A `refdoc`
and `devel` target are also still missing, as does a pkg-config file.
diff --git a/.gitignore b/.gitignore
index b5db9d874..a47f568e6 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,2 +1,3 @@
 config.mk
 objs/vc2010/
+build
diff --git a/CMakeLists.txt b/CMakeLists.txt
index 32006d3c7..067d1983a 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -12,35 +12,44 @@
 # fully.
 #
 #
-# As a preliminary, create a compilation directory and change into it, for
-# example
+# The following will 1. create a build directory and 2. change into it and
+# call cmake to configure the build with default parameters as a static
+# library.
 #
-#   mkdir ~/freetype2.compiled
-#   cd ~/freetype2.compiled
-#
-# Now you can say
-#
-#   cmake 
-#
-# to create a Makefile that builds a static version of the library.
+#   cmake -E make_directory build
+#   cmake -E chdir build cmake ..
 #
 # For a dynamic library, use
 #
-#   cmake -D BUILD_SHARED_LIBS:BOOL=true 
+#   cmake -E chdir build cmake -D BUILD_SHARED_LIBS:BOOL=true ..
 #
 # For a framework on OS X, use
 #
-#   cmake -D BUILD_FRAMEWORK:BOOL=true -G Xcode 
-#
-# instead.
+#   cmake -E chdir build cmake -G Xcode -D BUILD_FRAMEWORK:BOOL=true ..
 #
 # For an iOS static library, use
 #
-#   cmake -D IOS_PLATFORM=OS -G Xcode 
+#   cmake -E chdir build cmake -G Xcode -D IOS_PLATFORM=OS ..
 #
 # or
 #
-#   cmake -D IOS_PLATFORM=SIMULATOR -G Xcode 
+#   cmake -E chdir build cmake -G Xcode -D IOS_PLATFORM=SIMULATOR ..
+#
+# Finally, build the project with:
+#
+#   cmake --build build
+#
+# Install it with
+#
+#   (sudo) cmake --build build --target install
+#
+# A binary distribution can be made with
+#
+#   cmake --build build --config Release --target package
+#
+# A source distribution can be made with
+#
+#   cmake --build build --target package_source
 #
 # Please refer to the cmake manual for further options, in particular, how
 # to modify compilation and linking parameters.
@@ -74,13 +83,17 @@
 #   (this is compatible with the same CMake variables in zlib's CMake
 #   support).
 
-
-cmake_minimum_required(VERSION 2.6)
-
+# FreeType is build as part of the Python binding freetype-py. Python
+# extensions for Linux are usually compiled against the manylinux1 target (PEP
+# 513); the Manylinux1 Docker container provided by PyPa happens to contain a
+# CentOS 5.11 with cmake 2.8.11.2 installed. Raising the minimum version makes
+# sure this requirement is actually tested.
+cmake_minimum_required(VERSION 2.8.11.2)
+# Allow symbol visibility settings also on static libraries.
+cmake_policy(SET CMP0063 NEW)
 
 include(CheckIncludeFile)
 
-
 # CMAKE_TOOLCHAIN_FILE must be set before `project' is called, which
 # configures the base build environment and references the toolchain file
 if (APPLE)
@@ -116,26 +129,47 @@ else ()
 endif ()
 
 
-project(freetype)
+project(freetype C)
+
+set(VERSION_MAJOR "2")
+set(VERSION_MINOR "9")
+set(VERSION_PATCH "0")
+
+# SOVERSION scheme: CURRENT.AGE.REVISION
+#   If there was an incompatible interface change:
+# Increment CURRENT. Set AGE and REVISION to 0
+#   If there was a compatible interface change:
+# Increment AGE. Set REVISION to 0
+#   If the source code was changed, but there were no interface changes:
+# Increment REVISION.
+set(LIBRARY_VERSION "6.16.0")
+set(LIBRARY_SOVERSION "6")
+
+# These options mean "require x and complain if not found". They'll get
+# optionally found anyway. Use `-DCMAKE_DISABLE_FIND_PACKAGE_x=TRUE` to disable
+# searching for a packge entirely (x is the CMake package name, so "BZip2"
+# instead of "BZIP2").
+option(FT_WITH_ZLIB "Use system zlib instead of internal library." OFF)
+option(FT_WITH_BZIP2 "Support bzip2 compressed fonts." OFF)
+option(FT_WITH_PNG "Support PNG compressed OpenType embedded bitmaps." OFF)
+option(FT_WITH_HARFBUZZ "Improve auto-hinting of OpenType fonts." OFF)
 
 
 # Disallow in-source builds
 if ("${PROJECT_BINARY_DIR}" STREQUAL "${PROJECT_SOURCE_DIR}")
   message(FATAL_ERROR
-"
-In-source builds are not permitted!  Make a separate folder for"
-" building, e.g.,"
-"
-  mkdir build; cd build; cmake .."
-"
-Before that, remove the files created by this failed run with"
-"
-  rm -rf CMakeCache.txt CMakeFiles")
+"In-source builds are not permitted!  Make a separate folder for"
+" building, e.g.,\n"
+"  cmake -E mak

Re: [ft-devel] Time for a new FreeType release

[Werner LEMBERG]

>> Maybe it is even possible with GNU make's string functions
> 
> I'm gonna try that, GNU make >= 4.2 supports things like
> ```
> file:=test.txt
> variable:=$(file < $(FILE))
> ```

Please don't use this – version 4.2 is too recent.  Instead, you
should use code similar to

  variable := $(shell $(CAT) $(FILE))

(cf. file `builds/toplevel.mk'), where $(CAT) is either `cat' on UNIX
or `type' on Windows and DOS.

> -#if FT_SIZEOF_INT == ( 32 / FT_CHAR_BIT )
> +#if FT_SIZEOF_INT == 4
> ...
> 
> +  /* we handle the LLP64 scheme separately for GCC and clang, */
> +  /* suppressing the `long long' warning  */
> +#elif ( FT_SIZEOF_LONG == 4 )   && \
> +  defined( HAVE_LONG_LONG_INT ) && \
> +  defined( __GNUC__ )
> +#pragma GCC diagnostic ignored "-Wlong-long"
> +#define FT_LONG64
> +#define FT_INT64   long long int
> +#define FT_UINT64  unsigned long long int
> +
> 
> -#endif /* FT_SIZEOF_LONG == (64 / FT_CHAR_BIT) */
> +#endif /* FT_SIZEOF_LONG == 8 */
> ```
> 
> Shouldn't this be the same in both files?

Theoretically yes.  However, relying on `FT_CHAR_BIT' is not as
reliable as using the `SIZEOF_INT' and `SIZEOF_LONG' autoconf tests.


Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Time for a new FreeType release

[Derek B. Noonburg]

On Tue, 3 Apr 2018 15:41:19 +0100
Chris Liddell  wrote:

> On 03/04/18 15:12, Alexei Podtelezhnikov wrote:
>  We're currently experiencing a problem with FreeType 2.9 in
>  conjunction with Ghostscript.  Some TrueType glyphs are
>  rendering as if the hinting is broken, or points are being
>  moved/dropped.  
> >>
> >> Well, the good news is that the corrupted glyph rendering is
> >> resolved in the current freetype.git HEAD code.
> >>  
> > 
> > This must be bug 52846 .  
> 
> Seems extremely like it - I could bisect, but it didn't seem worth the
> effort.

I ran into this when testing Xpdf with FreeType 2.9.  But it only
happened with Type 1 fonts, not with TrueType.  That seems to match the
bug report.

In any case, the current git code (as of a couple weeks ago when I ran
my tests) fixed the problem.

- Derek

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Time for a new FreeType release

[Alexei Podtelezhnikov]

On Tue, Apr 3, 2018 at 11:34 AM, Nikolaus Waxweiler 
wrote:

> > (1) without any build tools (e.g., flat-directory compilation, as
> discussed in file `INSTALL.ANY');
>
> So how would a universal ftconfig.h.in fit in here? If you generate
> one for `make dist`, you're going to bake in platform specifics, no?
>

I'd rather start with generic ftconfig.h, then generate ftconfig.in for
autotools from it.
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Time for a new FreeType release

[Nikolaus Waxweiler]

> (1) without any build tools (e.g., flat-directory compilation, as discussed 
> in file `INSTALL.ANY');

So how would a universal ftconfig.h.in fit in here? If you generate
one for `make dist`, you're going to bake in platform specifics, no?

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Time for a new FreeType release

[Werner LEMBERG]

> Werner, as I understand it, the requirement is to support GNU make
> next to Autotools plus GNU make, no?  Platforms not supported by
> that (e.g. Windows) can use CMake?  I'm asking because Alexei says
> not all build systems are scriptable, so you always need to maintain
> a spelt out `ftconfig.h`.

Well, it should be possible to compile FreeType

(1) without any build tools (e.g., flat-directory compilation, as
discussed in file `INSTALL.ANY');

(2) with GNU make (or its perl replacement, `makepp'), using only
platform-specific tools (if any) that are always available;

(3) with GNU make + autotools (this is the default for UNIX, to be
called by the top-level `configure' wrapper script);

(4) any other build system that gets contributed.

For (1), you need a ready-to-run `ftconfig.h' file.  This could be
delivered in a tarball, created by `make dist'.  For (2) to (4), the
build systems themselves should create a suitable `ftconfig.h' file
from the template.


Werner

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Time for a new FreeType release

[Werner LEMBERG]

> I'd prefer the entire open source ecosystem to switch to meson, but
> oh well

I must admit that I don't know meson at all.  Life is short, so I
probably won't have a look :-/

> CMake is the next best thing.

Personally, I really dislike CMake.  Both the syntax and the
philosophy behind it.  Of course, I don't object if people want to
maintain and improve CMake support, but it's definitely not me who is
going to do that.


Werner

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Time for a new FreeType release

[Werner LEMBERG]

>> (1) A call to make should run on *all* platforms.  In other words,
>> GNU make by itself had to produce an `ftconfig.h' file from the
>> template.
> 
> Run
>
>  diff -U2 ./include/freetype/config/ftconfig.h \
>   ./builds/unix/ftconfig.in
>
> What's to be done about the #define differences?

Well, the `build' version should have the corresponding #define
statements activated.  If you mean something different, please
elaborate.

>> Because this needs a bourne shell...
> 
> That's horrible. `sed` should do the job I reckon.

Maybe it is even possible with GNU make's string functions so that we
don't need external tools?  This would be the best solution IMHO (for
the non-configure case).


Werner

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Time for a new FreeType release

[Nikolaus Waxweiler]

> Personally, I really dislike CMake.

Me too, it's rather unelegant. I like it enough to work on it
though... I don't think there are many build systems out there that
are likeable, which might have something to do with the fact that
C/C++ are hard to tool around.

> Maybe it is even possible with GNU make's string functions

I'm gonna try that, GNU make >= 4.2 supports things like
```
file:=test.txt
variable:=$(file < $(FILE))
```
Then you should be able to regex around in it.

> If you mean something different, please elaborate.

```
-#if FT_SIZEOF_INT == ( 32 / FT_CHAR_BIT )
+#if FT_SIZEOF_INT == 4
...

+  /* we handle the LLP64 scheme separately for GCC and clang, */
+  /* suppressing the `long long' warning  */
+#elif ( FT_SIZEOF_LONG == 4 )   && \
+  defined( HAVE_LONG_LONG_INT ) && \
+  defined( __GNUC__ )
+#pragma GCC diagnostic ignored "-Wlong-long"
+#define FT_LONG64
+#define FT_INT64   long long int
+#define FT_UINT64  unsigned long long int
+

-#endif /* FT_SIZEOF_LONG == (64 / FT_CHAR_BIT) */
+#endif /* FT_SIZEOF_LONG == 8 */
```

Shouldn't this be the same in both files?

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Time for a new FreeType release

[Werner LEMBERG]

> Eh... that would exclude make. And if you make do without it (haha),
> you might also copy and edit *.in files by hand ;)

Well, copying source and header files is described in file
`INSTALL.ANY', section `II. Support for flat-directory compilation'.

It's not that far-fetched as you believe :-)


Werner

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Time for a new FreeType release

[Werner LEMBERG]

> ../src/autofit/afscript.h:35:11: error:
> 'HB_SCRIPT_ADLAM' undeclared here (not in a function)

Fixed in current git: You need a HarfBuzz version 1.3.0 or newer.

> why not uing meson ?

If someone is contributing Meson support...

> btw is Jam still supported ?

Theoretically yes; we take care to synchronize the jam files.
However, jam itself with the extensions used by FreeType (vanilla jam
doesn't work AFAIK) is ooold, and I haven't found time to take care of
it.  And, admittedly, I'm not a jam user, thus my enthusiasm to do
that is rather restricted.


Werner

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Time for a new FreeType release

[Werner LEMBERG]

> I'm still amazed how it takes less than 5 seconds or something on my
> 8-core Ryzen 1700 to go from
>
>   cmake -G Ninja -DBUILD_SHARED_LIBS=ON .. \
>   && cmake --build . --config Release
>
> to a shared lib.  Running configure alone takes more than 5
> seconds :D

No wonder, since cmake has *a lot* of built-in platform knowledge.
Its philosophy is quite contrary to GNU autotools.


Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Time for a new FreeType release

[Werner LEMBERG]

> So from a Ghostscript perspective, the current code looks good.

Thanks for checking!


Werner

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Time for a new FreeType release

[Chris Liddell]

On 03/04/18 15:12, Alexei Podtelezhnikov wrote:
 We're currently experiencing a problem with FreeType 2.9 in
 conjunction with Ghostscript.  Some TrueType glyphs are rendering as
 if the hinting is broken, or points are being moved/dropped.
>>
>> Well, the good news is that the corrupted glyph rendering is resolved in
>> the current freetype.git HEAD code.
>>
> 
> This must be bug 52846 .

Seems extremely like it - I could bisect, but it didn't seem worth the
effort.

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Time for a new FreeType release

[Nikolaus Waxweiler]

> If MSbuild is a kind of make, then yes. I do not know if that is scriptable.

Me neither. Does it matter if you can use e.g. CMake on that platform?
That's also what's done by vcpkg, A Microsoft project to make it easy
to install open source libraries in a Windows environment.

Werner, as I understand it, the requirement is to support GNU make
next to Autotools plus GNU make, no? Platforms not supported by that
(e.g. Windows) can use CMake? I'm asking because Alexei says not all
build systems are scriptable, so you always need to maintain a spelt
out `ftconfig.h`.

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Time for a new FreeType release

[Alexei Podtelezhnikov]

> >> We're currently experiencing a problem with FreeType 2.9 in
> >> conjunction with Ghostscript.  Some TrueType glyphs are rendering as
> >> if the hinting is broken, or points are being moved/dropped.
>
> Well, the good news is that the corrupted glyph rendering is resolved in
> the current freetype.git HEAD code.
>

This must be bug 52846 .
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Time for a new FreeType release

[Chris Liddell]

On 02/04/18 16:04, Werner LEMBERG wrote:
> 
>> We're currently experiencing a problem with FreeType 2.9 in
>> conjunction with Ghostscript.  Some TrueType glyphs are rendering as
>> if the hinting is broken, or points are being moved/dropped.
> 
> Interesting.
> 
>> If your projected timescale is later than this week that's probably
>> OK for us.  I hope we can at least isolate the problem this week and
>> then you can decide whether to delay releasing until we can propose
>> a good fix.
> 
> OK, will wait until you report.  There is no hurry :-)
> 
> And thanks in advance for your investigations!

Hi Werner,

Well, the good news is that the corrupted glyph rendering is resolved in
the current freetype.git HEAD code.

I found a couple of other changes in the output, but one is a (badly!)
broken font, and the other is almost certainly unique to the way
Ghostscript uses Freetype, and I can address that in our code.

So from a Ghostscript perspective, the current code looks good.

Chris


___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Time for a new FreeType release

[Nikolaus Waxweiler]

> Any additional requirements are not acceptable.

Eh... that would exclude make. And if you make do without it (haha),
you might also copy and edit *.in files by hand ;)

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Time for a new FreeType release

[Alexei Podtelezhnikov]

>
> > Because this needs a bourne shell...
>
> That's horrible. `sed` should do the job I reckon.
>

To compile FreeType you need ANSI C compiler. [period]
You can use whatever is in your toolbox, but you cannot require it.
Any additional requirements are not acceptable. Therefore ftconfig.h is
there to stay.
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Time for a new FreeType release

[Nikolaus Waxweiler]

> MSYS2 is "native" in the sense that there is no additional DLL which is 
> required (contrary to cygwin)  andi said "native" because  compiling with gcc 
> is actually cross compilation (native would mean Visual Studio, and Visual 
> Studio is so huge...)

Ah, okay. Maybe you find that my cleaned CMake build also suits your
MSYS needs while being faster :)

> sticking to one build system with a good doc is the less error prone

Yes :D I'd throw the other stuff out in a heartbeat (I love purging
legacy code) but I'm not the maintainer and Werner has a different
opinion on this :)

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Time for a new FreeType release

[Vincent Torri]

On Tue, Apr 3, 2018 at 12:52 PM, Nikolaus Waxweiler  wrote:
> (Oh, and: streamlining the build process for all build systems should
> make it much easier to add support for more. FreeType definitely needs
> more build systems.)

then you multiply the amount of work by the number of build systems
each time you modify build systems.

sticking to one build system with a good doc is the less error prone

regards

Vincent Torri

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Time for a new FreeType release

[Vincent Torri]

On Tue, Apr 3, 2018 at 12:47 PM, Nikolaus Waxweiler  wrote:
> Good :) Is it usable your your purposes? Is there a specific reason
> you compile in MSYS instead of using a native CMake build?

MSYS2 is "native" in the sense that there is no additional DLL which
is required (contrary to cygwin)
andi said "native" because compiling with gcc is actually cross
compilation (native would mean Visual Studio, and Visual Studio is so
huge...)

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Time for a new FreeType release

[Nikolaus Waxweiler]

> (1) A call to make should run on *all* platforms.  In other words, GNU make 
> by itself had to produce an `ftconfig.h' file from the template.

Run `diff -U2 ./include/freetype/config/ftconfig.h
./builds/unix/ftconfig.in` -- What's to be done about the #define
differences?

> Because this needs a bourne shell...

That's horrible. `sed` should do the job I reckon.

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Time for a new FreeType release

[Nikolaus Waxweiler]

(Oh, and: streamlining the build process for all build systems should
make it much easier to add support for more. FreeType definitely needs
more build systems.)

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Time for a new FreeType release

[Nikolaus Waxweiler]

Good :) Is it usable your your purposes? Is there a specific reason
you compile in MSYS instead of using a native CMake build?

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Time for a new FreeType release

[Vincent Torri]

On Tue, Apr 3, 2018 at 12:37 PM, Nikolaus Waxweiler  wrote:
> Because meson is younger than the other build systems ;)

well, some big projects are already using meson. Like gstreamer.

> I'd prefer
> the entire open source ecosystem to switch to meson, but oh well ;)
> CMake is the next best thing.
>
> Use `-DCMAKE_DISABLE_FIND_PACKAGE_x=TRUE` to disable searching for a
> package entirely (x is the CMake package name, so "BZip2" instead of
> "BZIP2"). Try `-DCMAKE_DISABLE_FIND_PACKAGE_HarfBuzz=TRUE`

cmake -G Ninja -DBUILD_SHARED_LIBS=ON
-DCMAKE_DISABLE_FIND_PACKAGE_HarfBuzz=TRUE
-DCMAKE_DISABLE_FIND_PACKAGE_BZip2=TRUE .. && cmake --build . --config
Release

is working (i do not have bzip2)

> Actually, I'm in the process of cleaning up the CMake build, can you
> try compiling my
> https://github.com/madig/freetype2/tree/modernize-cmake-build branch?

same command than above, i get the DLL

Vincent Torri

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Time for a new FreeType release

[Nikolaus Waxweiler]

Because meson is younger than the other build systems ;) I'd prefer
the entire open source ecosystem to switch to meson, but oh well ;)
CMake is the next best thing.

Use `-DCMAKE_DISABLE_FIND_PACKAGE_x=TRUE` to disable searching for a
package entirely (x is the CMake package name, so "BZip2" instead of
"BZIP2"). Try `-DCMAKE_DISABLE_FIND_PACKAGE_HarfBuzz=TRUE`

Actually, I'm in the process of cleaning up the CMake build, can you
try compiling my
https://github.com/madig/freetype2/tree/modernize-cmake-build branch?

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Time for a new FreeType release

[Vincent Torri]

On Tue, Apr 3, 2018 at 12:20 PM, Nikolaus Waxweiler  wrote:
>> note that Windows (non-UNIX platform) can be compiled on MSYS2 which 
>> provides a kind of POSIX environment. I compile on it evry day
>
> Interesting, have you looked at the CMake build? I'm still amazed how
> it takes less than 5 seconds or something on my 8-core Ryzen 1700 to
> go from `cmake -G Ninja -DBUILD_SHARED_LIBS=ON .. && cmake --build .
> --config Release` to a shared lib. Running configure alone takes more
> than 5 seconds :D

fast but fails : ../src/autofit/afscript.h:35:11: error:
'HB_SCRIPT_ADLAM' undeclared here (not in a function)

how do I disable harffbuz support ?

why not uing meson ?

btw is Jam still supported ?

Vincent Torri

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Time for a new FreeType release

[Nikolaus Waxweiler]

> note that Windows (non-UNIX platform) can be compiled on MSYS2 which provides 
> a kind of POSIX environment. I compile on it evry day

Interesting, have you looked at the CMake build? I'm still amazed how
it takes less than 5 seconds or something on my 8-core Ryzen 1700 to
go from `cmake -G Ninja -DBUILD_SHARED_LIBS=ON .. && cmake --build .
--config Release` to a shared lib. Running configure alone takes more
than 5 seconds :D

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Time for a new FreeType release

[Vincent Torri]

On Tue, Apr 3, 2018 at 11:53 AM, Werner LEMBERG  wrote:
>
>> So, let me rephrase the question: what would it take to unify all
>> ftconfig.* files into one ftconfig.h.in for all platforms?
>
> Two cases have to be supported.
>
> (1) A call to
>
>   make
>
> should run on *all* platforms.  In other words, GNU make by itself
> had to produce an `ftconfig.h' file from the template.
>
> Ditto for `make devel'.
>
> (2) A call to
>
>   ./configure
>
> should do what it does now.
>
> If you manage (1), please proceed :-) As Tosihiya-san said: having a
> single config file is certainly a good idea.
>
>> This reminds me: do we really need the devel/*.h files or can we
>> make something easier using build system hackery?  Most of the
>> defines can be turned into build system options anyway, a debug
>> build would be a simple --enable-debug-build or something that turns
>> everything on.
>
> I'm open to any changes under the hood as long as `make devel' works –
> without calling `./configure', and doing a static build.
>
>>> On the other hand, it would disable direct compilation from git for
>>> non-UNIX platforms, forcing people to first say `make tarball' or
>>> something like this to generate the necessary file(s).
>>
>> Well, you want to invoke some build system anyway, so the build
>> system does the heavy lifting for you while building?  Why ship
>> pre-filled config.hs?
>
> My thinko, see above.  If GNU make produces `ftconfig.h', then I don't
> object to larger changes :-)
>
>>> If we changed the FreeType build system to native automake, say,
>>> then we could have a single `config.h' file.  I'm sometimes tempted
>>> to do that...
>>
>> Why not use AC_CONFIG_FILES like in configure.raw?
>
> Because this needs a bourne shell...

note that Windows (non-UNIX platform) can be compiled on MSYS2 which
provides a kind of POSIX environment. I compile on it evry day

and automake adds in Makefile the distcheck rule which is really useful.

in case this helps...

Vincent Torri

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Time for a new FreeType release

[Werner LEMBERG]

> So, let me rephrase the question: what would it take to unify all
> ftconfig.* files into one ftconfig.h.in for all platforms?

Two cases have to be supported.

(1) A call to

  make

should run on *all* platforms.  In other words, GNU make by itself
had to produce an `ftconfig.h' file from the template.

Ditto for `make devel'.

(2) A call to

  ./configure

should do what it does now.

If you manage (1), please proceed :-) As Tosihiya-san said: having a
single config file is certainly a good idea.

> This reminds me: do we really need the devel/*.h files or can we
> make something easier using build system hackery?  Most of the
> defines can be turned into build system options anyway, a debug
> build would be a simple --enable-debug-build or something that turns
> everything on.

I'm open to any changes under the hood as long as `make devel' works –
without calling `./configure', and doing a static build.

>> On the other hand, it would disable direct compilation from git for
>> non-UNIX platforms, forcing people to first say `make tarball' or
>> something like this to generate the necessary file(s).
> 
> Well, you want to invoke some build system anyway, so the build
> system does the heavy lifting for you while building?  Why ship
> pre-filled config.hs?

My thinko, see above.  If GNU make produces `ftconfig.h', then I don't
object to larger changes :-)

>> If we changed the FreeType build system to native automake, say,
>> then we could have a single `config.h' file.  I'm sometimes tempted
>> to do that...
> 
> Why not use AC_CONFIG_FILES like in configure.raw?

Because this needs a bourne shell...


Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Time for a new FreeType release

[Nikolaus Waxweiler]

> it should be generated automatically from ftconfig.in [...]

> The idea of the `configure' script is to have a template file `ftconfig.in' 
> that gets massaged to create `ftconfig.h'.

This is what I want :) Currently, we have one .in for Unix and then
just spelt out ftconfig.h files for everything else... I'd like to
have ONE ftconfig.h.in for all/the majority of platforms with @STUFF@
that I can replace from CMake (best without regex hackery). Other
build systems could use the same file and replace things by
script/AC_CONFIG_FILES. The important piece is having just one
canonical template. Additionally, I'd like to have a ftoption.h.in
that I can also fill in from CMake without regexes.

So, let me rephrase the question: what would it take to unify all
ftconfig.* files into one ftconfig.h.in for all platforms?

> if we drop all platforms which building tool XXX does not support, we can 
> support all systems by building tool XXX.

Don't get me wrong, I'm not saying we should drop unsupported-by-cmake
platforms (although I'm thinking that in my head, yes :B). Rather, I
want one canonical ftconfig.h.in and ftoption.h.in.


This reminds me: do we really need the devel/*.h files or can we make
something easier using build system hackery? Most of the defines can
be turned into build system options anyway, a debug build would be a
simple --enable-debug-build or something that turns everything on.

> MPW configuration files

What is MPW? Google brings up some m68k build scripts?

> FreeType needs simply #define'd configure file for obscure platforms without 
> autotools or cmake.

There aren't too many things to be filled in from what I can gather;
if you port to obscure platforms, you can replace @STUFF@ by hand or
script quickly enough I suppose.

> On the other hand, it would disable direct compilation from git for non-UNIX 
> platforms, forcing people to first say `make tarball' or something like this 
> to generate the necessary file(s).

Well, you want to invoke some build system anyway, so the build system
does the heavy lifting for you while building? Why ship pre-filled
config.hs?

> If we changed the FreeType build system to native automake, say, then we 
> could have a single `config.h' file.  I'm sometimes tempted to do that...

Why not use AC_CONFIG_FILES like in configure.raw?

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Time for a new FreeType release

[Werner LEMBERG]

>> The first is called "ANSI-specific configuration file", the second
>> "UNIX [...]".  Why are there two files?

The first one gets used without the `configure' script; it is generic
and should work on any platform.

>> The configure/Makefile system seems to always install the second on
>> Linux.  Why do we need the first then, for everything else?

Yes.  Not every OS uses (or can use) `configure'.

>> There are various #define differences between the two -- is
>> this... intended?

Yes.

>> What would it take to unify the config.h files for all platforms?

This is not possible.  The idea of the `configure' script is to have a
template file `ftconfig.in' that gets massaged to create `ftconfig.h'.
If we had a single `ftconfig.h' file we would still need a
UNIX-specific configuration file to be included by it.

> But, if you propose a workflow to reduce the maintenance cost, like,
> "ftconfig.h for ANSI C platform should not be stored as
> self-standing file in the git repository, because there is a
> possibility to be overlooked in the maintenance. it should be
> generated automatically from ftconfig.in during the process to make
> a tarball for releasing", I think it's very good idea.

Yes, probably.  On the other hand, it would disable direct compilation
from git for non-UNIX platforms, forcing people to first say `make
tarball' or something like this to generate the necessary file(s).

>> Also, CMake comes with the configure_file() command[1], which
>> substitutes ${VAR} or @VAR@ with stuff or (un)defines things with
>> #cmakedefine.  We can't really use it here because the ftconfig.*
>> files don't contain variables to expand.  I guess because we aren't
>> using the (full) Autotools stack?

Exactly.  Those `@xxx@' variables are in
`builds/unix/{unix-cc.in,unix-def.in}'.

>> I'd like to have one config.h for all platforms that I can fill in
>> from all build systems.
> 
> Sorry, I feel something like a tautology; if we drop all platforms
> which building tool XXX does not support, we can support all systems
> by building tool XXX.

If we changed the FreeType build system to native automake, say, then
we could have a single `config.h' file.  I'm sometimes tempted to do
that...


Werner

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Time for a new FreeType release

[Alexei Podtelezhnikov]

On Mon, Apr 2, 2018 at 4:25 PM, Nikolaus Waxweiler 
wrote:

> Still looking into it on and off... on my plate: more idiomatic ftconfig.h
> generation, pkg-config .pc file generation.


I would not do that. FreeType needs simply #define'd configure file for
obscure platforms without autotools or cmake. You got already that
autotools process the the ftconfig.in file, Whatnot including Cmake uses
ftconfig.h.
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Time for a new FreeType release

[suzuki toshiya]

Dear Nikolaus,

Nikolaus Waxweiler wrote:
> The first is called "ANSI-specific configuration file", the second "UNIX 
> [...]". Why are there two files? The configure/Makefile system seems to 
> always install the second on Linux. Why do we need the first then, for 
> everything else? There are various #define differences between the two 
> -- is this... intended? What would it take to unify the config.h files 
> for all platforms?

When I entered freetype community, there were already 2 files,
so I don't know the original background. But I understand they
have their own rationales.

* POSIX C library has greater set of the features, than ANSI C,
although the majority of freetype users might be working with POSIX
environment.

* configrue (or cmake) is not always executable on the platforms
with ANSI C. sometimes the developers use strange & platform-specific
building tools, and they have to pick or edit the configuration files
manually. providing pre-configured config.h would be helpful for
these cases.

So I'm negative with the proposal to remove the pre-configured
files simply.

But, if you propose a workflow to reduce the maintenance cost, like,
"ftconfig.h for ANSI C platform should not be stored as self-standing
file in the git repository, because there is a possibility to be
overlooked in the maintenance. it should be generated automatically
from ftconfig.in during the process to make a tarball for releasing",
I think it's very good idea.

> Also, CMake comes with the configure_file() command[1], which 
> substitutes ${VAR} or @VAR@ with stuff or (un)defines things with 
> #cmakedefine. We can't really use it here because the ftconfig.* files 
> don't contain variables to expand. I guess because we aren't using the 
> (full) Autotools stack? I'd like to have one config.h for all platforms 
> that I can fill in from all build systems.

Sorry, I feel something like a tautology; if we drop all platforms
which building tool XXX does not support, we can support all systems
by building tool XXX.

> Also also, do we still need the macOS Framework stuff? Is it maybe 
> redundant in later versions?

If cmake is able to generate MPW configuration files, I'm interested in.
In fact, jam had once been expected to be useful for such - but it was
not. It's my long running homework to make a tool to update the MPW
configuration files automatically.

Regards,
mpsuzuki


___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Time for a new FreeType release

[Nikolaus Waxweiler]

Actually, regarding ftconfig.h generation. There are two files (plus two 
more for Amiga and VMS...):


./include/freetype/config/ftconfig.h
./builds/unix/ftconfig.in

The first is called "ANSI-specific configuration file", the second "UNIX 
[...]". Why are there two files? The configure/Makefile system seems to 
always install the second on Linux. Why do we need the first then, for 
everything else? There are various #define differences between the two 
-- is this... intended? What would it take to unify the config.h files 
for all platforms?


Is it necessary to have HAVE_UNISTD_H, HAVE_FCNTL_H and HAVE_STDINT_H 
#define'd in ftconfig.h (I know the Makefiles do this) or would this 
suffice:

```
if (UNIX)
  if (HAVE_UNISTD_H)
target_compile_definitions(freetype PRIVATE HAVE_UNISTD_H=1)
  endif ()
  if (HAVE_FCNTL_H)
target_compile_definitions(freetype PRIVATE HAVE_FCNTL_H=1)
  endif ()
  if (HAVE_STDINT_H)
target_compile_definitions(freetype PRIVATE HAVE_STDINT_H=1)
  endif ()
endif ()
```

Also, CMake comes with the configure_file() command[1], which 
substitutes ${VAR} or @VAR@ with stuff or (un)defines things with 
#cmakedefine. We can't really use it here because the ftconfig.* files 
don't contain variables to expand. I guess because we aren't using the 
(full) Autotools stack? I'd like to have one config.h for all platforms 
that I can fill in from all build systems.


Also also, do we still need the macOS Framework stuff? Is it maybe 
redundant in later versions?



[1]: https://cmake.org/cmake/help/v3.11/command/configure_file.html

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Time for a new FreeType release

[Nikolaus Waxweiler]

Still looking into it on and off... on my plate: more idiomatic 
ftconfig.h generation, pkg-config .pc file generation.


___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Time for a new FreeType release

[Werner LEMBERG]

> We're currently experiencing a problem with FreeType 2.9 in
> conjunction with Ghostscript.  Some TrueType glyphs are rendering as
> if the hinting is broken, or points are being moved/dropped.

Interesting.

> If your projected timescale is later than this week that's probably
> OK for us.  I hope we can at least isolate the problem this week and
> then you can decide whether to delay releasing until we can propose
> a good fix.

OK, will wait until you report.  There is no hurry :-)

And thanks in advance for your investigations!


Werner

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Time for a new FreeType release

[Ken Sharp]

At 09:09 01/04/2018 +0200, Werner LEMBERG wrote:


Folks,


I would like to do a new FreeType release within the next few weeks.
Is there anything that should be handled before doing so?


Hi Werner,

We're currently experiencing a problem with FreeType 2.9 in conjunction 
with Ghostscript. Some TrueType glyphs are rendering as if the hinting is 
broken, or points are being moved/dropped.


We haven't mentioned it yet because we intend to diagnose it ourselves and 
get back to you with an explanation and proposed solution, but the prospect 
of a release soon made me think I should at least tell you we see a problem


I know Chris Liddell was hoping to get somewhere with debugging (or at 
least bisecting to the commit) this week. Chris is on vacation today but he 
may get back to you shortly.


If your projected timescale is later than this week that's probably OK for 
us. I hope we can at least isolate the problem this week and then you 
can  decide whether to delay releasing until we can propose a good fix.



Regards,


Ken Sharp


___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Time for a new FreeType release

[Alexei Podtelezhnikov]

On Sun, Apr 1, 2018 at 3:09 AM, Werner LEMBERG  wrote:

> I would like to do a new FreeType release within the next few weeks.
> Is there anything that should be handled before doing so?


Let's commit CMakeList.txt review if Nikolaus feels confident. If Nikolause
can
add handing of ftver.rc on Windows, that would be swell.
http://cmake.3232098.n2.nabble.com/CMake-amp-win32-rc-files-td6327003.html
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel