Le mar. 19 mai 2020 à 14:09, Hugh McMaster a
écrit :
> On Mon, 18 May 2020 at 23:59, Werner LEMBERG wrote:
> > > - Meson as the primary build system for FreeType developers, which
> > > includes the ability to run tests, sanitizers, coverage analysis,
> > > etc.
> >
> > It seems that Meson
On Tue, May 19, 2020 at 10:59 AM Ben Wagner wrote:
> > [Presently, FT_CONFIG_OPTION_SUBPIXEL_RENDERING only alternates
> > between ClearType and Harmony algorithms. Most users won't be able
> > to tell them apart.]
>
> Note that some users of FreeType are never going to use subpixel
> rendering
Le mar. 19 mai 2020 à 10:05, Alexei Podtelezhnikov
a écrit :
>
> On Tue, May 19, 2020 at 8:09 AM Hugh McMaster
> wrote:
> > Is there any opportunity to avoid modifying ftoption.h directly to
> > enable, say, subpixel rendering with a new build system? Carrying
> > permanent patches for
On Tue, May 19, 2020 at 8:09 AM Hugh McMaster wrote:
> Is there any opportunity to avoid modifying ftoption.h directly to
> enable, say, subpixel rendering with a new build system? Carrying
> permanent patches for downstream packaging is annoying.
[Presently, FT_CONFIG_OPTION_SUBPIXEL_RENDERING
On Mon, 18 May 2020 at 23:59, Werner LEMBERG wrote:
> > - Meson as the primary build system for FreeType developers, which
> > includes the ability to run tests, sanitizers, coverage analysis,
> > etc.
>
> It seems that Meson can create cmake package files, and probably build
> scripts, too.
Let me think about the HarfBuzz co-dependency a bit...
On Mon, May 18, 2020 at 12:26 PM Behdad Esfahbod wrote:
> Hi David,
>
> Thanks for experimenting with this!
>
> I encourage you to explore removing the Module and Service abstraction
> completely. We did that in Pango a couple of years ago
Hi David,
Thanks for experimenting with this!
I encourage you to explore removing the Module and Service abstraction
completely. We did that in Pango a couple of years ago and never looked
back...
I'll reply to your original request this week. Threadsafety and lack of a
functional separate
>> > In the end, and this is personal opinion, I find Meson cleaner than
>> > CMake,
I don't have to have a look at Meson to believe this immediately :-)
>> I'd vote for removing CMake support. Its inofficial status means that
>> people shouldn't rely on it anyway, even if there inevitably are
Also note different optimisation levels. The make system uses -O2 by
default.
On Mon, May 18, 2020 at 8:44 AM David Turner wrote:
>
>
>
> Le dim. 17 mai 2020 à 21:47, Nikolaus Waxweiler a écrit :
>>
>> First off: all of this sounds fantastic! I always love when stuff is deleted
>> :)
>>
>> > In the end, and this is personal opinion, I find Meson cleaner than CMake,
>>
>>
Le dim. 17 mai 2020 à 21:47, Nikolaus Waxweiler a
écrit :
> First off: all of this sounds fantastic! I always love when stuff is
> deleted :)
>
> > In the end, and this is personal opinion, I find Meson cleaner than
> CMake,
>
> I'd vote for removing CMake support. Its inofficial status means
That sounds very good.
Personally I'd be very happy to see the header inclusion macros gone where
possible, because they confuse both users and IDEs. I would also be very
happy to see meson support, because it seems to be gaining usage nicely and
I do find it nicer than CMake.
I'd be a bit sad
Le dim. 17 mai 2020 à 21:47, Nikolaus Waxweiler a
écrit :
> First off: all of this sounds fantastic! I always love when stuff is
> deleted :)
>
> > In the end, and this is personal opinion, I find Meson cleaner than
> CMake,
>
> I'd vote for removing CMake support. Its inofficial status means
First off: all of this sounds fantastic! I always love when stuff is deleted :)
> In the end, and this is personal opinion, I find Meson cleaner than CMake,
I'd vote for removing CMake support. Its inofficial status means that
people shouldn't rely on it anyway, even if there inevitably are
Continuing my own thread, after taking the time to experiment a little.
First, I've refactored the build system so we turn the rules.mk into
declarative files (instead of Makefile fragments) and get rid of the
module.mk files.
This allowed me to write a Python script to parse modules.cfg and the
>
> I apologize if somebody felt personally wronged by my comment.
>
> Since I don't see anything wrong with it, I would be very happy if you could
> please explain what's wrong with it so I can try to improve myself in the
> future.
Rather easy. I am sure this is not how you communicate with
Le ven. 1 mai 2020 à 10:12, Albert Astals Cid a écrit :
>
>
> I apologize if somebody felt personally wronged by my comment.
>
> Since I don't see anything wrong with it, I would be very happy if you
> could please explain what's wrong with it so I can try to improve myself in
> the future.
>
>
> [...] 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
El divendres, 1 de maig de 2020, a les 0:52:16 CEST, David Turner va escriure:
> Le jeu. 30 avr. 2020 à 23:33, Albert Astals Cid a écrit :
>
> > El dijous, 30 d’abril de 2020, a les 19:35:19 CEST, Behdad Esfahbod va
> > escriure:
> > > Hi David,
> > >
> > > Thanks for bringing this up. I come
David Turner writes:
> for ten different Unix-like system is a portability nightmare.
> On the other hand, building them for a standard Linux distribution, or OS
> X, is a well known problem, so we may consider keeping autotools/libtool as
> an escape hatch for esoteric systems that still exist,
> I'm not sure you realize that what you wrote sounds insensitive and is
> bordering ad-hominen.
> You could have said that you disagree and that this doesn't match your
> experience for example.
> Instead you tone devalues the point you're trying to make.
+1
> A) One of the major features of
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
>
Le jeu. 30 avr. 2020 à 03:30, Alexei Podtelezhnikov a
écrit :
> On Wed, Apr 29, 2020 at 8:34 PM David Turner wrote:
> >
> > Starting a thread here to discuss potential build system improvements
> for FreeType.
> >
> > The current FreeType 2 build system has many flaws. To its credit, it
> was
Le jeu. 30 avr. 2020 à 23:33, Albert Astals Cid a écrit :
> El dijous, 30 d’abril de 2020, a les 19:35:19 CEST, Behdad Esfahbod va
> escriure:
> > Hi David,
> >
> > Thanks for bringing this up. I come from the GNOME camp. My
> understanding
> > is that meson is replacing autotools longterm,
El dijous, 30 d’abril de 2020, a les 19:35:19 CEST, Behdad Esfahbod va escriure:
> Hi David,
>
> Thanks for bringing this up. I come from the GNOME camp. My understanding
> is that meson is replacing autotools longterm, sidestepping attempts like
> cmake, the same way that git replaced CVS,
Hi David,
Thanks for bringing this up. I come from the GNOME camp. My understanding
is that meson is replacing autotools longterm, sidestepping attempts like
cmake, the same way that git replaced CVS, sidestepping mercurial, bazaar,
etc.
In the latest HarfBuzz release we added a meson build
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
On Thu, Apr 30, 2020 at 8:39 AM Werner LEMBERG 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
> 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
> Most serious projects I have encountered so far use ./configure;
> make. It is the libtool that annoys me. They refused to implement
> -fvisibiity=hidden when I asked. They said that libtool was current
> when building shared libraries was hard, which is actually true.
> Let's just get rid
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 Thu, Apr 30, 2020 at 2:34 AM David Turner wrote:
>
> Starting a thread here to discuss potential build system improvements for
> FreeType.
currently, to have harfbuzz support, freetype must be compiled without
hb support, then build hb with freetype support, then freetype with
hb.
it would
On Thu, Apr 30, 2020 at 2:34 AM David Turner wrote:
>
> Starting a thread here to discuss potential build system improvements for
> FreeType.
>
> The current FreeType 2 build system has many flaws. To its credit, it was
> designed in a very different time, when things like CMake / Meson /
> [...] I have experience with CMake (I find it a vast improvement
> over auto-tools for package / feature detection, but a hot mess for
> about anything else), GN/Ninja (very powerful, but essentially
> requires too much dependencies to get the most out of it) and Bazel
> (can be hard to get
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
On Wed, Apr 29, 2020 at 8:34 PM David Turner wrote:
>
> Starting a thread here to discuss potential build system improvements for
> FreeType.
>
> The current FreeType 2 build system has many flaws. To its credit, it was
> designed in a very different time, when things like CMake / Meson /
38 matches
Mail list logo
