re-implementing a MS Visual Studio/C# (express?) based build system.

[HinTak]

Microsoft stripped away the build system before releasing the code bundle. Seeing as most of the users are windows users, it is probably a good idea to re-implement a build system with microsoft visual studio/visual c# express.

Mono's mcs compiler is mostly compatible with microsoft's csc C# compiler, option-wise, from past experience. There are subtle differences like "-define" (open-/unix- style) vs "/define" (MS style), "/" vs "" for file and directory paths, and for "/reference:", mcs takes names without the dll suffix, csc wants the dll suffix. But on the whole, all the options have their equivalences, adapting to some difference between open- and MS style practices.

I have done this before in the past - mostly when I wrote valid c# code and and mcs did not like it, and went and did it with csc, then filed bug report with the mono folks ("hey, it works with csc and not with mcs!"). Mot of these got fixed eventually - and such issues got rarer and rarer over time.

Monodevelop's xbuild can process visual studio *.csproj and *.sln files (project and solution files) so that should be straight-forward and the easy part. Converting the command line options is the hard part, outlined above.

Again this is just lack of time/priority.

[HinTak]

Here is some notes, possibly for Microsoft folks, if they want to make the older csproj files work on the updated code.

• in general, removed parts (Win32APIs, WinVerifyTrustAPI, truetype.NET, fscaler) are replaced by the Compat module.
• the new code no longer needs the COM/ActiveX mshtml primary interop reference assembly and friends.

So just by removing most reference to mshtml and changing references to all the removed bits to 'Compat' should work; of course a new csproj file for the Compat module needs to be added.

After the DSIG work, there is a slight complication - there is circular dependency where the DSIG part of Compat uses OTFontFile . So the Compat module is built twice, once without the DSIG stuff then later with. One way of solving this is to build the Compat.2nd part with OTFontFile or OTFontFileVal if one is to make the whole thing buildable with visual studio.

In a way the circular dependency is artificial - it comes from trying to separate replacement things I wrote and things from Microsoft; so one part I wrote also depends on Microsoft stuff, instead of most Microsoft stuff depending on my replacements. If one freely build my replacement stuff together with Microsoft stuff into single assembly, any circular dependent becomes just mutual dependencies within an assembly and therefore immaterial.

The mine/Microsoft divide is much blurred in the more recent work where whole parts are rewritten - the XML viewer code and the CFF tests, as well as the new SVG tests; so the divide does not need to be taken too seriously, at least for trying to get visual studio to build this.

[HinTak]

Building with Visual Studio has been re-instated with the two commits:

14f5191

6082793

which depends on a pre-built Compat.dll (which replaces all the not-opened parts)

There is only one issue left: a new vc# project file for the Compat module. The 4 files added in the Compat.2nd GNU make target can go into OTFontFileVal project file. After these two tasks, reference to pre-built Compat.dll can be switched over to referenceproject.

[HinTak]

@prepare @none53 : apologies I only saw your forks while I was preparing my FontVal talk last week. I should have pointed you two to this issues on my notes.

[madig]

Hm. How about tossing Makefile and VS-specific build files and use CMake for cross-platform building? Microsoft has started supporting CMake a while ago.

[HinTak]

The idea of this issue is to make it easy for windows developers to participate. So I'd like to make it as VS-natural as possible. Adding CMake is just another build-system - along the same line, you can say MS include Ubuntu WSL and therefore you can use Ubuntu WSL to build FontValidator for windows too. FWIW, you can get visual studio to run make with makefiles, etc, too! Ghostscript used to do that. Also, there are two other people already working on this. I am already half-way through but just haven't finished yet. I don't object to adding a CMake-based building system. However, that's a separate and additional issue from this. If you feel like contribute a CMake based system, I am okay with that; it is separate from this issue and does not replace it though.

[madig]

Ok, so things seem to work differently in Microsoft's world. What at this point would prevent this project from going with just "solution" files and using MSBuild on Windows and Mono's xbuild everywhere else?

[HinTak]

@prepare @none53 @madig : I just tagged FontVal-2.1.3 . It should be buildable with just msbuild from vs2008 (express) onwards. Tested the binaries (both GUI and command-line) with wine already and functionally identical to Linux/mono build.

@madig : found a few incompatibility issues on the way between msbuild/csc and xbuild/mono 4.x . Probably unimportant as mono 5.x deprecates xbuild, ships msbuild and also roslyn (ms's csc supposedly mostly). So the incompatibility will be immaterial when I upgrade my Linux box to mono 5.x

[HinTak]

Argh, I forgot to update the readme before I tagged. Never mind, as long as people know that now it is supposed to work.

[HinTak]

@prepare @none53 : apologies I never got round to look at your work - mostly I was looking for supporting the oldest vs without breaking mono-based build, so using the latest vs and/or moving source files around found in some of your work are not what I want. Now that I have completed vs2008 build-ability, I 'll go back and look at what you two did and see what can be merged, at some point.