[prev in list] [next in list] [prev in thread] [next in thread]
List: freetype-devel
Subject: Re: [Freetype-devel] Re: Build system considerations
From: David Turner <david () freetype ! org>
Date: 2020-04-30 23:00:44
Message-ID: CAMr8+-1EysTHw=-j=O8m0MLbKHkcH2AdHEhWoASwqkqKkb8tPA () mail ! gmail ! com
[Download RAW message or body]
Le jeu. 30 avr. 2020 Ã 10:40, Nikolaus Waxweiler <madigens@gmail.com> a
écrit :
> One thing regarding build systems and IDE/tool integration:
>
> Cmake and others can generate a
> https://clang.llvm.org/docs/JSONCompilationDatawas a portabililty
> nightmarebase.html
> <https://clang.llvm.org/docs/JSONCompilationDatabase.html> that help
> tools like static analyzers and language servers and IDEs parse
> projects. It's very nice have when you hack on something.
>
> It also means that you have to have an entry for every single .c file,
> unless I'm missing something. FreeType bundles several .c files into
> bigger .c files, breaking the database. Werner mentioned that this is
> done because older compilers have worse inlining or dead code
> elimination or something like that. It would still be nice to have the
> database.
>
> The wrapper source files are used for two reasons:
1) Speed up compilation (though this is less of an issue with today's
powerful CPUs and multiple cores)
2) Much better / smaller generated machine code, because all FT_LOCAL
functions are really "static" and can be freely inlined by the simplest
compiler.
Getting the same level of optimization without wrappers requires
link-time-optimization (LTO), which may or may not be available depending
on the toolchain you're using, and cannot always be enabled by projects
embedding the library for multiple reasons (LTO is super slow, ThinLTO
makes it slightly better, but only if you use Clang, etc).
Apart from that, it would be easy to write a script to generate the proper
compilation database from the rules.mk/module.mk file with the patches I've
submitted to the mailing list (in another thread).
Also other tools can output such a database (e.g. GN has
--export-compile-commands=default for example, not sure about Meson).
Something to consider when cleaning up the build system :)
>
> 2020-04-30 9:11 GMT+01:00, suzuki toshiya <mpsuzuki@hiroshima-u.ac.jp>:
> > The circular dependency is a headache, but I don't think the
> > reconsideration of the building system is good place to discuss
> > the simplification of the dependency between FreeType and harfbuzz.
> >
> > In my understanding, the features of harfbuzz used by FreeType are
> > very small subset, the classification of character encoding, script
> > and language. Although I sympathize with the circular dependency
> > problem, it would not be good idea to cloning them into FreeType
> > source code, because of the different time-frames between FreeType
> > and Unicode related features of harfbuzz (or Unicode itself).
> >
> > Some meta-building system would be the easiest way to avoid the
> > manual and repeated building of FreeType and harfbuzz, aslike some
> > GNU toolchains (binutils + gcc + gdb) ?
> >
> > Regards,
> > mpsuzuki
> >
> > P.S.
> > But, I'm interested in the decision under a situation: if harfbuzz
> > requires libstdc++, should we care the dependency of FreeType?
> >
> >
> > Vincent Torri wrote:
> >> On Thu, Apr 30, 2020 at 8:39 AM Werner LEMBERG <wl@gnu.org> wrote:
> >>>
> >>>> currently, to have harfbuzz support, freetype must be compiled
> >>>> without hb support, then build hb with freetype support, then
> >>>> freetype with hb.
> >>>>
> >>>> it would be nice to remove this circular dependency
> >>> AFAIK, this would only be possible by splitting either HarfBuzz or
> >>> FreeType into two packages, and this won't happen.
> >>
> >> or moving/coying some functions from freetype to hb, or conversely ?
> >>
> >> Vincent Torri
> >>
> >>
> >
> >
>
>
[Attachment #3 (text/html)]
<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" \
class="gmail_attr">Le jeu. 30 avr. 2020 Ã 10:40, Nikolaus Waxweiler <<a \
href="mailto:madigens@gmail.com">madigens@gmail.com</a>> a écrit \
:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">One thing regarding \
build systems and IDE/tool integration:<br> <br>
Cmake and others can generate a<br>
<a href="https://clang.llvm.org/docs/JSONCompilationDatabase.html" rel="noreferrer" \
target="_blank">https://clang.llvm.org/docs/JSONCompilationDatawas a \
<span>portabililty</span> nightmarebase.html</a> that help<br> tools like static \
analyzers and language servers and IDEs parse<br> projects. It's very nice have \
when you hack on something.<br> <br>
It also means that you have to have an entry for every single .c file,<br>
unless I'm missing something. FreeType bundles several .c files into<br>
bigger .c files, breaking the database. Werner mentioned that this is<br>
done because older compilers have worse inlining or dead code<br>
elimination or something like that. It would still be nice to have the<br>
database.<br>
<br></blockquote><div>The wrapper source files are used for two \
reasons:</div><div><br></div><div>1) Speed up compilation (though this is less of an \
issue with today's powerful CPUs and multiple \
cores)<br><br></div><div></div><div>2) Much better / smaller generated machine code, \
because all FT_LOCAL functions are really "static" and can be freely \
inlined by the simplest compiler.</div><div>Getting the same level of optimization \
without wrappers requires link-time-optimization (LTO), which may or may not be \
available depending on the toolchain you're using, and cannot always be enabled \
by projects embedding the library for multiple reasons (LTO is super slow, ThinLTO \
makes it slightly better, but only if you use Clang, etc).<br></div><br></div><div \
class="gmail_quote">Apart from that, it would be easy to write a script to generate \
the proper compilation database from the <a \
href="http://rules.mk/module.mk">rules.mk/module.mk</a> file with the patches \
I've submitted to the mailing list (in another thread).<br></div><div \
class="gmail_quote">Also other tools can output such a database (e.g. GN has \
--export-compile-commands=default for example, not sure about Meson).<br></div><div \
class="gmail_quote"></div><div \
class="gmail_quote"><div></div><div><br></div><blockquote class="gmail_quote" \
style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"> Something to consider when cleaning up the build \
system :)<br> <br>
2020-04-30 9:11 GMT+01:00, suzuki toshiya <<a \
href="mailto:mpsuzuki@hiroshima-u.ac.jp" \
target="_blank">mpsuzuki@hiroshima-u.ac.jp</a>>:<br> > The circular dependency \
is a headache, but I don't think the<br> > reconsideration of the building \
system is good place to discuss<br> > the simplification of the dependency between \
FreeType and harfbuzz.<br> ><br>
> In my understanding, the features of harfbuzz used by FreeType are<br>
> very small subset, the classification of character encoding, script<br>
> and language. Although I sympathize with the circular dependency<br>
> problem, it would not be good idea to cloning them into FreeType<br>
> source code, because of the different time-frames between FreeType<br>
> and Unicode related features of harfbuzz (or Unicode itself).<br>
><br>
> Some meta-building system would be the easiest way to avoid the<br>
> manual and repeated building of FreeType and harfbuzz, aslike some<br>
> GNU toolchains (binutils + gcc + gdb) ?<br>
><br>
> Regards,<br>
> mpsuzuki<br>
><br>
> P.S.<br>
> But, I'm interested in the decision under a situation: if harfbuzz<br>
> requires libstdc++, should we care the dependency of FreeType?<br>
><br>
><br>
> Vincent Torri wrote:<br>
>> On Thu, Apr 30, 2020 at 8:39 AM Werner LEMBERG <<a \
href="mailto:wl@gnu.org" target="_blank">wl@gnu.org</a>> wrote:<br> \
>>><br> >>>> currently, to have harfbuzz support, freetype must \
be compiled<br> >>>> without hb support, then build hb with freetype \
support, then<br> >>>> freetype with hb.<br>
>>>><br>
>>>> it would be nice to remove this circular dependency<br>
>>> AFAIK, this would only be possible by splitting either HarfBuzz or<br>
>>> FreeType into two packages, and this won't happen.<br>
>><br>
>> or moving/coying some functions from freetype to hb, or conversely ?<br>
>><br>
>> Vincent Torri<br>
>><br>
>><br>
><br>
><br>
<br>
</blockquote></div></div>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic