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,
Here are two cumulative patches that try to simplify the rules.mk and
module.mk used by the FreeType 2 build system. The point is to remove
GNU-Make specific statements from these files, making them declarative
instead. I.e. after applying the first patch, a module.mk will contain
something like:
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
Responding to all the scattered bits of this thread I know something
about...
> Skia: https://github.com/google/skia/tree/master/third_party/freetype2
> modules: no raster1, type1, pfr, bitmapped formats
> options: seems to be using the default, i.e. no subpixel rendering, no
> harfbuzz, no
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
(oops, forgot to send to the list)
-- Forwarded message --
From: Nikolaus Waxweiler
Date: Thu, 30 Apr 2020 09:28:34 +0100
Subject: Re: I'm back
To: David Turner
> Can you clarify what that means exactly? I think I lack context and/or
> examples :-)
See
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
17 matches
Mail list logo
