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

[Daniel Ribeiro Maciel]

Hi Behdad,

I wrote this hb.cc file. Drop it in the root of harfbuzz source tree to try
it out. You will need to add both Freetype and 'hb-ucdn' to the include
path though.

It will *not* compile; there are a bunch of symbol redefinition problems
and other seemingly (?) trivial things to fix (82 issues to be exact).
I did not apply any patches to harfbuzz source tree itself. Thought you
might want to change those things yourself since they would take some
renaming of enum variables and other stuff.

Let me know if you want a patch for that as well, I believe I'm able to
write it myself.

Cheers,
Daniel



On Wed, Dec 30, 2015 at 2:21 PM, Behdad Esfahbod 
wrote:

> Thanks Daniel.  I'm not opposed to the idea if it doesn't introduce too
> many
> hacks.  Might take a look at it myself even.
>
> On 15-12-28 11:00 PM, Daniel Ribeiro Maciel wrote:
> > I can write a '.cc' file which includes all other '.cc' files and
> defines a
> > bunch of stuff if you guys are willing to add such file to your source
> tree.
> >
> > On Tue, Dec 15, 2015 at 11:14 AM, 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.
> >
> > 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.
> >
> > On Tuesday, December 15, 2015, Behdad Esfahbod <
> behdad.esfah...@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.
> >
> >
> > ___
> > HarfBuzz mailing list
> > HarfBuzz@lists.freedesktop.org  HarfBuzz@lists.freedesktop.org>
> > http://lists.freedesktop.org/mailman/listinfo/harfbuzz
> >
> >
>

#define HAVE_FREETYPE
#define HAVE_OT
#define HAVE_UCDN
#define HAVE_INTEL_ATOMIC_PRIMITIVES

#include "src/hb-blob.cc"
#include "src/hb-buffer-serialize.cc"
#include "src/hb-buffer.cc"
#include "src/hb-common.cc"
#include "src/hb-face.cc"
#include "src/hb-font.cc"
#include "src/hb-ot-tag.cc"
#include "src/hb-set.cc"
#include "src/hb-shape.cc"
#include "src/hb-shape-plan.cc"
#include "src/hb-shaper.cc"
#include "src/hb-unicode.cc"
#include "src/hb-warning.cc"

// OT Sources

#include "src/hb-ot-font.cc"
#include "src/hb-ot-layout.cc"
#include "src/hb-ot-map.cc"
#include "src/hb-ot-shape.cc"
#include "src/hb-ot-shape-complex-arabic.cc"
#include "src/hb-ot-shape-complex-default.cc"
#include "src/hb-ot-shape-complex-hangul.cc"
#include "src/hb-ot-shape-complex-hebrew.cc"
#include "src/hb-ot-shape-complex-indic.cc"
#include "src/hb-ot-shape-complex-indic-table.cc"
#include "src/hb-ot-shape-complex-myanmar.cc"
#include "src/hb-ot-shape-complex-thai.cc"
#include "src/hb-ot-shape-complex-tibetan.cc"
#include "src/hb-ot-shape-complex-use.cc"
#include "src/hb-ot-shape-complex-use-table.cc"
#include "src/hb-ot-shape-normalize.cc"
#include "src/hb-ot-shape-fallback.cc"

// UCDN Sources

#include "src/hb-ucdn.cc"
#include "src/hb-ucdn/ucdn.c"

// Freetype Sources

#include "src/hb-ft.cc"
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz

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

[Behdad Esfahbod]

Thanks Daniel.  I'm not opposed to the idea if it doesn't introduce too many
hacks.  Might take a look at it myself even.

On 15-12-28 11:00 PM, Daniel Ribeiro Maciel wrote:
> I can write a '.cc' file which includes all other '.cc' files and defines a
> bunch of stuff if you guys are willing to add such file to your source tree.
> 
> On Tue, Dec 15, 2015 at 11:14 AM, 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.
> 
> 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.
> 
> On Tuesday, December 15, 2015, Behdad Esfahbod  > 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.
> 
> 
> ___
> HarfBuzz mailing list
> HarfBuzz@lists.freedesktop.org 
> http://lists.freedesktop.org/mailman/listinfo/harfbuzz
> 
> 
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz

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

[Daniel Ribeiro Maciel]

I can write a '.cc' file which includes all other '.cc' files and defines a
bunch of stuff if you guys are willing to add such file to your source tree.

On Tue, Dec 15, 2015 at 11:14 AM, 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.
>
> 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.
>
> On Tuesday, December 15, 2015, Behdad Esfahbod 
> 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.
>>
>
> ___
> HarfBuzz mailing list
> HarfBuzz@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/harfbuzz
>
>
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz

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

[Behdad Esfahbod]

On 15-12-16 12:06 AM, Jamie Dale wrote:
> The way I handled this was to create a define called HAVE_STUB_GETENV (which
> is a really weird name in hindsight) in my config.h file. I then just set that
> define, along with HAVE_INTEL_ATOMIC_PRIMITIVES, when building for PS4.
> 
> I'm not sure if you'd want to take that into HarfBuzz proper, or whether you'd
> want a better way?

If there's a macro to detect PS4, we can add that.  We already do that for 
WinCE:

#  if defined(_WIN32_WCE)
 /* Some things not defined on Windows CE. */
#define strdup _strdup
#define getenv(Name) NULL
#if _WIN32_WCE < 0x800
#  define setlocale(Category, Locale) "C"
static int errno = 0; /* Use something better? */
#endif
...

behdad


> #ifdef HAVE_STUB_GETENV
> // Stub out getenv as not all platforms support it
> #define getenv(name) 0
> #endif // HAVE_STUB_GETENV
> 
> -Jamie.
> 
>   This email has been sent from a virus-free computer protected by Avast.
> www.avast.com
> 
> 
> 
> <#DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> 
> On 15 December 2015 at 11:40, Behdad Esfahbod  > 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.
> 
> 
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz

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

[Konstantin Ritt]

Is Makefile format really that hard to understand?
It took 15 minutes for me to port the build rules fin Makefile to my build
tool. That's definitely less than I spent reading this thread, BTW ;)


Konstantin

2015-12-15 20:23 GMT+03:00 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 
> 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.esfah...@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.
>> >
>>
>
> ___
> HarfBuzz mailing list
> HarfBuzz@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/harfbuzz
>
>
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz

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

[Behdad Esfahbod]

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.
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz

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

[Jiang Jiang]

On Tue, Dec 15, 2015 at 9: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.
>
> 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.

Bootstrap with an autoconf/automake build system is never very Windows
friendly, I'd say it's quite hostile to Windows developers. I guess
switching to CMake can be a huge step forward for Windows developers
if someone is willing to maintain it.

That said, both Gecko and Chromium have their own build systems to
build HarfBuzz, which can be an easier start, however those projects
rarely allows you to have a standalone HarfBuzz checkout or build
*only* the HarfBuzz library.

- Jiang

>
> On Tuesday, December 15, 2015, Behdad Esfahbod 
> 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.
>
>
> ___
> HarfBuzz mailing list
> HarfBuzz@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/harfbuzz
>
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz

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

[Werner LEMBERG]

> It seems to me that the best way to do this is just to provide one
> .cpp file that just includes everything else.  [...]

Cf.

  https://github.com/vinniefalco/FreeTypeAmalgam
  https://github.com/vinniefalco/Amalgams/


 Werner
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz

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

[Konstantin Ritt]

Hmm...
Good luck with that ;P


Konstantin

2015-12-13 10:40 GMT+04:00 Jonathan Blow :

> Hi,
>
> I just got through hooking HarfBuzz into a project that runs on Windows
> (and Monday we get to make sure it runs on the PS4 as well). Even with the
> help of Daniel Maciel here, who had done a similar thing already, it still
> took me a couple of hours all together.
>
> The thing is there's no reason for that, and I think there are lots of
> people out there who would like to use HarfBuzz on a variety of platforms
> if (a) they knew it existed, and (b) they knew they could just use it.
>
> It might seem that supporting Windows, random game consoles, etc, takes a
> lot of development work, but actually the opposite is true; all that needs
> to happen is removal of the dependency on an OS-dependant build system --
> then the problem just goes away.
>
> It seems to me that the best way to do this is just to provide one .cpp
> file that just includes everything else. That way you just add a cpp to
> your project, include one .h where you want to use it, and you're done --
> you don't have to worry about having build tools installed, static vs
> dynamic linkage, syncing up 64 vs 32-bit libraries, keeping straight all
> the precompiled libraries for all your OSs, etc.
>
> In general among people I know who ship software that runs on many OSs,
> this is the solution that has stood the test of time and is simple and just
> works for the maximum number of people. (Actually the absolute best thing
> to do, from a usability standpoint, is to pack everything into just one
> actual text file -- as in the stb libraries [
> https://github.com/nothings/stb] -- but beyond some size of project this
> may reduce understandability, so given that, an include-all cpp file is a
> reasonable compromise).
>
> Of course now that I have got this working for my current project, the
> strife involved in building does not matter so much for me, but as with any
> library the multiplier of any time saved becomes enormous the more people
> use the software. Conversely, a lot of programmers out there get a lot more
> powerful as soon as they don't have to deal with a bunch of friction in
> integrating some code.
>
> ___
> HarfBuzz mailing list
> HarfBuzz@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/harfbuzz
>
>
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz