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 <[email protected]>: > 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 <[email protected]> > 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 < >> [email protected] >> > <mailto:[email protected]>> 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 > [email protected] > http://lists.freedesktop.org/mailman/listinfo/harfbuzz > >
_______________________________________________ HarfBuzz mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/harfbuzz
