[HarfBuzz] A plea to make HarfBuzz easier to build.

[Behdad Esfahbod]

On 15-12-15 02:14 PM, Jonathan Blow wrote:
> Sure, it would be fine to add this; there is also a for-loop in one spot that
> doesn't compile in Visual Studio because it declares an enum inline, so one
> has to move the enum.

That's fixed already.  Will be in next release (I thought that went into a
release already).


> But these things don't matter, they only take a minute to fix. It's trivial.
> Whereas getting the library to build and link for the first time is measured
> in hours.
> 
> It is a two-orders-of-magnitude difference, which is why I am saying that if
> widespread use of the code is a goal, making it easier to build should be the
> priority.

But the one-minute manual fixes have to be redone every time you want to
update your copy of harfbuzz, whereas the initial build has to be done once.
So I rather optimize for faster roll-forward than faster initial-build.

An nmake build system for Windows will be coming soon:

  https://github.com/behdad/harfbuzz/pull/164

A CMake one might happen.  But in general nothing in text layout is easy, so
making the library much easier to build is not going to matter much.  You
still have to study the problem enough to know whether you want freetype,
ucdn, etc; as well as figure out the atomic and mutex implementation.  So a
one-file solution is more often than not going to get something wrong.  That
said, I might give it a try and see how much work it is.  It does make day to
day compiles much slower, so it can't be the default.  Not being default means
that it will either rot or can hide tricky bugs in there.

Might be easier if we just write a good porting guide instead.

behdad

> On Tuesday, December 15, 2015, Behdad Esfahbod <behdad.esfahbod at gmail.com
> <mailto:behdad.esfahbod at gmail.com>> wrote:
> 
>     On 15-12-13 09:33 PM, Jamie Dale wrote:
>     > You'll need a define to stub out getenv for a PS4 build
> 
>     I'll take a patch to hb-private.hh to do that.
>