Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
HinTak opened this issue Dec 2, 2015 · 9 comments
Closed

Comments

@HinTak
Copy link
Owner

HinTak commented Dec 2, 2015

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
Copy link
Owner Author

HinTak commented Feb 14, 2016

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
Copy link
Owner Author

HinTak commented Feb 21, 2016

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
Copy link
Owner Author

HinTak commented Apr 17, 2018

@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
Copy link

madig commented Jun 11, 2018

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
Copy link
Owner Author

HinTak commented Jun 11, 2018

@madig
Copy link

madig commented Jun 26, 2018

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
Copy link
Owner Author

HinTak commented Nov 18, 2018

@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 HinTak closed this as completed Nov 18, 2018
@HinTak
Copy link
Owner Author

HinTak commented Nov 18, 2018

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
Copy link
Owner Author

HinTak commented Nov 18, 2018

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants