[Mono-dev] Compiling Mono with Visual Studio and .pdb files

Marek Safar marek.safar at gmail.com
Sat May 19 08:41:06 UTC 2012


Hi,

>  **
>
> Thanks Miguel, your description helped me figure out a couple of key
> things. I’m gradually getting on top of the mcs/class  build process and
> its translation to VS solutions/projects. There was already a lot of prior
> work done by Sebastien Pouliot (I think) a few years ago.
>

That's not correct, all projects were regenerated recently. About the
corlib-build issue, you don't need to build any of *-build.csproj projects,
they are needed only on systems with no .NET 4 API. I have done some work
on cleaning this up recently but it's not yet finished.

Marek

> ****
>
> ** **
>
> One thing I came across is that the project for “corlib-build” builds if
> targeting .Net 2.0, but fails on .NET 4.0 with a few errors such as
> follows. The only related issue I found (
> https://github.com/nikhilk/scriptsharp/issues/156) suggests that .NET4.5
> may be the issue. Any advice on handling this is welcome. I need to add
> project dependencies on a couple of outputs from the “basic” profile to
> overcome the issue and still target 4.0. However I do not like the
> departure from the cygwin build process.****
>
> ** **
>
> The type 'System.Diagnostics.TextWriterTraceListener' is defined in an
> assembly that is not referenced. You must add a reference to assembly
> 'System, Version=4.0.0.0, Culture=neutral,
> PublicKeyToken=b77a5c561934e089'.
> C:\src\mono\mono\mcs\class\corlib\System.Diagnostics\ConditionalAttribute.cs
> 35           11           corlib-build****
>
> The type 'System.Collections.Generic.ISet`1<T0>' is defined in an assembly
> that is not referenced. You must add a reference to assembly 'System,
> Version=4.0.0.0, Culture=neutral,
> PublicKeyToken=b77a5c561934e089'.
> C:\src\mono\mono\mcs\class\corlib\System.Collections.Generic\CollectionDebuggerView.cs
> 32           11                corlib-build****
>
> ** **
>
> ** **
>
> Cheers,****
>
> J-M****
>
> ** **
>
> *From:* Miguel Mudge [mailto:michael.mudge at welchallyn.com]
> *Sent:* Saturday, 12 May 2012 12:34 AM
> *To:* Perraud, Jean-Michel (CLW, Black Mountain)
> *Cc:* mono-devel-list at lists.ximian.com
> *Subject:* Re: [Mono-dev] Compiling Mono with Visual Studio and .pdb files
> ****
>
> ** **
>
> Making progress with msvc, with a lot of second guessing, but I cannot
> seem to fully get out of the circular dependencies easily. After fixing a
> few things, there seems to be a two to three stage build process (‘basic’,
> ‘build’ and, well, the huge rest). I can build the ‘basic’ stuff with
> references being the MS.NET libraries it defaults to, but the ‘build’
> phase fails both with dependencies on the basic system or the MS.NETlibraries (missing implementations or ambiguous references). Well done for
> you to sort it all out.****
>
> ** **
>
> Our build uses *none* of the MS.NET libraries - every project *only*
> depends on other projects in the same Mono solution file.  All of the
> projects reference the mscorlib project built in that solution, *never*
> Microsoft's mscorlib.dll (see Project Properties -> Build -> Advanced ->
> "Do not reference mscorlib.dll").****
>
> ** **
>
> mscorlib has these compilation symbols: INSIDE_CORLIB LIBC NET_1_1 NET_2_0
> NET_3_0 NET_3_5 NET_4_0****
>
> And it has a few links to external files: Aes.cs, Consts.cs, Locale.cs,
> MonoTODOAttribute.cs, SemaphoreFullException,
> TimeZoneInfo.AdjustmentRule.cs, TimeZoneInfo.Android.cs, TimeZoneInfo.cs,
> TimeZoneInfo.TransitionTime.cs.****
>
> We were able to determine most of those files by looking at
> corlib.dll.sources - definitely look at the .sources files for the other
> DLLs too... although it's better to look at the Linux build in-action.****
>
> ** **
>
> You should be able to build mscorlib with the above info.  Here is the
> info for system (notice the dash, as in "minus"):****
>
> ** **
>
> System -XML -Config: LIBC NET_1_1 NET_2_0 NET_3_0 NET_3_5 NET_4_0
> CONFIGURATION_2_0****
>
> Depends on: mscorlib project****
>
> ** **
>
> System.Xml then depends on the above.****
>
> ** **
>
> System -Config: LIBC NET_1_1 NET_2_0 NET_3_0 NET_3_5 NET_4_0
> CONFIGURATION_2_0 XML_DEP****
>
> Depends on: mscorlib project, System.Xml project****
>
> ** **
>
> Mono.Security then depends on mscorlib and System -Config****
>
> Mono.Configuration then depends on mscorlib, System.Xml and System -Config
> ****
>
> ** **
>
> System: LIBC NET_1_1 NET_2_0 NET_3_0 NET_3_5 NET_4_0  CONFIGURATION_2_0
> CONFIGURATION_DEP XML_DEP SECURITY_DEP****
>
> Depends on: mscorlib, System.Xml, System.Configuration, Mono.Security****
>
> ** **
>
> Don't trust the above though - I think there's a missing step, there may
> need to be 4 builds of System (one before XML_DEP is added, one before
> SECURITY_DEP is added, one before CONFIGURATION_DEP is added, then the
> final build with all 3 constants added).****
>
> ** **
>
> The best thing to do is compile mcs in Linux and gather this information:*
> ***
>
> - The order in which each library is built - including if it is built
> multiple times.****
>
> - What dependencies each build has.****
>
> - What compile-time constants are set.****
>
> - What files are a part of the build.****
>
> ** **
>
> I would definitely add you to my list of super-cool people if you
> duplicated / modified the Linux build process to capture the above 4 things
> to generate a working MSVC solution - it's just XML files, an xslt might do
> this well.  I'm sure the Mono folks would be happy to include the output of
> such a process in each source release to make it easier on us MSVC-centric
> folks.****
>
> ** **
>
> - Kipp****
>
> ** **
>
> It sounds like your approach is similar to that in the ‘msvc’ folder and
> related makefile targets, but I probably miss many details. I found that I
> could run the make targets generating csproj files only after a successful
> ‘make’ on cygwin, using anciliary files (.response) from the call to
> ‘make’. I wonder how similar to what you describe this is. My question may
> be naive, but what do you mean by compiler constants, build order and files
> used? Are you post-processing the captured output redirected to a file?***
> *
>
>  ****
>
> I never really had to do much with makefiles, and with a codebase the size
> of Mono, this is a steep learning curve.****
>
>  ****
>
> Cheers,****
>
> J-M****
>
>  ****
>
>  ****
>
>  ****
>
> *From:* Miguel Mudge [mailto:michael.mudge at welchallyn.com]
> *Sent:* Tuesday, 8 May 2012 12:30 AM
> *To:* Perraud, Jean-Michel (CLW, Black Mountain)
> *Cc:* mono-devel-list at lists.ximian.com
> *Subject:* Re: [Mono-dev] Compiling Mono with Visual Studio and .pdb files
> ****
>
>  ****
>
> We've been building the 2.10.2 Mono framework libraries in Visual Studio.
>  We performed a build on Linux, copied the compiler constants, build order
> and files used, and use this information to create the Visual Studio
> project - we did not start from Mono's msvc.  It was a very manual process,
> but I am pleased with the output.****
>
>  ****
>
> We don't compile all of the libraries since our embedded device doesn't
> have the space.  Most of the difficulty is in the roots anyways - for
> example, we have several System.dll projects, which are incrementally more
> dependent, in order to solve circular dependency problems.  Picture
> attached:****
>
>  ****
>
> It seems like the only way to reliably "copy" the build process into MSVC
> is to actually run the mcs make.  You might be able to hack it a bit to
> mock a build, grab the compile flags/files and then generate msvc files
> from that.****
>
>  ****
>
> Thanks,****
>
> Michael "Kipp" Mudge | Welch Allyn | Lead Software Engineer****
>
> 315-554-4057 | michael.mudge at welchallyn.com****
>
>  ****
>
>  ****
>
> ** **
>
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ximian.com/pipermail/mono-devel-list/attachments/20120519/ed3c27a1/attachment.html>


More information about the Mono-devel-list mailing list