> [...] I'm interested in the decision under a situation: if harfbuzz
> requires libstdc++, should we care the dependency of FreeType?
Please elaborate. Given that FreeType is a C library it's not clear
to me why there should be an issue – FreeType happily works without
HarfBuzz (then with
Le jeu. 30 avr. 2020 à 10:40, Nikolaus Waxweiler 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
>
One thing regarding build systems and IDE/tool integration:
Cmake and others can generate a
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
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
suzuki toshiya writes:
> Is there any recommended alternative? Or, should we accept
> the "modern" situation where we have to execute twice to build
> shared and static libraries?
X and Mesa have switched to Meson, and I've used it in a couple of other
projects (including picolibc). On POSIX
On Wed, Apr 29, 2020 at 10:17 PM suzuki toshiya
wrote:
> It is a pity that I hear the lack of -fvisibility=hidden is
> not only current status but promised in the future release X-(.
Suzuki san,
We have -fvisibility=hidden despite libtool.
Alexei
Dear Alexei, Turner,
It is a pity that I hear the lack of -fvisibility=hidden is
not only current status but promised in the future release X-(.
BTW, during the participation to Poppler and SVG Native Viewer,
I had big headache by the CMake's lack of the seamless (or
side-by-side) support for
