Initial attempt at building Windows binaries via Appveyor.

[ramiro]

The appveyor.yml build configuration file is located in the misc/ subdir
along with a couple helper files so to not pollute the FreeTDS source
tree root dir.

The build script downloads, builds (but doesn't link in them yet as this
just needs changes to the FreeTDS CMake setup) both OpenSSL
(by Shinning Light Productions
https://slproweb.com/products/Win32OpenSSL.html) and iconv (Yukihiro
Nakadaira's win-iconv https://github.com/win-iconv/win-iconv). Thanks
goes to them for their generous work.

[ramiro]

This is IMHO ready to be useful already, even when not completely finished. I plan to keep opening PRs to tune it further.

It depends on PR #13 or a similar implementation to be able to run the FreeTDS test suite on Windows.

If desired, the commit can be brought via cherry-pick to the Branch-0_95 branch to also provide Windows CI services for it.

All the pre-0.95 branches are blacklisted. This means both new branches in the official repo and contributor PR branches created from now on should trigger CI builds on Appveyor.

Note: If/when this gets merged, an account needs to be created in Appveyor by a GitHub FreeTDS organization member/owner (possibly using GitHub credentials) and then project settings on Appveyor need to be changed so it scans for the appveyor.yml file in the misc/ subdir instead of the source tree root.

This would be the only Web UI action needed. Everything else can be handled with the appveyor.yml file.

Things already included:

• Builds are performed with C compilers from Visual Studio 2008 and 2010, others can be added easily.
• x86 and x64 builds.
• Runs the test suite against MS SQL Server 2008 R2 SP2, others can be added easily.
• Creates artifacts from every sucessful build: Zipballs containing header files, libtds static lib, and both static and dynamic+import libs for libct, sybdb and tdsodbc.
• Can link in OpenSSL. This depends on PR CMakeLists.txt: Detect OpenSSL. #12 but is optional. OpenSSL is linked in dynamically (end users need to have OpenSSL installed). Rationale for this is to avoid having statically linked copies of such a security sensitive library.
• Can link in iconv. This depends on getting proper support for iconv on Windows in the CMakeLists.txt (a quick, hackish solution can be seen in https://github.com/FreeTDS/freetds/compare/master...ramiro:link-in-iconv-on-Windows?expand=1) but is optional. Iconv is linked in statically.

Things not done yet/that could be added:

• Detect latest OpenSSL version by scraping https://slproweb.com/products/Win32OpenSSL.html ? This would avoid frequent CI builds failures as the provider of these OpenSSL Windows binaries updates them immediately after a new official upstream release also removing older ones.
• Couldn't get registration of the ODBC driver to work. Work in progress can be seen in appveyor.yml
• Above item means the ODBC-related tests are failing. The resulting test suite > 0 exit code is ignored by appending a || cmd /c "exit /b 0" to keep it from aborting the build.
• Upload zipballs created as artifacts to GitHub with every (beta, RC, final) git tag? This could help in getting these more widely tested by users.

[freddy77]

Wonderful work! Thank you!
I don't know if win_conv is ok for everybody or would be better to use GNU libiconv but I'm ok with it.

[ramiro]

Problem with GNU libiconv support for building it with Visual C isn't very
good. See for example https://savannah.gnu.org/bugs/?35088 which has been
open for almost four years.

I suspect this isn't a problem with msys/mingw etc. and libiconv presence
there can be handled just like on *nix (even assumed as always present?).

Anyway, I still need to find a better, more generic technique to detect
iconv instead of the hack I'm using right now. Maybe using the macros to
test for functions (e.g. iconv_open()) and adding libs conditionally on
it?

On Wed, Jun 17, 2015 at 6:21 PM, freddy77 notifications@github.com wrote:

Wonderful work! Thank you!
I don't know if win_conv is ok for everybody or would be better to use GNU
libiconv but I'm ok with it.

—
Reply to this email directly or view it on GitHub
#14 (comment).

Ramiro Morales
@RamiroMorales