linux port now on my opencompiler-port branch (the default)

[HinTak]

It probably would work with mac too. native compile just do "cd src; make". For cross-compiling for windows, make CXX=i686-w64-mingw32-c++ (32-bit) or make CXX=x86_64-w64-mingw32-c++ (64-bit).

https://github.com/HinTak/VisualTrueType

[madig]

I'd like to see the changes upstream, any plans?

[HinTak]

Fixed up more stuff so you can do "cd src ; make CXX=clang++" to build with clang too. And took and adapted Georg Seifert's xcode proj stuff too, so it should build on macs whether you want to use xcode gui or plain make.

[HinTak]

I just signed the cla for a pull, and as it stands, I think it does everything it claims to do (within reasons) and does not affect visual studio builds, so this can indeed be a pull.

But one reason of not creating a pull, besides the objection of signing a CLA, is issue with CLA by-pass and random crap being added by somebody else: not thinking about CLA and pulls, means I can include things like Georg's xcode stuff on merits alone (Georg may object to signing CLAs...), I can do changes like converting comments from windows encoding to utf8 - not necessary, just a conveniences to utf-8 people at the expense of inconvenience to windows encoding people; and I can object to including random people's requests to add random crap, like a cmake-based build system - I honestly do no want it, and if upstream adds such thing, I will refuse to do a pull to donate my work to be sitting next to some random crap :).

[HinTak]

For those who want to fix warnings, do "make ... CXXFLAGS=-Wall" . I don't want to put it into the Makefile yet, as the build already have warnings without it (and those are more important and should be looked at first)

[HinTak]

I am splitting out "no need to debate" changes as individual pulls... But for example, I don't want to take bulk formatting /cosmetic or indentation changes at this stage, and the conversions from windows encoding to utf8 in the comments I did, I would find that objectionable if somebody else do that amount of changes in comments and try to push in my direction :). (it makes the comoments more readable to utf8 unix people, but less readable to windows visual studio people...)

[jenskutilek]

I get an error when I try to build your fork on macOS:

$ make
c++    -c -o Area.o Area.cpp
c++    -c -o CvtManager.o CvtManager.cpp
In file included from CvtManager.cpp:8:
./pch.h:22:10: fatal error: 'span' file not found
#include <span>
         ^~~~~~
1 error generated.
make: *** [CvtManager.o] Error 1

I don't know a whole lot about C++, so I'm not sure what might cause this.

[HinTak]

@jenskutilek how old is your default command-line c++ compiler (c++ --version)? That file is part of the compiler. On linux's clang it is at "/usr/include/c++/v1/span".

You might need to add c++ development if xcode have optional components?

If it helps, there is an xcode project too. I believe recent xcode put up-to-date compilers (and multiple of them) under private places and leave the system-wide command line at old versions or not accessible.

[HinTak]

For gcc it is part of gcc's c++11 support, so you need a compiler that is less than 10 years old :).

Edit: on linux, I have two variants of that file, one at /usr/include/c++/v1/ and that belongs to clang, and another at /usr/include/c++/11/ and that belongs to gcc. The respective c++ compiler of each family uses its own versions.

[jenskutilek]

Hm, thanks, my computer is out of support, the Apple developer tools for XCode 10.0.0 are the newest version that can be installed. I get this:

$ c++ --version
Apple LLVM version 10.0.0 (clang-1000.10.44.4)
Target: x86_64-apple-darwin17.7.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin

Guess I have to wait until I can upgrade my computer :-/

[HinTak]

That is not particularly old - current clang is 12 or 13, and comparing that with Debian Linux, which is still shipping clang 6... Have a look around under /Library/Developer/ to see if you can find a file called span inside "c++/v1" somewhere? Do you have a directory /usr/include/c++ ? Hmm, actually I have xcode 9.x (for mac os x 10.13) zipped up from a mac, and the location is something like: ... Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/, but indeed span is not there, while codecvt is. So if your xcode is similarly old - xcode 9.x for 10.13 (which yours seems to be, darwin17), you might be out of luck. I don't know what version of old xcode that would compile this code, sorry, but 9.x for os x 10.13 seems too old according to the xcode 9.x bundle I have.

[HinTak]

Okay, found it - according to https://stackoverflow.com/questions/45723819/what-is-a-span-and-when-should-i-use-one and of course https://docs.microsoft.com/en-us/cpp/standard-library/span-class?view=msvc-160 , the <span> header is part of C++ 20 . That's the 2020 c++ standard (the one before was 2017)... So you need a c++ compiler that is QUITE up to date! 4 years old would be too old.

[HinTak]

Oh, it is microsoft visual studio being annoying - <span> is not used. ("pch.h" stands for "precompiled header" and just generic stuff populated by visual studio). Building with gcc or clang doesn't complain when that line is removed. I'll get rid of it now.

[paullinnerud]

When I reduced VTT for vttcompile, I was planning on using but then ended up using a different method given it's newness. I forgot to remove from pch.h.

[paullinnerud]

One question/concern I have with a port is VTT and vttcompile dependence on pragmas particularly on #pragma pack (1) to set structure packing and also #pragma once in some headers to avoid multiple includes. I have read somewhere that CLang supports #pragma pack(1) but GCC does not. I don't know if that's still correct. I think #pragma once is supported on both.