Hi @jtanx,
The wiki has a syntax error and needs to be corrected to:

git clone https://github.com/fontforge/fontforge; cd fontforge; mkdir build; cd build

'&&' actually means fork and run in parallel while ';' means run sequentially afterwards.
DOS was unable to run more than one program at a time, so this was a good kludge to fake '&&' behaviour, and windows inherited this behaviour for backwards compatibility reasons.

Next, this is an error which reflects packaging

# Sigh, the old build system checks for the non-existant LibSpiroGetVersion

You'll want to add code to differentiate the recent 20190731 release from the older versions of libspiro that don't have it. FontForge has had code that uses this instruction since 2015.
It wasn't added to Libspiro (on purpose) until now because I wanted to add some pretty big changes like CRA bug fix first before the tag release point. LibSpiroGetVersion() coincides with the tag point, and therefore is a marker for operating systems that have/had faulty packaging, or if you want to use packaging as your go-to method, then use packaging instead (...but watch out for the BSDs and older LTS like maybe Redhat, Centos, maybe others).

&&'

I don't know what interpreter you're using, but that's plain wrong with bash and cmd. Please read this.

You'll want to add code to differentiate the recent 20190731 release from the older versions of libspiro that don't have it

See, this would be a non-issue if the version was just added to the header, as I previously mentioned, and which could have easily been done before 20190731 was cut. Now I have to go and add yet more of these dumb feature detection methods.

My error, you're right, I was thinking '&' which had to be fixed elsewhere for something else.

See, this would be a non-issue if the version was just added to the header, as I previously mentioned, and which could have easily been done before 20190731 was cut. Now I have to go and add yet more of these dumb feature detection methods.

At this point, version control is all in one place : at the top of configure.ac
If you are testing for a package version#, it might work, depending on which os and version.

libuninameslist has version numbers in the header - let's see your improvement.

At this point, version control is all in one place : at the top of configure.ac
If you are testing for a package version#, it might work, depending on which os and version.

That's moot, because that's not accessible from the header.

libuninameslist has version numbers in the header - let's see your improvement.

I don't understand why it doesn't just have

#define LIBUNINAMESLIST_VERSION 2019xxx

But anyway, assuming LIBUNINAMESLIST_MAJOR/LIBUNINAMESLIST_MINOR is kept up to date, we can get rid of all this garbage and just check LIBUNINAMESLIST_MAJOR/MINOR directly.

Of course, that doesn't help with older versions, which was why it should have been included in the last libspiro release.

Looking at that code, we should probably clean it up anyway and just drop support for older versions of libspiro/libuninameslist.

I was looking forward to your solution using headers or packaging, etc. with libuninameslist

I guess I'll have to accept you at least removed the inflammatory comments.

I suggest folding libuninameslist into FontForge, dropping support for external library and simplifying the code. The library is nit used by anything else, so all this complexity is not warranted.

I’d go even further and suggest doing this for libspiro, but it seems to have at least one user other than FontForge, so that might be a controversial decision.

I suggest folding libuninameslist into FontForge, dropping support for external library and simplifying the code. The library is nit used by anything else, so all this complexity is not warranted.

I’m working on this.

#3861

Yeah, that's actually not a bad idea, nice.

Are there any other questions/concerns/comments about this? Otherwise I'd like to look at getting this in soon.

I tried it today while working on other stuff and actually quite like it. So, no negative comment, only a positive one in support :-)

I did a code review that wasn't conclusive either way, which basically means I didn't see any problems but wasn't confident enough to offer an assessment.

Given that this is build infrastructure it seems to me that there are two conventional ways of going:

1. Have some folks volunteer to use it for a while as a side project, periodically pulling over changes from the master branch.
2. Switch the master branch to it and shake out any issues in place.

I'm happy to "vote" for option 2 in this case.

Alright, option 2 works for me too. If there really are no further comments on this, then I'll be looking at merging this in a day or two.

@frank-trampe, still waiting for details on how that ppa works, so that Packaging can be updated.

Great! A bonus of this is that I don't think my libtool command line is needed anymore. The system libfontforge.so no longer seems to override—finally! So that can probably be removed from CONTRIBUTING.md.

This might be why:

[fred@pc fontforge]$ ls -alh bin/fontforge # With cmake
-rwxr-xr-x 1 fred fred 15M Aug 15 16:21 bin/fontforge
[fred@pc fontforge]$ ls -alh `which fontforge` # Autotools build
-rwxr-xr-x 1 root root 57K Aug  9 19:51 /usr/local/bin/fontforge

A bonus of this is that I don't think my libtool command line is needed anymore. The system libfontforge.so no longer seems to override—finally!

Yeah, this is because cmake actually sets the RPATH properly (and changes it again when it gets installed). So it's always looking for the right dll when you invoke it from the build folder

(My libtool command still works, I just don't think it's necessary anymore. It might be a good precaution still, though, as I did not test thoroughly. As a reminder, it's:

#!/bin/sh
DIR=bin # Change to `fontforgeexe` for autotools builds
libtool --mode=execute gdb -ex "run ${1@Q}" $DIR/fontforge

)

Sorry, commented before seeing yours! That makes sense.

I just found out about the switch and I think it's great! Thank you for this! I always cheer when autotools are removed from something. I took the liberty to edit the Wiki build instructions slightly to make them more cmake-y.