ttfautohint @1.7: new port

[tuffnatty (Phil Krylov)]

New port for ttfautohint, which is a library and a tool to autohint TrueType fonts.

[kencu (Ken)]

Tried:

libraries... yes
checking dynamic linker characteristics... darwin10.8.0 dyld
checking how to hardcode library paths into programs... immediate
configure: creating ./config.lt
config.lt: creating libtool
checking for freetype-config... /opt/local/bin/freetype-config
checking whether FreeType header files are version 2.4.5 or higher... yes
checking whether FreeType library is version 2.4.5 or higher... (found 2.8.0)... yes
checking for import... import
checking for inkscape... inkscape
checking for pandoc... no
configure: WARNING: Need pandoc to create PDF and HTML documentation files
checking for xelatex... no
checking for kpsewhich... kpsewhich
configure: WARNING: Can't find `NotoSansGujarati-Regular.ttf'.
configure: error: Adjust the `TTFONTS' environment variable so that the Noto fonts are found.
Command failed:  cd "/opt/local/var/macports/build/_Users_Shared_Downloads_graphics_ttfautohint/ttfautohint/work/ttfautohint-1.7" && ./configure --prefix=/opt/local --with-qt=no 
Exit code: 1
Error: Failed to configure ttfautohint, consult /opt/local/var/macports/build/_Users_Shared_Downloads_graphics_ttfautohint/ttfautohint/work/ttfautohint-1.7/config.log
Error: Failed to configure ttfautohint: configure failure: command execution failed

I presume you have that font installed? Perhaps you can tell me what port provides `NotoSansGujarati-Regular.ttf' so we can add that as a dependency.

[tuffnatty (Phil Krylov)]

Replying to kencu:

I presume you have that font installed? Perhaps you can tell me what port provides `NotoSansGujarati-Regular.ttf' so we can add that as a dependency.

No, I don't have that font, but the build passes because I also don't have kpsewhich that you have. Anyway, these are needed only for documentation building, no port provides these fonts, and the official build instructions recommend to disable docs building. So here is the new Portfile version with docs disabled.

[mf2k (Frank Schima)]

Comments:

• Use a single configure.args-replace command instead of configure.args-delete and configure.args-append
• Why is the qt5 variant not default?
• Why have a qt4 variant? Why not just always use qt5 and remove both variants?

[tuffnatty (Phil Krylov)]

Replying to mf2k:

• Use a single configure.args-replace command instead of configure.args-delete and configure.args-append

Thanks, I'll update the Portfile now.

• Why is the qt5 variant not default?
• Why have a qt4 variant? Why not just always use qt5 and remove both variants?

The default is to build just the command-line utility. The GUI (both variants) is optional. As for the qt4 variant - why do we have qt4 in the ports tree if we forbid building packages that support it against qt4? Because someone may need it, e.g. there is a package depending on qt4 and we don't want to install qt5 as well if ttfautohintGUI supports qt4 too.

[mf2k (Frank Schima)]

The answer to having qt4 is legacy reasons. Removing it would break many ports that rely on it. At some point those should be updated to qt5 where possible.

For new ports, it is best to support the latest framework only (qt, wx, python, etc).

[tuffnatty (Phil Krylov)]

Replying to mf2k:

The answer to having qt4 is legacy reasons. Removing it would break many ports that rely on it. At some point those should be updated to qt5 where possible.

There are some ports having both qt4 ant qt5 variants: cmake, doxygen, faustlive-devel, gate, gecode, lpe, LyX...

For new ports, it is best to support the latest framework only (qt, wx, python, etc).

Is it an official recommendation? I don't see it in docs. And I believe that we must provide all possible build options when it is not too hard to support them. I already gave an example where a qt4 variant may be useful.

[mf2k (Frank Schima)]

Replying to tuffnatty:

Replying to mf2k: There are some ports having both qt4 ant qt5 variants: cmake, doxygen, faustlive-devel, gate, gecode, lpe, LyX...

Again, legacy reasons. Most of them started out with qt4 or even qt3.

Is it an official recommendation? I don't see it in docs. And I believe that we must provide all possible build options when it is not too hard to support them. I already gave an example where a qt4 variant may be useful.

Recommendation: yes, requirement: no. The docs could be updated. And who would support them in this case? This proposed port is nomaintainer. More options requires more support. We are definitely short-staffed on this all-volunteer project.

Are you saying a dependency of ttfautohint has a qt4 variant? I looked at the ones in the Portfile but they don't directly have it. Yes, that would be a good reason.

[tuffnatty (Phil Krylov)]

Replying to mf2k:

Is it an official recommendation? I don't see it in docs. And I believe that we must provide all possible build options when it is not too hard to support them. I already gave an example where a qt4 variant may be useful.

Recommendation: yes, requirement: no. The docs could be updated. And who would support them in this case? This proposed port is nomaintainer. More options requires more support. We are definitely short-staffed on this all-volunteer project.

I'd volunteer to maintain this port if I had the needed access privileges.

Are you saying a dependency of ttfautohint has a qt4 variant? I looked at the ones in the Portfile but they don't directly have it. Yes, that would be a good reason.

No I did not mean it. I said that someone who already has qt4 installed for some reason and does not want to bloat the system with qt5 as well, can use +qt4 variant for ttfautohint. If there is no +qt4 variant, one will not have this option. That's all.

As for myself, I don't need the GUI at all, CLI is enough for me. However, one of the things that worries me in contemporary software development is a tendency to drop useful features without a strong reason, when supporting them is easy enough.

[ryandesign (Ryan Carsten Schmidt)]

If both qt variants remain, they should conflict with one another.

Is pkgconfig really a lib dependency? Usually it is only a build dependency.

If you'd like to maintain the port that would be great. To update the port, you would file a ticket, just as you've done here, or file a pull request on GitHub.

[tuffnatty (Phil Krylov)]

Replying to ryandesign:

If both qt variants remain, they should conflict with one another.

Is pkgconfig really a lib dependency? Usually it is only a build dependency.

Oops! Fixed.

If you'd like to maintain the port that would be great. To update the port, you would file a ticket, just as you've done here, or file a pull request on GitHub.

I've added myself as a maintainer, added cross-variant conflict, and changed pkgconfig to a build-time dependency.

[tuffnatty (Phil Krylov)]

Portfile with the latest fixes.

[kencu (Ken)]

That worked. I did some typical Macports reformatting to match our other ports.

I think this port needs c++11 - at least it tests for it and uses it - dunno if it would build if it didn't find it. If so, would need the cxx11 1.1 PortGroup.

Does an unusually good job of testing for glib functions and replaces the missing ones, nice to see. Perhaps I can learn how they do that and add it to the ports that don't do it right.

I'll post up the Portfile I have reformatted, and try the build on a couple of other systems to see about the cxx11 1.1 PG.

[kencu (Ken)]

Portfile.reformatted slightly

[tuffnatty (Phil Krylov)]

Replying to kencu:

I think this port needs c++11 - at least it tests for it and uses it - dunno if it would build if it didn't find it. If so, would need the cxx11 1.1 PortGroup.

Is not that included with Xcode which is a global dependency anyway?

I'll post up the Portfile I have reformatted, and try the build on a couple of other systems to see about the cxx11 1.1 PG.

Thank you.

[kencu (Ken)]

Replying to tuffnatty:

Is not that included with Xcode which is a global dependency anyway?

In MacPorts, although the focus is clearly on the last three systems released, we try if possible to include older systems. To make this easy for everyone, some supporting software has been written and is maintained as possible.

Systems from Mountain Lion and earlier don't have default compilers that support c++11. So this functionality is retrofitted into those systems with a simple single line of code in the Portfile

PortGroup cxx11 1.1

and presto, the software will build (in most cases) all the way back to Tiger.

Magic. Usually :>

[kencu (Ken)]

Tested. Builds fine with apple's gcc-4.2 compiler without c++11. So it will use it if available, but doesn't require it.

[kencu (Ken)]

the +qt4 version built without trouble, but I'm running into a hiccup with the +qt5 build:

checking whether wcsftime is declared without a macro... yes
checking for stdint.h... (cached) yes
checking for HARFBUZZ... yes
checking for qmake... /opt/local/libexec/qt5/bin/qmake
checking for moc... /opt/local/libexec/qt5/bin/moc
checking for uic... /opt/local/libexec/qt5/bin/uic
checking for rcc... /opt/local/libexec/qt5/bin/rcc
checking whether host operating system is Darwin... yes
Info: creating stash file /opt/local/var/macports/build/_Volumes_MacBookProSSD_Users_Shared_Downloads_graphics_ttfautohint/ttfautohint/work/ttfautohint-1.7/conftest.dir/.qmake.stash
Project ERROR: failed to parse default search paths from compiler output
configure: error: Calling /opt/local/libexec/qt5/bin/qmake -spec macx-g++ failed.
Command failed:  cd "/opt/local/var/macports/build/_Volumes_MacBookProSSD_Users_Shared_Downloads_graphics_ttfautohint/ttfautohint/work/ttfautohint-1.7" && ./configure --prefix=/opt/local --with-qt=/opt/local/libexec/qt5/bin --with-doc=no 
Exit code: 3
Error: Failed to configure ttfautohint, consult /opt/local/var/macports/build/_Volumes_MacBookProSSD_Users_Shared_Downloads_graphics_ttfautohint/ttfautohint/work/ttfautohint-1.7/config.log
Error: Failed to configure ttfautohint: configure failure: command execution failed
Error: See /opt/local/var/macports/logs/_Volumes_MacBookProSSD_Users_Shared_Downloads_graphics_ttfautohint/ttfautohint/main.log for details.
Error: Follow https://guide.macports.org/#project.tickets to report a bug.

[tuffnatty (Phil Krylov)]

Hmm. My qt5 is 5.8.0, probably your OS is 10.10+ and supports some newer qt5 version which I could not test.

[tuffnatty (Phil Krylov)]

Replying to kencu:

the +qt4 version built without trouble, but I'm running into a hiccup with the +qt5 build:

Error: Failed to configure ttfautohint, consult /opt/local/var/macports/build/_Volumes_MacBookProSSD_Users_Shared_Downloads_graphics_ttfautohint/ttfautohint/work/ttfautohint-1.7/config.log

Can you post your config.log?

[kencu (Ken)]

config.log for qt5 build failure

[kencu (Ken)]

main.log for qt5 build failure

[kencu (Ken)]

Here is the qt5 version that is current for high sierra on macports:

$ port -v installed | grep qt5
  qt5-qtbase @5.9.2_1+openssl platform='darwin 17' archs='x86_64' date='2017-11-02T11:49:29-0700'
  qt5-qtbase @5.9.2_2+openssl (active) platform='darwin 17' archs='x86_64' date='2017-11-16T21:51:29-0800'
  qt5-qtcreator @4.4.1_0 (active) platform='darwin 17' archs='x86_64' date='2017-11-02T11:50:03-0700'
  qt5-qtdeclarative @5.9.2_0 (active) platform='darwin 17' archs='x86_64' date='2017-11-02T11:49:39-0700'
  qt5-qtgraphicaleffects @5.9.2_0 (active) platform='darwin 17' archs='x86_64' date='2017-11-02T11:49:56-0700'
  qt5-qtmacextras @5.9.2_0 (active) platform='darwin 17' archs='x86_64' date='2017-11-02T11:49:55-0700'
  qt5-qtquickcontrols @5.9.2_0 (active) platform='darwin 17' archs='x86_64' date='2017-11-02T11:49:57-0700'
  qt5-qtscript @5.9.2_0 (active) platform='darwin 17' archs='x86_64' date='2017-11-02T11:49:50-0700'
  qt5-qtsvg @5.9.2_0 (active) platform='darwin 17' archs='x86_64' date='2017-11-02T11:49:36-0700'
  qt5-qttools @5.9.2_0 (active) platform='darwin 17' archs='x86_64' date='2017-11-02T11:49:45-0700'
  qt5-qtxmlpatterns @5.9.2_0 (active) platform='darwin 17' archs='x86_64' date='2017-11-02T11:49:37-0700'

[tuffnatty (Phil Krylov)]

Portfile fixing QT 5.9+ GUI build

[tuffnatty (Phil Krylov)]

Replying to kencu:

the +qt4 version built without trouble, but I'm running into a hiccup with the +qt5 build:

configure: error: Calling /opt/local/libexec/qt5/bin/qmake -spec macx-g++ failed.

Added a patch taking the spec name from the qt5 PortGroup. Seems to fix the issue on a OS X 10.12/QT 5.9.2 installation. Try the new Portfile.

[ken-cunningham-webuse]

In baf16baecba4fa67e3073b3af7a9779e3c518912/macports-ports:

ttfautohint: new port

tool and library to autohint TrueType fonts
closes: #55365