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

[Jonathan Blow]

A porting guide would definitely help, because most of the several hours
(and most of the frustration) is just not knowing what to do and having to
figure it out. If you knew exactly what to do it's 30 minutes or less.

A one-file solution could just be set up to error if you don't provide the
necessary defines ... Which then indicates very clearly to the user exactly
what decisions they need to make, and you would it even need to write a
porting guide! (I think of documentation as code that is always wrong
because it never runs.)


On Tuesday, December 15, 2015, Behdad Esfahbod <behdad.esfahbod at gmail.com>
wrote:

> 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 <javascript:;>
> > <mailto:behdad.esfahbod at gmail.com <javascript:;>>> 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.
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/harfbuzz/attachments/20151215/0f42a05c/attachment.html>