I'm looking to rework my Angelscript utility code to separate out the Angelscript library into its own repository. I figured that somebody else probably did it before, and so i searched for and found several repositories on Github containing old mirrors of the SDK, some with additional changes like CMake support. CMake support is provided in sdk/angelscript/projects/cmake, although it uses outdated syntax to support older versions of CMake.

At least one of these (https://github.com/svn2github/angelscript) was set up to automatically mirror the commits, but it seems that none of these repositories are still actively mirroring the commits.

So i'm wondering if there are any plans to set this up as part of the SVN repository's commit handling. Basically, a Github repository automatically receives commits as the SVN repository does, with tags pushed for version releases. It seems that commits that update version numbers always follow the same format: "Releasing major.minor.patch", so a script could detect this and add a tag to it.

It would make using Angelscript in projects easier and make the other mirrors obsolete (and prevent the creation of even more, as i almost did this myself), so it's a win-win for everybody.

On the subject of the CMake project file: there is no setup for install targets, which would usually install the library and the header file somewhere to be used. I'd suggest installing to <target>/angelscript_major_minor_patch, optionally installing shared libraries in lib/shared and static libraries in lib/static, with a FindXXX.cmake file to locate it automatically based on this. This is how Boost does it (specifically https://github.com/Kitware/CMake/blob/master/Modules/FindBoost.cmake#L1222), and lets you have multiple versions installed side by side.

Of course, it is ultimately up to the end user so having it detect the version some other way (like parsing angelscript.h for ANGELSCRIPT_VERSION_STRING) might be better. Boost searches for config.hpp in paths that adhere to the version number approach i mentioned above: https://github.com/Kitware/CMake/blob/master/Modules/FindBoost.cmake#L1240

Here's Boost's FindBoost file: https://github.com/Kitware/CMake/blob/master/Modules/FindBoost.cmake

And here's the documentation for it: https://cmake.org/cmake/help/v3.0/module/FindBoost.html

Ideally with this done, getting started with Angelscript would involve cloning the repository, setting it up with the desired compile settings (e.g. AS_NO_EXCEPTIONS, which should be possible using a CMake variable like CMAKE_CXX_FLAGS), installing it and then using it in your own projects by calling:

	#Find this exact version of Angelscript, error if not found
	find_package( Angelscript 2.32.0 EXACT REQUIRED )
	 
	target_link_libraries( my_executable
	optimized Angelscript::Angelscript
	debug Angelscript::Angelscriptd
	)
	

And then using an imported target to link with it automatically. This target could have angelscript.h specified by adding an interface_include_directories property, making it even easier. I'm assuming that a debug version would be provided as a separate target here.

Having each release push a tag would make it easy to get the version you want, and you can switch to WIP by pulling the latest commit. Once set up it should be as simple as recompiling and executing the install target to bring your projects up to date.

With such a repository set up on Github, it may be possible to have additional hooks triggered there to do other things, but i assume this requires write access to the repository to set up. It could allow for automatic builds to test for breaking changes or compiler/platform specific issues as well.

I was suggesting a way to synchronize a Git mirror with the SVN repository, so that any commits made in the SVN repository are mirrored in Git as well, including tags. I don't know how to set this up myself as i have limited experience with SVN, but if it's possible it would make things a bit easier.

I updated the CMake project file, you can find the files here: https://github.com/SamVanheer/Angelscript/tree/cmake-update/sdk/angelscript/projects/cmake

What i've done is update the syntax to use the modern target_* commands, which are more explicit about how they work (the old commands can affect previously defined targets), let you specify how these properties are inherited and will avoid any issues if there are ever other libraries added to the Angelscript project.

I've set the minimum CMake version required to 3.5, which is the last version to still support Visual Studio 1998 and 2002. I couldn't find any information on the minimum version that Angelscript supports, so i assumed the earliest version supported by modern versions of CMake.

I've added installation rules to place the compiled binaries and the header file angelscript.h at the user defined installation path. The result is that 3 directories (2 if not building shared libraries) will be created: include, bin and lib.

Additionally, several files are automatically placed in lib/cmake/Angelscript. These files are used by CMake's find_package command to locate the library and produce an imported target to link with.

A user need only define Angelscript_DIR to point to the directory containing these files, and use the following CMake commands:

	find_package( Angelscript CONFIG REQUIRED )
	target_link_libraries( MyProject Angelscript::angelscript )
	

This will locate the library and link with it. CMake takes care of the threading dependency on its own, so the Threads package is located and added automatically. You do not need to specify the include directory containing angelscript.h yourself, as this is also taken care of automatically.

CMake also handles versioning automatically here, so it knows which version is specified by the file. For example:

	find_package( Angelscript CONFIG  2.32.1 REQUIRED )
	

Will give you this error:

	CMake Error at CMakeLists.txt:14 (find_package):
Could not find a configuration file for package "Angelscript" that exactly
matches requested version "2.32.1".

The following configuration files were considered but not accepted:

<install path>/lib/cmake/Angelscript/AngelscriptConfig.cmake, version: 2.32.0
	

This makes detecting version issues much easier since it won't even generate build files if the version has changed, so when using an automated build system you can detect compatibility issues right away (i use webhooks to get build failure notifications in Gitter).

So yeah, this really makes using Angelscript with CMake a lot easier. I'm going to upgrade my own projects with this as well since it makes using them much easier.

A friend of mine found this: https://gist.githubusercontent.com/ticean/1556967/raw/f075637ea8c15c8861986f52b8720ef2cc9d78ce/SVN_Git_Mirror.md

Seems that the work has to be done on the Git side. A script could run once a day to sync it, but it would probably have to run on a server to make this all work.

Regarding CMake versions, 3.5 is about 2 years old so most users should have no issues using it. Requiring the latest version isn't really a good idea since most users won't have it installed so soon. On Linux CMake tends to be a few versions behind in package repositories so unless new features are required it should be fine as-is.

Thanks, i'm starting work on upgrades now for AngelscriptUtils. I do have to correct one of my earlier statements regarding library dependencies though:

CMake only keeps track of what the dependencies are, but you still have to find them yourself. In this case, you need to do this yourself:

	find_package( Threads REQUIRED )
	

Otherwise it complains about a missing target. This does not appear to apply to targets that are defined in the current context, so for example in my AngelscriptUtils repository, the test program will implicitly link Angelscript::angelscript and Threads::Threads when it links with AngelscriptUtils.

I discovered that i used the wrong variable for config file generation. It seems that it causes no issues because the version is defined above as PROJECT_VERSION, but i've fixed it anyway to be sure.

I've also added a CMake option to disable exceptions, since there is apparently no way to set preprocessor definitions from the command line.

Both changes can be found in today's commits here: https://github.com/SamVanheer/Angelscript/commits/cmake-update