> Here's what I have so far:
> https://github.com/madig/freetype2/blob/modernize-cmake-build/CMakeLists.txt
Thanks for working on this.
> One difference is in how export/import attributes are
> triggered. [...]
Note that some very recent commits to HarfBuzz change symbol
visibility, cf. commit
On Sun, Mar 18, 2018 at 9:45 AM, Nikolaus Waxweiler wrote:
> I have to pass in FT2_BUILD_LIBRARY for static and shared builds, otherwise
> I get plenty of errors. Shouldn't this only be necessary for shared builds?
There are other places where FT2_BUILD_LIBRARY is used besides the
visibility cont
So I've been trying to make the CMakeLists.txt file a bit neater. CMake
is sadly not an elegant build system...
Here's what I have so far:
https://github.com/madig/freetype2/blob/modernize-cmake-build/CMakeLists.txt
I cribbed the SO version thing from
https://git.libssh.org/projects/libssh.g
2018-03-16 5:32 GMT+05:00 Nikolaus Waxweiler :
> Damn! Well, in the name of testing if the minimum version actually works,
I
> suggest bumping the requirement to 2.8.11.2 because that will actually get
> testing via freetype-py. Not a great win for me though.
>
> Now, if the features Azamat suggest
> So.. regarding a minimum version. I'm building FreeType for bundling
> with freetype-py and I'm using
> https://github.com/matthew-brett/multibuild to build it on Linux and
> macOS. For Linux, a CentOS 5.11 image is used to build stuff
> (https://github.com/pypa/manylinux), which comes with CMak
So.. regarding a minimum version. I'm building FreeType for bundling
with freetype-py and I'm using
https://github.com/matthew-brett/multibuild to build it on Linux and
macOS. For Linux, a CentOS 5.11 image is used to build stuff
(https://github.com/pypa/manylinux), which comes with CMake 2.8.1
2018-03-14 19:24 GMT+05:00 Nikolaus Waxweiler :
>
> Good to hear from someone who seems to know something about CMake :)
> Do you see any other room for improvement of CMakeLists.txt? My gut
> feeling tells me there is.
Of course, there is much to do:
1. pkg-config module file autogeneration and i
> I'd say only do this if there are *important* improvements. It seems to me
> that bumping the version for just a single statement is overkill.
:( okay
> I suggest yes, but I'm not a CMake user... Is there a reason you would what
> differently versioned or named libraries?
Dunno. I only car
> I'd be happy to bump the version requirement, I love getting rid of
> legacy software.
I'd say only do this if there are *important* improvements. It seems
to me that bumping the version for just a single statement is
overkill.
> Yeah, about the library version... Werner, should we just track
Good to hear from someone who seems to know something about CMake :)
Do you see any other room for improvement of CMakeLists.txt? My gut
feeling tells me there is.
I'd be happy to bump the version requirement, I love getting rid of
legacy software.
Yeah, about the library version... Werner, shoul
Hello.
Few comments about CMake project.
Nikolaus, you replaced PROJECT_VERSION with project(freetype VERSION ...)
but this syntax requires cmake >= 3.0, so you need to bump
cmake_minimum_required() statement.
Also there in CMakeList.txt typo around in line 430 (excess curly bracket
on end):
set(
More CMakeLists.txt tweaks.
- Minor version variable cleanup
- Enable implicit symbol hiding for static and shared builds
s.patch
Description: Binary data
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listin
Certainly. You are welcome to set something up! I was too lazy to
do it myself...
:)
I'm currently looking at size and symbol differences of libfreetype (on
Fedora 27 x86_64, GCC 7.3.1) when compiling with Autotools and CMake. I
built the shared lib both times without changing any options.
> Playing with CI services made me wonder if that would be something
> useful for FT as well? I'm thinking of building the library with
> different compilers and different build systems and running some
> basic smoke tests to ensure nothing rots away without us knowing.
Certainly. You are welco
One more thing: the CMake system generates filenames like
"libfreetype.so.2.9.0", whereas the default autotools-based one
generates something like "libfreetype.so.6.16.0" -- is this
intentional?
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
h
Thanks Werner and Chun-wei Fan :)
Playing with CI services made me wonder if that would be something
useful for FT as well? I'm thinking of building the library with
different compilers and different build systems and running some basic
smoke tests to ensure nothing rots away without us knowing.
> I find that simply deleting the fatal error if-clause works and
> according to http://www.nirsoft.net/utils/dll_export_viewer.html, the
> following symbols are exported: https://pastebin.com/5YYRz65H.
Good.
I do not see DLL_EXPORT defined in the CMakeLists.txt even though MSVC
might define _DLL
Ah, I always forget about Savannah :D
I find that simply deleting the fatal error if-clause works and
according to http://www.nirsoft.net/utils/dll_export_viewer.html, the
following symbols are exported: https://pastebin.com/5YYRz65H.
So I suppose we can simply delete the fatal error if-clause :)
> Turns out that Microsoft has some CMake patches lying around for
> FreeType:
> https://github.com/Microsoft/vcpkg/tree/master/ports/freetype. I
> think 0001 is of particular interest (not sure what to make of 0002
> and 0003), so you don't have to use MingW to build DLLs.
>
> Can we include it
19 matches
Mail list logo
