[Mono-dev] Building mono on windows

[Michael Stoll]

I'm trying to build Mono on Windows 7.

The System:
Windows 7 Professional x64
Mono 3.0.1
Cygwin 1.7

What I did:
Checkout git repository (with Tortoise GIT, no auto CRLF)
./autogen.sh --prefix /usr/local &> autogen.log (see attachment)
make &> make.log (see attachment)

But make fails:
MCS [net_2_0] mscorlib.dll
Cannot open assembly './../../class/lib/build/mcs.exe': Permission denied.
../../build/library.make:243: recipe for target 
`../../class/lib/net_2_0/tmp/mscorlib.dll' failed

make[8]: *** [../../class/lib/net_2_0/tmp/mscorlib.dll] Error 2

There's also a strange warning in autogen.log:297 (configure: WARNING: 
winternl.h: present but cannot be compiled)


Any clue?

Regards
Michael
Making all in runtime
make[2]: Entering directory `/cygdrive/d/lnk/mono/mono/runtime'
d=`cd ../support && pwd`; \
sed 's,target="libMonoPosixHelper[^"]*",target="'$d/libMonoPosixHelper.la'",' 
../data/config > etc/mono/configt
if test -z ""; then :; else \
  sed 's,,& ,' 
etc/mono/configt > etc/mono/configtt; \
  mv -f etc/mono/configtt etc/mono/configt; fi
mv -f etc/mono/configt etc/mono/config
/bin/sh ../mkinstalldirs _tmpinst/bin
mkdir -p -- _tmpinst/bin
cp mono-wrapper _tmpinst/bin/mono
echo '#! /bin/sh' > _tmpinst/bin/ilasm ; \
r=`pwd`; m=`cd D:/lnk/mono/mono/mcs && pwd`; \
echo 'exec "'"$r/_tmpinst/bin/mono"'" "'"$m/ilasm/ilasm.exe"'" "$@"' >> 
_tmpinst/bin/ilasm ; \
chmod +x _tmpinst/bin/ilasm
echo '#! /bin/sh' > _tmpinst/bin/mcs ; \
r=`pwd`; m=`cd D:/lnk/mono/mono/mcs && pwd`; \
echo 'exec "'"$r/_tmpinst/bin/mono"'" "'"$m/class/lib/build/mcs.exe"'" "$@"' >> 
_tmpinst/bin/mcs ; \
chmod +x _tmpinst/bin/mcs
echo '#! /bin/sh' > _tmpinst/bin/gmcs ; \
r=`pwd`; m=`cd D:/lnk/mono/mono/mcs && pwd`; \
echo 'exec "'"$r/_tmpinst/bin/mono"'" "'"$m/class/lib/build/mcs.exe -sdk:2"'" 
"$@"' >> _tmpinst/bin/gmcs ; \
chmod +x _tmpinst/bin/gmcs
echo '#! /bin/sh' > _tmpinst/bin/dmcs ; \
r=`pwd`; m=`cd D:/lnk/mono/mono/mcs && pwd`; \
echo 'exec "'"$r/_tmpinst/bin/mono"'" "'"$m/class/lib/build/mcs.exe -sdk:4"'" 
"$@"' >> _tmpinst/bin/dmcs ; \
chmod +x _tmpinst/bin/dmcs
echo '#! /bin/sh' > _tmpinst/bin/al2 ; \
r=`pwd`; m=`cd D:/lnk/mono/mono/mcs && pwd`; \
echo 'exec "'"$r/_tmpinst/bin/mono"'" "'"$m/class/lib/net_2_0/al.exe"'" "$@"' 
>> _tmpinst/bin/al2 ; \
chmod +x _tmpinst/bin/al2
echo '#! /bin/sh' > _tmpinst/bin/al ; \
r=`pwd`; m=`cd D:/lnk/mono/mono/mcs && pwd`; \
echo 'exec "'"$r/_tmpinst/bin/mono"'" "'"$m/class/lib/net_4_5/al.exe"'" "$@"' 
>> _tmpinst/bin/al ; \
chmod +x _tmpinst/bin/al
if test -w D:/lnk/mono/mono/mcs; then :; else chmod -R +w D:/lnk/mono/mono/mcs; 
fi
cd D:/lnk/mono/mono/mcs && make --no-print-directory -s NO_DIR_CHECK=1 
PROFILES='  net_2_0 net_3_5  net_4_0  net_4_5' CC='gcc-3.exe -mno-cygwin 
-g' all-profiles
mkdir -p -- build/deps
Bootstrap compiler: Mono C# compiler version 3.0.1.0
Makefile:43: warning: overriding recipe for target `csproj-local'
../build/executable.make:149: warning: ignoring old recipe for target 
`csproj-local'
Makefile:43: warning: overriding recipe for target `csproj-local'
../build/executable.make:149: warning: ignoring old recipe for target 
`csproj-local'
Makefile:43: warning: overriding recipe for target `csproj-local'
../build/executable.make:149: warning: ignoring old recipe for target 
`csproj-local'
D:\lnk\mono\mono\mcs\jay\jay.exe: 7 shift/reduce conflicts.
Converting mcs.exe.sources to ../build/deps/mcs.exe.sources.response ...
mkdir -p -- ../class/lib/basic/
MCS [basic] basic.exe
Converting corlib.dll.sources to ../../build/deps/basic_corlib.dll.response ...
mkdir -p -- ../../class/lib/basic/tmp/
MCS [basic] mscorlib.dll
** Warning: System.dll built without parts that depend on: System.Xml.dll
Converting System.dll.sources to ../../build/deps/basic_System.dll.response ...
MCS [basic] System.dll
System.Diagnostics\TraceImpl.cs(44,15): warning CS0649: Field 
`System.Diagnostics.TraceImplSettings.AutoFlush' is never assigned to, and will 
always have its default value `false'
Compilation succeeded - 1 warning(s)
Converting System.Xml.dll.sources to 
../../build/deps/basic_System.Xml.dll.response ...
D:\lnk\mono\mono\mcs\jay\jay.exe: 21 rules never reduced
D:\lnk\mono\mono\mcs\jay\jay.exe: 1 shift/reduce conflict, 42 reduce/reduce 
conflicts.
D:\lnk\mono\mono\mcs\jay\jay.exe: 3 rules never reduced
D:\lnk\mono\mono\mcs\jay\jay.exe: 1 shift/reduce conflict, 46 reduce/reduce 
conflicts.
MCS [basic] System.Xml.dll
MCS [basic] System.dll
Converting Mono.Security.dll.sources to 
../../build/deps/basic_Mono.Security.dll.response ...
MCS [basic] Mono.Security.dll
.\Mono.Security.Protocol.Ntlm\Type3Message.cs(278,29): warning CS0618: 
`Mono.Security.Protocol.Ntlm.ChallengeResponse' is obsolete: `Use of this API 
is highly discouraged, it selects legacy-mode LM/NTLM authentication, which 
sends your password in very weak encryption over the wire even if the server 
supports the more secure NTLMv2 / NTLMv2 Session. You need to use the new 
`Type3Message (Ty

[Mono-dev] Building mono on windows

[Michael Stoll]

Hi,

I used to build mono on Cygwin/Windows a couple of month ago. Therefore 
I had to convert a few files using dos2unix command.


Today I did a clean checkout and applied dos2unix as before. But when 
runing make it complained about

./depcomp: line2: $'\r': command not found
As depcomp hat unix format, I have no idea, what to do.

Regards Michael

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

[Mono-dev] Building Mono on Windows

[Jonathan Chambers]

I am attempting to build mono on Windows using cygwin. I have been building
the runtime using Visual Studio, and using class libraries built on
Linux/OSX. This prevents me from easily running the runtime/classlib tests
though. So, I clone the mono repository, and attempt to configure. I
immediately get a ton of errors all related to line endings in the scripts.
Looking at the .gitattributes file it appears we work native line endings
on *.sh files.

https://github.com/mono/mono/blob/master/.gitattributes

I locally converted all *.sh files to LF, and that gets me a bit further
but things still fail. Is anyone else building on cygwin? Assuming I make
progress enough to run a build, is there any reason for scripts to be
checked out with CRLF endings?

I am trying to get things building on windows and re-documenting the
minimum steps needed to get a build. I had made a good bit of progress
using msys/MinGW instead of cygwin, but hit an issue where it can't handle
'/' specified flags on the command line. They need escaped to '//'. I
decided to go back to cygwin before proceeding any further with MinGW.

Thanks,
Jonathan
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Building mono on windows

[Bartosz Przygoda]

Hi,

I've recently been following this:
http://shana.worldofcoding.com/en/mono_cygwin_tutorial.html and got similar
issue when I tried with latest make.

Instead, they suggest to fetch it from:
http://www.go-mono.com/archive/helper/make-3.80-1.tar.bz2 which helped (as
far I recall).


On 3 December 2012 12:52, Michael Stoll  wrote:

> I'm trying to build Mono on Windows 7.
>
> The System:
> Windows 7 Professional x64
> Mono 3.0.1
> Cygwin 1.7
>
> What I did:
> Checkout git repository (with Tortoise GIT, no auto CRLF)
> ./autogen.sh --prefix /usr/local &> autogen.log (see attachment)
> make &> make.log (see attachment)
>
> But make fails:
> MCS [net_2_0] mscorlib.dll
> Cannot open assembly './../../class/lib/build/mcs.**exe': Permission
> denied.
> ../../build/library.make:243: recipe for target
> `../../class/lib/net_2_0/tmp/**mscorlib.dll' failed
> make[8]: *** [../../class/lib/net_2_0/tmp/**mscorlib.dll] Error 2
>
> There's also a strange warning in autogen.log:297 (configure: WARNING:
> winternl.h: present but cannot be compiled)
>
> Any clue?
>
> Regards
> Michael
>
> ___
> Mono-devel-list mailing list
> Mono-devel-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
>
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Building mono on windows

[Michael Stoll]

Replaced the make.exe, did a "make clean" and "make", but got the same 
error.


Nevertheless thanks for the advice.

Am 03.12.2012 13:01, schrieb Bartosz Przygoda:

Hi,

I've recently been following this: 
http://shana.worldofcoding.com/en/mono_cygwin_tutorial.html and got 
similar issue when I tried with latest make.


Instead, they suggest to fetch it from: 
http://www.go-mono.com/archive/helper/make-3.80-1.tar.bz2 which helped 
(as far I recall).



On 3 December 2012 12:52, Michael Stoll > wrote:


I'm trying to build Mono on Windows 7.

The System:
Windows 7 Professional x64
Mono 3.0.1
Cygwin 1.7

What I did:
Checkout git repository (with Tortoise GIT, no auto CRLF)
./autogen.sh --prefix /usr/local &> autogen.log (see attachment)
make &> make.log (see attachment)

But make fails:
MCS [net_2_0] mscorlib.dll
Cannot open assembly './../../class/lib/build/mcs.exe': Permission
denied.
../../build/library.make:243: recipe for target
`../../class/lib/net_2_0/tmp/mscorlib.dll' failed
make[8]: *** [../../class/lib/net_2_0/tmp/mscorlib.dll] Error 2

There's also a strange warning in autogen.log:297 (configure:
WARNING: winternl.h: present but cannot be compiled)

Any clue?

Regards
Michael

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com

http://lists.ximian.com/mailman/listinfo/mono-devel-list




___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Building mono on windows

[Robert Jordan]

Hi,

On 03.12.2012 12:52, Michael Stoll wrote:

I'm trying to build Mono on Windows 7.

The System:
Windows 7 Professional x64
Mono 3.0.1
Cygwin 1.7

What I did:
Checkout git repository (with Tortoise GIT, no auto CRLF)
./autogen.sh --prefix /usr/local &> autogen.log (see attachment)
make &> make.log (see attachment)

But make fails:
MCS [net_2_0] mscorlib.dll
Cannot open assembly './../../class/lib/build/mcs.exe': Permission denied.


Rerun `make' until it works. It might also help to call `make'
once from the directory where it started to fail (here: mcs/classes/corlib):

make PROFILE=net_2_0

When it comes to cygwin, doing stuff until it eventually starts
working is a perfectly valid modus operandi. Don't worry ;)

Robert


___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Building mono on windows

[Michael Stoll]

Hi Robert,

each make call got me the same message, so that didn't help.
But I found a solution. By replacing the mcs.exe with one from the 
binary release I got a better error message. So I found out that the 
machine.config was not accessible due to access restrictions. Fixed that 
and the build went well.


Regards Michale

Am 03.12.2012 16:15, schrieb Robert Jordan:

Hi,

On 03.12.2012 12:52, Michael Stoll wrote:

I'm trying to build Mono on Windows 7.

The System:
Windows 7 Professional x64
Mono 3.0.1
Cygwin 1.7

What I did:
Checkout git repository (with Tortoise GIT, no auto CRLF)
./autogen.sh --prefix /usr/local &> autogen.log (see attachment)
make &> make.log (see attachment)

But make fails:
MCS [net_2_0] mscorlib.dll
Cannot open assembly './../../class/lib/build/mcs.exe': Permission 
denied.


Rerun `make' until it works. It might also help to call `make'
once from the directory where it started to fail (here: 
mcs/classes/corlib):


make PROFILE=net_2_0

When it comes to cygwin, doing stuff until it eventually starts
working is a perfectly valid modus operandi. Don't worry ;)

Robert


___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list



___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

[Mono-dev] Building mono on Windows issues.

[Chris Eelmaa]

Hello all,

I have question regarding building mono on windows,
namely I've tried a lot of times, and had a lot of different
problems(such as missing some dependencies, git converting *.sh files
to CRLF ending and cygwin not being able to interpret them, etc..)

however I've reached now to a point where I can run `make` for a little while,
and then receive the error:

In file included from socket-io.c:30:0:
/usr/i686-pc-mingw32/sys-root/mingw/include/ws2tcpip.h:38:2: error:
#error "ws2tcpip.h is not compatible with winsock.h. Include
winsock2.h instead."
In file included from socket-io.c:30:0:
/usr/i686-pc-mingw32/sys-root/mingw/include/ws2tcpip.h:147:8: error:
redefinition of 'struct ip_mreq'
In file included from
/usr/i686-pc-mingw32/sys-root/mingw/include/windows.h:93:0,


As you can see, winsock.h doesn't play well with ws2tcpip.h. I ran a
grep to look for winsock.h from mono dir, but there's nothing about
that. That file seems to be crawling in from some arbitrary place?!


After that, I tried to compile with DISABLE_SOCKETS, and then I
arrived to this place:

./.libs/libmini.a(libmini_la-debugger-agent.o): In function
`socket_transport_connect':
/cygdrive/c/GITHUB/mono/mono/mini/debugger-agent.c:1236: undefined
reference to `mono_network_init'



At this point, I have no idea what to do. Is mono master branch
broken, or is it possible to actually build it with Windows from
there? Can anyone confirm? Do I have messed up Windows SDK or
something similiar?

Thanks.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Building mono on windows

[Alex]

Hi,

git config --global core.autocrlf true

should fix any EOL problems with building on Windows. (Make sure to do
a clean clone after that.)

Regards,
Alex

On Wed, Feb 1, 2012 at 5:26 PM, Michael Stoll  wrote:
> Hi,
>
> I used to build mono on Cygwin/Windows a couple of month ago. Therefore I
> had to convert a few files using dos2unix command.
>
> Today I did a clean checkout and applied dos2unix as before. But when runing
> make it complained about
> ./depcomp: line2: $'\r': command not found
> As depcomp hat unix format, I have no idea, what to do.
>
> Regards Michael
>
> ___
> Mono-devel-list mailing list
> Mono-devel-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Building mono on windows

[Michael Stoll]

Hi,

I'm using TortoiseGit. So I set the AutoCrlf flag in the settings, did a 
clean clone, but configure failed because of additional \r.
AFAIK The script files should be in unix format in order to run using 
cygwin tools. But AutoCrlf would convert to windows format. Correct?


Regards Michael


Am 01.02.2012 18:24, schrieb Alex:

Hi,

git config --global core.autocrlf true

should fix any EOL problems with building on Windows. (Make sure to do
a clean clone after that.)

Regards,
Alex

On Wed, Feb 1, 2012 at 5:26 PM, Michael Stoll  wrote:

Hi,

I used to build mono on Cygwin/Windows a couple of month ago. Therefore I
had to convert a few files using dos2unix command.

Today I did a clean checkout and applied dos2unix as before. But when runing
make it complained about
./depcomp: line2: $'\r': command not found
As depcomp hat unix format, I have no idea, what to do.

Regards Michael

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list


___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Building Mono on Windows

[Robert Jordan]

Hi Jonathan,

On 03.03.2012 16:23, Jonathan Chambers wrote:

I am attempting to build mono on Windows using cygwin. I have been building
the runtime using Visual Studio, and using class libraries built on
Linux/OSX. This prevents me from easily running the runtime/classlib tests
though. So, I clone the mono repository, and attempt to configure. I
immediately get a ton of errors all related to line endings in the scripts.
Looking at the .gitattributes file it appears we work native line endings
on *.sh files.

https://github.com/mono/mono/blob/master/.gitattributes


I don't see these CRLF issues when I clone using cygwin's git.

What's the output of

git config --global core.autocrlf

on your system?

Robert

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Building Mono on Windows

[Jonathan Chambers]

Hello Robert,

$ git config --global core.autocrlf
true

I believe I enabled that following directions for Windows here:

http://help.github.com/line-endings/

Should that be set to 'input'?

Thanks,
Jonathan

On Sat, Mar 3, 2012 at 10:40 AM, Robert Jordan  wrote:

> Hi Jonathan,
>
>
> On 03.03.2012 16:23, Jonathan Chambers wrote:
>
>> I am attempting to build mono on Windows using cygwin. I have been
>> building
>> the runtime using Visual Studio, and using class libraries built on
>> Linux/OSX. This prevents me from easily running the runtime/classlib tests
>> though. So, I clone the mono repository, and attempt to configure. I
>> immediately get a ton of errors all related to line endings in the
>> scripts.
>> Looking at the .gitattributes file it appears we work native line endings
>> on *.sh files.
>>
>> https://github.com/mono/mono/**blob/master/.gitattributes
>>
>
> I don't see these CRLF issues when I clone using cygwin's git.
>
> What's the output of
>
>git config --global core.autocrlf
>
> on your system?
>
> Robert
>
> __**_
> Mono-devel-list mailing list
> Mono-devel-list@lists.ximian.**com 
> http://lists.ximian.com/**mailman/listinfo/mono-devel-**list
>
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Building Mono on Windows

[Robert Jordan]

Hi Jonathan,

On 03.03.2012 18:01, Jonathan Chambers wrote:

Hello Robert,

$ git config --global core.autocrlf
true

I believe I enabled that following directions for Windows here:

http://help.github.com/line-endings/

Should that be set to 'input'?


Yes. It's 'input' on my system, and it seems to work (git version
1.7.5.1, cygwin).

Robert

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Building Mono on Windows

[Atsushi Eno]

Some monotouch guys broke jay-related builds on Windows and they are 
kept as they are.


Atsushi Eno

On 2012/03/04 0:23, Jonathan Chambers wrote:
I am attempting to build mono on Windows using cygwin. I have been 
building the runtime using Visual Studio, and using class libraries 
built on Linux/OSX. This prevents me from easily running the 
runtime/classlib tests though. So, I clone the mono repository, and 
attempt to configure. I immediately get a ton of errors all related to 
line endings in the scripts. Looking at the .gitattributes file it 
appears we work native line endings on *.sh files.


https://github.com/mono/mono/blob/master/.gitattributes

I locally converted all *.sh files to LF, and that gets me a bit 
further but things still fail. Is anyone else building on cygwin? 
Assuming I make progress enough to run a build, is there any reason 
for scripts to be checked out with CRLF endings?


I am trying to get things building on windows and re-documenting the 
minimum steps needed to get a build. I had made a good bit of progress 
using msys/MinGW instead of cygwin, but hit an issue where it can't 
handle '/' specified flags on the command line. They need escaped to 
'//'. I decided to go back to cygwin before proceeding any further 
with MinGW.


Thanks,
Jonathan


___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list


___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Building Mono on Windows

[Robert Jordan]

On 04.03.2012 15:50, Atsushi Eno wrote:

Some monotouch guys broke jay-related builds on Windows and they are
kept as they are.


This is already fixed.

Robert


___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Building mono on Windows issues.

[Edward Ned Harvey (mono)]

> From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list-
> boun...@lists.ximian.com] On Behalf Of Chris Eelmaa
> 
> I have question regarding building mono on windows,
> namely I've tried a lot of times, and had a lot of different

Many venture into the waters of mono build on windows.  Few live to tell the 
tale;-)

The honest truth is, many of us have sunk hours or days into trying to get it 
to work.  Many of us (including me) strike out and eventually give up.  
Occasionally, people come to this mailing list and post a procedure that worked 
for them.  I've never seen the same procedure twice, I always try, and it's 
never worked for me.

Your best bet is to search this mailing list archive for the most recent posts 
of people succeeding, and see if that's able to help you along.

Your *other* best bet, is to ask yourself "Why, God, Why?"  As I have done, and 
others like me who were also lost in the battle.  Generally speaking, the only 
reasons to build on windows are because you want to debug the code, which is 
generally better done on mac/linux.  Or you're trying to accomplish something 
else, like obtain a specific DLL (such as Mono.Data.Sqlite)...  Which usually 
you can obtain some other way such as building on linux and then copying the 
DLL over to windows.

So if you don't succeed at building on windows, then ask yourself (and this 
list) if there's another way to accomplish whatever you're actually trying to 
accomplish.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Building mono on Windows issues.

[Alex J Lennon]

On 16/10/2014 00:17, Chris Eelmaa wrote:
> Hello all,
>
> I have question regarding building mono on windows,
> namely I've tried a lot of times, and had a lot of different
> problems(such as missing some dependencies, git converting *.sh files
> to CRLF ending and cygwin not being able to interpret them, etc..)
>
> however I've reached now to a point where I can run `make` for a little while,
> and then receive the error:
>
> In file included from socket-io.c:30:0:
> /usr/i686-pc-mingw32/sys-root/mingw/include/ws2tcpip.h:38:2: error:
> #error "ws2tcpip.h is not compatible with winsock.h. Include
> winsock2.h instead."
> In file included from socket-io.c:30:0:
> /usr/i686-pc-mingw32/sys-root/mingw/include/ws2tcpip.h:147:8: error:
> redefinition of 'struct ip_mreq'
> In file included from
> /usr/i686-pc-mingw32/sys-root/mingw/include/windows.h:93:0,
>
>
> As you can see, winsock.h doesn't play well with ws2tcpip.h. I ran a
> grep to look for winsock.h from mono dir, but there's nothing about
> that. That file seems to be crawling in from some arbitrary place?!
>
>
> After that, I tried to compile with DISABLE_SOCKETS, and then I
> arrived to this place:
>
> ./.libs/libmini.a(libmini_la-debugger-agent.o): In function
> `socket_transport_connect':
> /cygdrive/c/GITHUB/mono/mono/mini/debugger-agent.c:1236: undefined
> reference to `mono_network_init'
>
>
>
> At this point, I have no idea what to do. Is mono master branch
> broken, or is it possible to actually build it with Windows from
> there? Can anyone confirm? Do I have messed up Windows SDK or
> something similiar?
>

Hi Chris,

I put this together precisely because it's such a problem -

http://www.codeproject.com/Articles/815565/How-to-build-Mono-on-Windows

I've tested various iterations and had feedback that others have found
it doesn't work.

Periodically git master doesn't build but I don't have the time to track
that. I will be updating
next time I discover there's a new release.

Cheers,

Alex

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Building mono on Windows issues.

[Alex J Lennon]

On 16/10/2014 04:56, Edward Ned Harvey (mono) wrote:
>> From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list-
>> boun...@lists.ximian.com] On Behalf Of Chris Eelmaa
>>
>> I have question regarding building mono on windows,
>> namely I've tried a lot of times, and had a lot of different
> Many venture into the waters of mono build on windows.  Few live to tell the 
> tale;-)
>
> The honest truth is, many of us have sunk hours or days into trying to get it 
> to work.  Many of us (including me) strike out and eventually give up.  
> Occasionally, people come to this mailing list and post a procedure that 
> worked for them.  I've never seen the same procedure twice, I always try, and 
> it's never worked for me.
>
> Your best bet is to search this mailing list archive for the most recent 
> posts of people succeeding, and see if that's able to help you along.
>
> Your *other* best bet, is to ask yourself "Why, God, Why?"  As I have done, 
> and others like me who were also lost in the battle.  Generally speaking, the 
> only reasons to build on windows are because you want to debug the code, 
> which is generally better done on mac/linux.  Or you're trying to accomplish 
> something else, like obtain a specific DLL (such as Mono.Data.Sqlite)...  
> Which usually you can obtain some other way such as building on linux and 
> then copying the DLL over to windows.
>
> So if you don't succeed at building on windows, then ask yourself (and this 
> list) if there's another way to accomplish whatever you're actually trying to 
> accomplish.
> ___
> Mono-devel-list mailing list
> Mono-devel-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
>

Ed,

Agreed, but the the other reason is that you want to use a current Mono
yet nobody has gotten around to an official release of Mono for WIndows
since 3.2.3.

Cheers,

Alex

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Building mono on Windows issues.

[Alex J Lennon]

On 16/10/2014 08:45, Alex J Lennon wrote:
> On 16/10/2014 00:17, Chris Eelmaa wrote:
>> Hello all,
>>
>> I have question regarding building mono on windows,
>> namely I've tried a lot of times, and had a lot of different
>> problems(such as missing some dependencies, git converting *.sh files
>> to CRLF ending and cygwin not being able to interpret them, etc..)
>>
>> however I've reached now to a point where I can run `make` for a little 
>> while,
>> and then receive the error:
>>
>> In file included from socket-io.c:30:0:
>> /usr/i686-pc-mingw32/sys-root/mingw/include/ws2tcpip.h:38:2: error:
>> #error "ws2tcpip.h is not compatible with winsock.h. Include
>> winsock2.h instead."
>> In file included from socket-io.c:30:0:
>> /usr/i686-pc-mingw32/sys-root/mingw/include/ws2tcpip.h:147:8: error:
>> redefinition of 'struct ip_mreq'
>> In file included from
>> /usr/i686-pc-mingw32/sys-root/mingw/include/windows.h:93:0,
>>
>>
>> As you can see, winsock.h doesn't play well with ws2tcpip.h. I ran a
>> grep to look for winsock.h from mono dir, but there's nothing about
>> that. That file seems to be crawling in from some arbitrary place?!
>>
>>
>> After that, I tried to compile with DISABLE_SOCKETS, and then I
>> arrived to this place:
>>
>> ./.libs/libmini.a(libmini_la-debugger-agent.o): In function
>> `socket_transport_connect':
>> /cygdrive/c/GITHUB/mono/mono/mini/debugger-agent.c:1236: undefined
>> reference to `mono_network_init'
>>
>>
>>
>> At this point, I have no idea what to do. Is mono master branch
>> broken, or is it possible to actually build it with Windows from
>> there? Can anyone confirm? Do I have messed up Windows SDK or
>> something similiar?
>>
> Hi Chris,
>
> I put this together precisely because it's such a problem -
>
> http://www.codeproject.com/Articles/815565/How-to-build-Mono-on-Windows
>
> I've tested various iterations and had feedback that others have found
> it doesn't work.
>
> Periodically git master doesn't build but I don't have the time to track
> that. I will be updating
> next time I discover there's a new release.
>
> Cheers,
>
> Alex
>
> ___

*does work

That'll teach me to email before coffee...

Regards,

Alex

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Building mono on Windows issues.

[Edward Ned Harvey (mono)]

> From: Alex J Lennon [mailto:ajlen...@dynamicdevices.co.uk]
> 
>> Generally
>> speaking, the only reasons to build on windows are because you want to
>> debug the code, which is generally better done on mac/linux.  Or you're
>> trying to accomplish something else, like obtain a specific DLL (such as
>> Mono.Data.Sqlite)...  Which usually you can obtain some other way such as
>> building on linux and then copying the DLL over to windows.
> 
> Agreed, but the the other reason is that you want to use a current Mono
> yet nobody has gotten around to an official release of Mono for WIndows
> since 3.2.3.

Agreed, but that's the point - Why would you want to use Mono on windows?  The 
only reasons I know of are (a) you wish to debug the mono sources using Visual 
Studio, or (b) you wish to use one of Mono's assemblies in windows, such as 
Mono.Security, Mono.Data.Sqlite, etc.

For case (a), at least for me, it's been easier to transition to Xamarin Studio 
or Monodevelop on mac/linux.

For case (b) I was able to brainlessly copy Mono.Security.dll, and I struggled 
a little bit to copy Mono.Data.Sqlite.dll, but after a few tries, managed to 
get it right more easily than getting it to build natively on windows.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Building mono on Windows issues.

[Bryan Crotaz]

Q: Why do I want to debug on Windows?
A: Resharper

On 16 October 2014 11:38, Edward Ned Harvey (mono) <
edward.harvey.m...@clevertrove.com> wrote:

> > From: Alex J Lennon [mailto:ajlen...@dynamicdevices.co.uk]
> >
> >> Generally
> >> speaking, the only reasons to build on windows are because you want to
> >> debug the code, which is generally better done on mac/linux.  Or you're
> >> trying to accomplish something else, like obtain a specific DLL (such as
> >> Mono.Data.Sqlite)...  Which usually you can obtain some other way such
> as
> >> building on linux and then copying the DLL over to windows.
> >
> > Agreed, but the the other reason is that you want to use a current Mono
> > yet nobody has gotten around to an official release of Mono for WIndows
> > since 3.2.3.
>
> Agreed, but that's the point - Why would you want to use Mono on windows?
> The only reasons I know of are (a) you wish to debug the mono sources using
> Visual Studio, or (b) you wish to use one of Mono's assemblies in windows,
> such as Mono.Security, Mono.Data.Sqlite, etc.
>
> For case (a), at least for me, it's been easier to transition to Xamarin
> Studio or Monodevelop on mac/linux.
>
> For case (b) I was able to brainlessly copy Mono.Security.dll, and I
> struggled a little bit to copy Mono.Data.Sqlite.dll, but after a few tries,
> managed to get it right more easily than getting it to build natively on
> windows.
> ___
> Mono-devel-list mailing list
> Mono-devel-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>



-- 
Bryan Crotaz
Managing Director
Silver Curve
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Building mono on Windows issues.

[Mladen Mihajlovic]

Could a service like https://ci.appveyor.com/ not be used to set up a
proper windows build?

On 16 October 2014 12:44, Bryan Crotaz 
wrote:

> Q: Why do I want to debug on Windows?
> A: Resharper
>
> On 16 October 2014 11:38, Edward Ned Harvey (mono) <
> edward.harvey.m...@clevertrove.com> wrote:
>
>> > From: Alex J Lennon [mailto:ajlen...@dynamicdevices.co.uk]
>> >
>> >> Generally
>> >> speaking, the only reasons to build on windows are because you want to
>> >> debug the code, which is generally better done on mac/linux.  Or you're
>> >> trying to accomplish something else, like obtain a specific DLL (such
>> as
>> >> Mono.Data.Sqlite)...  Which usually you can obtain some other way such
>> as
>> >> building on linux and then copying the DLL over to windows.
>> >
>> > Agreed, but the the other reason is that you want to use a current Mono
>> > yet nobody has gotten around to an official release of Mono for WIndows
>> > since 3.2.3.
>>
>> Agreed, but that's the point - Why would you want to use Mono on
>> windows?  The only reasons I know of are (a) you wish to debug the mono
>> sources using Visual Studio, or (b) you wish to use one of Mono's
>> assemblies in windows, such as Mono.Security, Mono.Data.Sqlite, etc.
>>
>> For case (a), at least for me, it's been easier to transition to Xamarin
>> Studio or Monodevelop on mac/linux.
>>
>> For case (b) I was able to brainlessly copy Mono.Security.dll, and I
>> struggled a little bit to copy Mono.Data.Sqlite.dll, but after a few tries,
>> managed to get it right more easily than getting it to build natively on
>> windows.
>> ___
>> Mono-devel-list mailing list
>> Mono-devel-list@lists.ximian.com
>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>>
>
>
>
> --
> Bryan Crotaz
> Managing Director
> Silver Curve
>
> ___
> Mono-devel-list mailing list
> Mono-devel-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
>
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Building mono on Windows issues.

[Alex J Lennon]

On 16/10/2014 12:38, Edward Ned Harvey (mono) wrote:
>> From: Alex J Lennon [mailto:ajlen...@dynamicdevices.co.uk]
>>
>>> Generally
>>> speaking, the only reasons to build on windows are because you want to
>>> debug the code, which is generally better done on mac/linux.  Or you're
>>> trying to accomplish something else, like obtain a specific DLL (such as
>>> Mono.Data.Sqlite)...  Which usually you can obtain some other way such as
>>> building on linux and then copying the DLL over to windows.
>> Agreed, but the the other reason is that you want to use a current Mono
>> yet nobody has gotten around to an official release of Mono for WIndows
>> since 3.2.3.
> Agreed, but that's the point - Why would you want to use Mono on windows?  
> The only reasons I know of are (a) you wish to debug the mono sources using 
> Visual Studio, or (b) you wish to use one of Mono's assemblies in windows, 
> such as Mono.Security, Mono.Data.Sqlite, etc.
>
> For case (a), at least for me, it's been easier to transition to Xamarin 
> Studio or Monodevelop on mac/linux.
>
> For case (b) I was able to brainlessly copy Mono.Security.dll, and I 
> struggled a little bit to copy Mono.Data.Sqlite.dll, but after a few tries, 
> managed to get it right more easily than getting it to build natively on 
> windows.
>
>

I guess different people will have different use-cases but this is ours
(which I don't think is so unique)

We develop software targetting Embedded Linux, Windows desktop/server
and Windows CE/Embedded Compact with .NET CF.

We use Visual Studio (plus Resharper as Bryan so rightly says - couldn't
get along without it) as we find this to be a productive development
environment.
In addition there is a lot of development resource out there with people
who know and are qualified on the VS toolchain.

Ideally we'd be write once and it'd just work whatever the platform or
framework, but the reality is we run into platform dependencies (SQLite
as you say, serial comms in the past), native dependencies and
configuration issues.

>From a productivity perspective and for risk management for testing and
deployment I wish to be able to develop and debug under Visual Studio
with Mono as a framework option.

I'd like to be able to do that with Mono on Windows as a check that no
issues come up between running on the .NET framework and running on Mono.

In addition I'd like to be able to remote debug to Embedded Linux with
Visual Studio - which  I used to be able to do with Xamarin's Monotools
Server before it disappeared.

I'm currently investigating a VS plugin to replace Monotools Server
which I've not had much luck with yet, but I'm optimistic:
https://github.com/DynamicDevices/monodebugvs

Cheers,

Alex

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Building mono on Windows issues.

[Greg Young]

This may help you a bit
https://www.google.co.uk/search?client=safari&rls=en&q=greg+young+sublime+is+sublime&ie=UTF-8&oe=UTF-8&gfe_rd=cr&ei=FsY_VN3ALO3H8gfZwoKwBg
you can do much of VS + R# in sublime/vim if you spend the time to set
it up.

Cheers,

Greg

On Thu, Oct 16, 2014 at 1:45 PM, Alex J Lennon
 wrote:
>
> On 16/10/2014 12:38, Edward Ned Harvey (mono) wrote:
>>> From: Alex J Lennon [mailto:ajlen...@dynamicdevices.co.uk]
>>>
 Generally
 speaking, the only reasons to build on windows are because you want to
 debug the code, which is generally better done on mac/linux.  Or you're
 trying to accomplish something else, like obtain a specific DLL (such as
 Mono.Data.Sqlite)...  Which usually you can obtain some other way such as
 building on linux and then copying the DLL over to windows.
>>> Agreed, but the the other reason is that you want to use a current Mono
>>> yet nobody has gotten around to an official release of Mono for WIndows
>>> since 3.2.3.
>> Agreed, but that's the point - Why would you want to use Mono on windows?  
>> The only reasons I know of are (a) you wish to debug the mono sources using 
>> Visual Studio, or (b) you wish to use one of Mono's assemblies in windows, 
>> such as Mono.Security, Mono.Data.Sqlite, etc.
>>
>> For case (a), at least for me, it's been easier to transition to Xamarin 
>> Studio or Monodevelop on mac/linux.
>>
>> For case (b) I was able to brainlessly copy Mono.Security.dll, and I 
>> struggled a little bit to copy Mono.Data.Sqlite.dll, but after a few tries, 
>> managed to get it right more easily than getting it to build natively on 
>> windows.
>>
>>
>
> I guess different people will have different use-cases but this is ours
> (which I don't think is so unique)
>
> We develop software targetting Embedded Linux, Windows desktop/server
> and Windows CE/Embedded Compact with .NET CF.
>
> We use Visual Studio (plus Resharper as Bryan so rightly says - couldn't
> get along without it) as we find this to be a productive development
> environment.
> In addition there is a lot of development resource out there with people
> who know and are qualified on the VS toolchain.
>
> Ideally we'd be write once and it'd just work whatever the platform or
> framework, but the reality is we run into platform dependencies (SQLite
> as you say, serial comms in the past), native dependencies and
> configuration issues.
>
> From a productivity perspective and for risk management for testing and
> deployment I wish to be able to develop and debug under Visual Studio
> with Mono as a framework option.
>
> I'd like to be able to do that with Mono on Windows as a check that no
> issues come up between running on the .NET framework and running on Mono.
>
> In addition I'd like to be able to remote debug to Embedded Linux with
> Visual Studio - which  I used to be able to do with Xamarin's Monotools
> Server before it disappeared.
>
> I'm currently investigating a VS plugin to replace Monotools Server
> which I've not had much luck with yet, but I'm optimistic:
> https://github.com/DynamicDevices/monodebugvs
>
> Cheers,
>
> Alex
>
> ___
> Mono-devel-list mailing list
> Mono-devel-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list



-- 
Studying for the Turing test
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Building mono on Windows issues.

[Bryan Crotaz]

continued... (grrr PEBKAC)
https://www.jetbrains.com/resharper/features/code_analysis.html

On 16 October 2014 14:35, Bryan Crotaz 
wrote:

> You can probably do 5-10% max of resharper this way.  Here's some examples
> of how it speeds up my day:
>
> On 16 October 2014 14:22, Greg Young  wrote:
>
>> This may help you a bit
>>
>> https://www.google.co.uk/search?client=safari&rls=en&q=greg+young+sublime+is+sublime&ie=UTF-8&oe=UTF-8&gfe_rd=cr&ei=FsY_VN3ALO3H8gfZwoKwBg
>> you can do much of VS + R# in sublime/vim if you spend the time to set
>> it up.
>>
>> Cheers,
>>
>> Greg
>>
>> On Thu, Oct 16, 2014 at 1:45 PM, Alex J Lennon
>>  wrote:
>> >
>> > On 16/10/2014 12:38, Edward Ned Harvey (mono) wrote:
>> >>> From: Alex J Lennon [mailto:ajlen...@dynamicdevices.co.uk]
>> >>>
>>  Generally
>>  speaking, the only reasons to build on windows are because you want
>> to
>>  debug the code, which is generally better done on mac/linux.  Or
>> you're
>>  trying to accomplish something else, like obtain a specific DLL
>> (such as
>>  Mono.Data.Sqlite)...  Which usually you can obtain some other way
>> such as
>>  building on linux and then copying the DLL over to windows.
>> >>> Agreed, but the the other reason is that you want to use a current
>> Mono
>> >>> yet nobody has gotten around to an official release of Mono for
>> WIndows
>> >>> since 3.2.3.
>> >> Agreed, but that's the point - Why would you want to use Mono on
>> windows?  The only reasons I know of are (a) you wish to debug the mono
>> sources using Visual Studio, or (b) you wish to use one of Mono's
>> assemblies in windows, such as Mono.Security, Mono.Data.Sqlite, etc.
>> >>
>> >> For case (a), at least for me, it's been easier to transition to
>> Xamarin Studio or Monodevelop on mac/linux.
>> >>
>> >> For case (b) I was able to brainlessly copy Mono.Security.dll, and I
>> struggled a little bit to copy Mono.Data.Sqlite.dll, but after a few tries,
>> managed to get it right more easily than getting it to build natively on
>> windows.
>> >>
>> >>
>> >
>> > I guess different people will have different use-cases but this is ours
>> > (which I don't think is so unique)
>> >
>> > We develop software targetting Embedded Linux, Windows desktop/server
>> > and Windows CE/Embedded Compact with .NET CF.
>> >
>> > We use Visual Studio (plus Resharper as Bryan so rightly says - couldn't
>> > get along without it) as we find this to be a productive development
>> > environment.
>> > In addition there is a lot of development resource out there with people
>> > who know and are qualified on the VS toolchain.
>> >
>> > Ideally we'd be write once and it'd just work whatever the platform or
>> > framework, but the reality is we run into platform dependencies (SQLite
>> > as you say, serial comms in the past), native dependencies and
>> > configuration issues.
>> >
>> > From a productivity perspective and for risk management for testing and
>> > deployment I wish to be able to develop and debug under Visual Studio
>> > with Mono as a framework option.
>> >
>> > I'd like to be able to do that with Mono on Windows as a check that no
>> > issues come up between running on the .NET framework and running on
>> Mono.
>> >
>> > In addition I'd like to be able to remote debug to Embedded Linux with
>> > Visual Studio - which  I used to be able to do with Xamarin's Monotools
>> > Server before it disappeared.
>> >
>> > I'm currently investigating a VS plugin to replace Monotools Server
>> > which I've not had much luck with yet, but I'm optimistic:
>> > https://github.com/DynamicDevices/monodebugvs
>> >
>> > Cheers,
>> >
>> > Alex
>> >
>> > ___
>> > Mono-devel-list mailing list
>> > Mono-devel-list@lists.ximian.com
>> > http://lists.ximian.com/mailman/listinfo/mono-devel-list
>>
>>
>>
>> --
>> Studying for the Turing test
>> ___
>> Mono-devel-list mailing list
>> Mono-devel-list@lists.ximian.com
>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>>
>
>
>
> --
> Bryan Crotaz
> Managing Director
> Silver Curve
>



-- 
Bryan Crotaz
Managing Director
Silver Curve
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Building mono on Windows issues.

[Bryan Crotaz]

Basically if we could persuade Xamarin to get mono building on Windows and
VS users able to debug Mono, suddenly there would be a lot more developers
able to contribute without having to learn a whole new stack first.

Bryan

On 16 October 2014 14:36, Bryan Crotaz 
wrote:

> continued... (grrr PEBKAC)
> https://www.jetbrains.com/resharper/features/code_analysis.html
>
> On 16 October 2014 14:35, Bryan Crotaz 
> wrote:
>
>> You can probably do 5-10% max of resharper this way.  Here's some
>> examples of how it speeds up my day:
>>
>> On 16 October 2014 14:22, Greg Young  wrote:
>>
>>> This may help you a bit
>>>
>>> https://www.google.co.uk/search?client=safari&rls=en&q=greg+young+sublime+is+sublime&ie=UTF-8&oe=UTF-8&gfe_rd=cr&ei=FsY_VN3ALO3H8gfZwoKwBg
>>> you can do much of VS + R# in sublime/vim if you spend the time to set
>>> it up.
>>>
>>> Cheers,
>>>
>>> Greg
>>>
>>> On Thu, Oct 16, 2014 at 1:45 PM, Alex J Lennon
>>>  wrote:
>>> >
>>> > On 16/10/2014 12:38, Edward Ned Harvey (mono) wrote:
>>> >>> From: Alex J Lennon [mailto:ajlen...@dynamicdevices.co.uk]
>>> >>>
>>>  Generally
>>>  speaking, the only reasons to build on windows are because you want
>>> to
>>>  debug the code, which is generally better done on mac/linux.  Or
>>> you're
>>>  trying to accomplish something else, like obtain a specific DLL
>>> (such as
>>>  Mono.Data.Sqlite)...  Which usually you can obtain some other way
>>> such as
>>>  building on linux and then copying the DLL over to windows.
>>> >>> Agreed, but the the other reason is that you want to use a current
>>> Mono
>>> >>> yet nobody has gotten around to an official release of Mono for
>>> WIndows
>>> >>> since 3.2.3.
>>> >> Agreed, but that's the point - Why would you want to use Mono on
>>> windows?  The only reasons I know of are (a) you wish to debug the mono
>>> sources using Visual Studio, or (b) you wish to use one of Mono's
>>> assemblies in windows, such as Mono.Security, Mono.Data.Sqlite, etc.
>>> >>
>>> >> For case (a), at least for me, it's been easier to transition to
>>> Xamarin Studio or Monodevelop on mac/linux.
>>> >>
>>> >> For case (b) I was able to brainlessly copy Mono.Security.dll, and I
>>> struggled a little bit to copy Mono.Data.Sqlite.dll, but after a few tries,
>>> managed to get it right more easily than getting it to build natively on
>>> windows.
>>> >>
>>> >>
>>> >
>>> > I guess different people will have different use-cases but this is ours
>>> > (which I don't think is so unique)
>>> >
>>> > We develop software targetting Embedded Linux, Windows desktop/server
>>> > and Windows CE/Embedded Compact with .NET CF.
>>> >
>>> > We use Visual Studio (plus Resharper as Bryan so rightly says -
>>> couldn't
>>> > get along without it) as we find this to be a productive development
>>> > environment.
>>> > In addition there is a lot of development resource out there with
>>> people
>>> > who know and are qualified on the VS toolchain.
>>> >
>>> > Ideally we'd be write once and it'd just work whatever the platform or
>>> > framework, but the reality is we run into platform dependencies (SQLite
>>> > as you say, serial comms in the past), native dependencies and
>>> > configuration issues.
>>> >
>>> > From a productivity perspective and for risk management for testing and
>>> > deployment I wish to be able to develop and debug under Visual Studio
>>> > with Mono as a framework option.
>>> >
>>> > I'd like to be able to do that with Mono on Windows as a check that no
>>> > issues come up between running on the .NET framework and running on
>>> Mono.
>>> >
>>> > In addition I'd like to be able to remote debug to Embedded Linux with
>>> > Visual Studio - which  I used to be able to do with Xamarin's Monotools
>>> > Server before it disappeared.
>>> >
>>> > I'm currently investigating a VS plugin to replace Monotools Server
>>> > which I've not had much luck with yet, but I'm optimistic:
>>> > https://github.com/DynamicDevices/monodebugvs
>>> >
>>> > Cheers,
>>> >
>>> > Alex
>>> >
>>> > ___
>>> > Mono-devel-list mailing list
>>> > Mono-devel-list@lists.ximian.com
>>> > http://lists.ximian.com/mailman/listinfo/mono-devel-list
>>>
>>>
>>>
>>> --
>>> Studying for the Turing test
>>> ___
>>> Mono-devel-list mailing list
>>> Mono-devel-list@lists.ximian.com
>>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>>>
>>
>>
>>
>> --
>> Bryan Crotaz
>> Managing Director
>> Silver Curve
>>
>
>
>
> --
> Bryan Crotaz
> Managing Director
> Silver Curve
>



-- 
Bryan Crotaz
Managing Director
Silver Curve
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Building mono on Windows issues.

[Edward Ned Harvey (mono)]

> From: Alex J Lennon [mailto:ajlen...@dynamicdevices.co.uk]
> 
> We use Visual Studio (plus Resharper as Bryan so rightly says - couldn't
> get along without it) as we find this to be a productive development
> environment.

+1


> In addition there is a lot of development resource out there with people
> who know and are qualified on the VS toolchain.

+1 again


> From a productivity perspective and for risk management for testing and
> deployment I wish to be able to develop and debug under Visual Studio
> with Mono as a framework option.
> 
> I'd like to be able to do that with Mono on Windows as a check that no
> issues come up between running on the .NET framework and running on
> Mono.

You can do that.  Don't need to build mono on windows - just do a normal 
mono-for-windows install - I haven't done it in a while, but there's a plugin 
to run your code against the mono runtime instead of .Net.  I'm pretty sure 
it's free - might even be a standard extension you can find with the Extension 
manager.


> In addition I'd like to be able to remote debug to Embedded Linux with
> Visual Studio - which  I used to be able to do with Xamarin's Monotools
> Server before it disappeared.

Again, you don't need to build mono to do this.  But this feature I'm sure, is 
not free.  It's included in Xamarin Business.  They offer Visual Studio support 
as one of the features of Xam Bus.  It allows you to do remote debugging with 
VS running a mono app on some remote mac or linux mono machine.


> I'm currently investigating a VS plugin to replace Monotools Server
> which I've not had much luck with yet, but I'm optimistic:
> https://github.com/DynamicDevices/monodebugvs

Interesting.  I guess I have to take back what I just said about "I'm sure it's 
not free."   ;-)   Should revise:  I'm sure Xam offers a commercial solution, 
and apparently there is also some hope for a free alternative.

So all the above boils down to ...  As I said, the only reason I know you need 
to build mono on windows is if you want to step through the *mono* code, not 
just your own code.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Building mono on Windows issues.

[Alex J Lennon]

On 16/10/2014 15:37, Bryan Crotaz wrote:
> Basically if we could persuade Xamarin to get mono building on Windows
> and VS users able to debug Mono, suddenly there would be a lot more
> developers able to contribute without having to learn a whole new
> stack first.
>
> Bryan

+1 and I'm happy to put some time in to help in any way I can.

Alex

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Building mono on Windows issues.

[Greg Young]

Oddly I have actually used this thing known as resharper before and
have some idea how it works. You can do a hell of a lot more than
5-10% of what you use. Have you even bothered to go through the post
list that explained how to setup much of what R# can do before
deciding its impossible?

On Thu, Oct 16, 2014 at 2:36 PM, Bryan Crotaz
 wrote:
> continued... (grrr PEBKAC)
> https://www.jetbrains.com/resharper/features/code_analysis.html
>
> On 16 October 2014 14:35, Bryan Crotaz 
> wrote:
>>
>> You can probably do 5-10% max of resharper this way.  Here's some examples
>> of how it speeds up my day:
>>
>> On 16 October 2014 14:22, Greg Young  wrote:
>>>
>>> This may help you a bit
>>>
>>> https://www.google.co.uk/search?client=safari&rls=en&q=greg+young+sublime+is+sublime&ie=UTF-8&oe=UTF-8&gfe_rd=cr&ei=FsY_VN3ALO3H8gfZwoKwBg
>>> you can do much of VS + R# in sublime/vim if you spend the time to set
>>> it up.
>>>
>>> Cheers,
>>>
>>> Greg
>>>
>>> On Thu, Oct 16, 2014 at 1:45 PM, Alex J Lennon
>>>  wrote:
>>> >
>>> > On 16/10/2014 12:38, Edward Ned Harvey (mono) wrote:
>>> >>> From: Alex J Lennon [mailto:ajlen...@dynamicdevices.co.uk]
>>> >>>
>>>  Generally
>>>  speaking, the only reasons to build on windows are because you want
>>>  to
>>>  debug the code, which is generally better done on mac/linux.  Or
>>>  you're
>>>  trying to accomplish something else, like obtain a specific DLL
>>>  (such as
>>>  Mono.Data.Sqlite)...  Which usually you can obtain some other way
>>>  such as
>>>  building on linux and then copying the DLL over to windows.
>>> >>> Agreed, but the the other reason is that you want to use a current
>>> >>> Mono
>>> >>> yet nobody has gotten around to an official release of Mono for
>>> >>> WIndows
>>> >>> since 3.2.3.
>>> >> Agreed, but that's the point - Why would you want to use Mono on
>>> >> windows?  The only reasons I know of are (a) you wish to debug the mono
>>> >> sources using Visual Studio, or (b) you wish to use one of Mono's 
>>> >> assemblies
>>> >> in windows, such as Mono.Security, Mono.Data.Sqlite, etc.
>>> >>
>>> >> For case (a), at least for me, it's been easier to transition to
>>> >> Xamarin Studio or Monodevelop on mac/linux.
>>> >>
>>> >> For case (b) I was able to brainlessly copy Mono.Security.dll, and I
>>> >> struggled a little bit to copy Mono.Data.Sqlite.dll, but after a few 
>>> >> tries,
>>> >> managed to get it right more easily than getting it to build natively on
>>> >> windows.
>>> >>
>>> >>
>>> >
>>> > I guess different people will have different use-cases but this is ours
>>> > (which I don't think is so unique)
>>> >
>>> > We develop software targetting Embedded Linux, Windows desktop/server
>>> > and Windows CE/Embedded Compact with .NET CF.
>>> >
>>> > We use Visual Studio (plus Resharper as Bryan so rightly says -
>>> > couldn't
>>> > get along without it) as we find this to be a productive development
>>> > environment.
>>> > In addition there is a lot of development resource out there with
>>> > people
>>> > who know and are qualified on the VS toolchain.
>>> >
>>> > Ideally we'd be write once and it'd just work whatever the platform or
>>> > framework, but the reality is we run into platform dependencies (SQLite
>>> > as you say, serial comms in the past), native dependencies and
>>> > configuration issues.
>>> >
>>> > From a productivity perspective and for risk management for testing and
>>> > deployment I wish to be able to develop and debug under Visual Studio
>>> > with Mono as a framework option.
>>> >
>>> > I'd like to be able to do that with Mono on Windows as a check that no
>>> > issues come up between running on the .NET framework and running on
>>> > Mono.
>>> >
>>> > In addition I'd like to be able to remote debug to Embedded Linux with
>>> > Visual Studio - which  I used to be able to do with Xamarin's Monotools
>>> > Server before it disappeared.
>>> >
>>> > I'm currently investigating a VS plugin to replace Monotools Server
>>> > which I've not had much luck with yet, but I'm optimistic:
>>> > https://github.com/DynamicDevices/monodebugvs
>>> >
>>> > Cheers,
>>> >
>>> > Alex
>>> >
>>> > ___
>>> > Mono-devel-list mailing list
>>> > Mono-devel-list@lists.ximian.com
>>> > http://lists.ximian.com/mailman/listinfo/mono-devel-list
>>>
>>>
>>>
>>> --
>>> Studying for the Turing test
>>> ___
>>> Mono-devel-list mailing list
>>> Mono-devel-list@lists.ximian.com
>>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>>
>>
>>
>>
>> --
>> Bryan Crotaz
>> Managing Director
>> Silver Curve
>
>
>
>
> --
> Bryan Crotaz
> Managing Director
> Silver Curve



-- 
Studying for the Turing test
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Building mono on Windows issues.

[Bryan Crotaz]

You can probably do 5-10% max of resharper this way.  Here's some examples
of how it speeds up my day:

On 16 October 2014 14:22, Greg Young  wrote:

> This may help you a bit
>
> https://www.google.co.uk/search?client=safari&rls=en&q=greg+young+sublime+is+sublime&ie=UTF-8&oe=UTF-8&gfe_rd=cr&ei=FsY_VN3ALO3H8gfZwoKwBg
> you can do much of VS + R# in sublime/vim if you spend the time to set
> it up.
>
> Cheers,
>
> Greg
>
> On Thu, Oct 16, 2014 at 1:45 PM, Alex J Lennon
>  wrote:
> >
> > On 16/10/2014 12:38, Edward Ned Harvey (mono) wrote:
> >>> From: Alex J Lennon [mailto:ajlen...@dynamicdevices.co.uk]
> >>>
>  Generally
>  speaking, the only reasons to build on windows are because you want to
>  debug the code, which is generally better done on mac/linux.  Or
> you're
>  trying to accomplish something else, like obtain a specific DLL (such
> as
>  Mono.Data.Sqlite)...  Which usually you can obtain some other way
> such as
>  building on linux and then copying the DLL over to windows.
> >>> Agreed, but the the other reason is that you want to use a current Mono
> >>> yet nobody has gotten around to an official release of Mono for WIndows
> >>> since 3.2.3.
> >> Agreed, but that's the point - Why would you want to use Mono on
> windows?  The only reasons I know of are (a) you wish to debug the mono
> sources using Visual Studio, or (b) you wish to use one of Mono's
> assemblies in windows, such as Mono.Security, Mono.Data.Sqlite, etc.
> >>
> >> For case (a), at least for me, it's been easier to transition to
> Xamarin Studio or Monodevelop on mac/linux.
> >>
> >> For case (b) I was able to brainlessly copy Mono.Security.dll, and I
> struggled a little bit to copy Mono.Data.Sqlite.dll, but after a few tries,
> managed to get it right more easily than getting it to build natively on
> windows.
> >>
> >>
> >
> > I guess different people will have different use-cases but this is ours
> > (which I don't think is so unique)
> >
> > We develop software targetting Embedded Linux, Windows desktop/server
> > and Windows CE/Embedded Compact with .NET CF.
> >
> > We use Visual Studio (plus Resharper as Bryan so rightly says - couldn't
> > get along without it) as we find this to be a productive development
> > environment.
> > In addition there is a lot of development resource out there with people
> > who know and are qualified on the VS toolchain.
> >
> > Ideally we'd be write once and it'd just work whatever the platform or
> > framework, but the reality is we run into platform dependencies (SQLite
> > as you say, serial comms in the past), native dependencies and
> > configuration issues.
> >
> > From a productivity perspective and for risk management for testing and
> > deployment I wish to be able to develop and debug under Visual Studio
> > with Mono as a framework option.
> >
> > I'd like to be able to do that with Mono on Windows as a check that no
> > issues come up between running on the .NET framework and running on Mono.
> >
> > In addition I'd like to be able to remote debug to Embedded Linux with
> > Visual Studio - which  I used to be able to do with Xamarin's Monotools
> > Server before it disappeared.
> >
> > I'm currently investigating a VS plugin to replace Monotools Server
> > which I've not had much luck with yet, but I'm optimistic:
> > https://github.com/DynamicDevices/monodebugvs
> >
> > Cheers,
> >
> > Alex
> >
> > ___
> > Mono-devel-list mailing list
> > Mono-devel-list@lists.ximian.com
> > http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
>
>
> --
> Studying for the Turing test
> ___
> Mono-devel-list mailing list
> Mono-devel-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>



-- 
Bryan Crotaz
Managing Director
Silver Curve
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Building mono on Windows issues.

[Alex J Lennon]

>> From a productivity perspective and for risk management for testing and
>> deployment I wish to be able to develop and debug under Visual Studio
>> with Mono as a framework option.
>>
>> I'd like to be able to do that with Mono on Windows as a check that no
>> issues come up between running on the .NET framework and running on
>> Mono.
> You can do that.  Don't need to build mono on windows - just do a normal 
> mono-for-windows install - I haven't done it in a while, but there's a plugin 
> to run your code against the mono runtime instead of .Net.  I'm pretty sure 
> it's free - might even be a standard extension you can find with the 
> Extension manager.
>

But this is exactly the point. I can't :-/ I wish I could.

I have Mono 3.8.0 built for multiple Embedded Linux platforms out of
Yocto and I want to use 3.8.0 on Windows in the development cycle, not
3.2.3 from September 2013.

I wish to be running the same releases of code for
development/debug/deployment in as far as is possible to catch any
potential problems.

But nobody seems to have ownership of at present of keeping Windows
binary releases in sync with Mono source/binary releases, which surely
isn't a major task?

>> In addition I'd like to be able to remote debug to Embedded Linux with
>> Visual Studio - which  I used to be able to do with Xamarin's Monotools
>> Server before it disappeared.
> Again, you don't need to build mono to do this.  But this feature I'm sure, 
> is not free.  It's included in Xamarin Business.  They offer Visual Studio 
> support as one of the features of Xam Bus.  It allows you to do remote 
> debugging with VS running a mono app on some remote mac or linux mono machine.
>

If the MonoTools plugin was still available I'd be happy to pay for
it... Perhaps I may investigate Xam Bus but for now if the alternate
OpenSource plugin will do the job for me that would make me very happy :)

Cheers,

Alex



___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Building mono on Windows issues.

[Edward Ned Harvey (mono)]

> From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list-
> boun...@lists.ximian.com] On Behalf Of Bryan Crotaz
> 
> Basically if we could persuade Xamarin to get mono building on Windows and
> VS users able to debug Mono, suddenly there would be a lot more
> developers able to contribute without having to learn a whole new stack
> first.

As discussed previously on this list in other threads, the barrier to 
contribution to the mono code base is not a lack of developers - there are 
plenty of people willing and able to work with XS or MD on mac and linux.  The 
problem is bottleneck of Xam employees to review and test code submissions.  
There is already a huge backlog of pull requests; they just don't have enough 
human resource to handle it.  The community isn't pouring forth with 
experienced volunteer maintainers to step into that role either.  And it takes 
quite an investment to get all the build & test VM's up to run a full fledged 
test environment anyway, which is necessary to pass before pull requests can be 
accepted.

Hopefully this can improve someday.  For now, community contribution is sparse.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Building mono on Windows issues.

[Mladen Mihajlovic]

Contributions are one thing, but there should be a windows build system
implemented and running - even continuous integration running for each
commit. I'm pretty sure there's a Jenkins set up for the linux/mac builds
but non for Windows? Why?

On 16 October 2014 15:45, Edward Ned Harvey (mono) <
edward.harvey.m...@clevertrove.com> wrote:

> > From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list-
> > boun...@lists.ximian.com] On Behalf Of Bryan Crotaz
> >
> > Basically if we could persuade Xamarin to get mono building on Windows
> and
> > VS users able to debug Mono, suddenly there would be a lot more
> > developers able to contribute without having to learn a whole new stack
> > first.
>
> As discussed previously on this list in other threads, the barrier to
> contribution to the mono code base is not a lack of developers - there are
> plenty of people willing and able to work with XS or MD on mac and linux.
> The problem is bottleneck of Xam employees to review and test code
> submissions.  There is already a huge backlog of pull requests; they just
> don't have enough human resource to handle it.  The community isn't pouring
> forth with experienced volunteer maintainers to step into that role
> either.  And it takes quite an investment to get all the build & test VM's
> up to run a full fledged test environment anyway, which is necessary to
> pass before pull requests can be accepted.
>
> Hopefully this can improve someday.  For now, community contribution is
> sparse.
> ___
> Mono-devel-list mailing list
> Mono-devel-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Building mono on Windows issues.

[DavidKarlas]

About debugging Mono on remote device(Linux) from VisualStudio...
http://www.giesswein-apps.at/mono aka.
https://github.com/giessweinapps/MonoDebugger

About compiling itself... Don't want to sound like jerk but... It's open
source make it compilable with Visual Studio tool chain and open PR...

About code analysis... Did you enable Source analysis in MonoDevelop/XS?
It's not resharper but it's open source if you miss some code action feel
free to PR...

I think it doesn't make much sense to remote debug Linux Desktop/Mac Desktop
from Windows thats probably why Novell remote debugger died...



--
View this message in context: 
http://mono.1490590.n4.nabble.com/Building-mono-on-Windows-issues-tp4664183p4664212.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Building mono on Windows issues.

[Bryan Crotaz]

What's the estimation of effort required to get mono buildable in
windows and debuggable in VS? 6 man months? 18 man months?

I don't have time to donate but I'd be happy to put some money in a
pot with some of you to hire someone to work on this full time. Feels
like a concerted full time effort would bear more fruit than
occasional toe-dips in the water.

Bryan Crotaz
Silver Curve

> On 16 Oct 2014, at 14:54, DavidKarlas  wrote:
>
> About debugging Mono on remote device(Linux) from VisualStudio...
> http://www.giesswein-apps.at/mono aka.
> https://github.com/giessweinapps/MonoDebugger
>
> About compiling itself... Don't want to sound like jerk but... It's open
> source make it compilable with Visual Studio tool chain and open PR...
>
> About code analysis... Did you enable Source analysis in MonoDevelop/XS?
> It's not resharper but it's open source if you miss some code action feel
> free to PR...
>
> I think it doesn't make much sense to remote debug Linux Desktop/Mac Desktop
> from Windows thats probably why Novell remote debugger died...
>
>
>
> --
> View this message in context: 
> http://mono.1490590.n4.nabble.com/Building-mono-on-Windows-issues-tp4664183p4664212.html
> Sent from the Mono - Dev mailing list archive at Nabble.com.
> ___
> Mono-devel-list mailing list
> Mono-devel-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Building mono on Windows issues.

[Vincent Povirk]

> What's the estimation of effort required to get mono buildable in
> windows and debuggable in VS? 6 man months? 18 man months?

I do builds from master for Windows regularly (but on Linux using
mingw-w64), so getting it to work shouldn't be anywhere near that
difficult. I've seen someone on irc who does builds on Windows using
VS. The Windows build on master is chronically broken but also
chronically fixed by people who rely on it. Often the build happens to
be broken during a release, and that is never fixed. (It's entirely
possible, however, that no one uses cygwin to build on master and it
never gets fixed.)

CI on Windows would certainly be helpful, especially if it included
running the Mono tests in .NET (so we know the tests are really
correct).

As for the original issue in this thread:

In file included from socket-io.c:30:0:
/usr/i686-pc-mingw32/sys-root/
mingw/include/ws2tcpip.h:38:2: error:
#error "ws2tcpip.h is not compatible with winsock.h. Include
winsock2.h instead."

I don't know anything about building with cygwin, but I would guess
something in your version of the standard cygwin headers is pulling in
winsock.h. Easiest way to find it is probably to add a define to
socket-io.c before the includes that will conflict with something
defined by winsock.h, i.e. add "int accept;" to the top of the file.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Building mono on Windows issues.

[Alex J Lennon]

On 16/10/2014 16:58, Bryan Crotaz wrote:
> What's the estimation of effort required to get mono buildable in
> windows and debuggable in VS? 6 man months? 18 man months?
>
> I don't have time to donate but I'd be happy to put some money in a
> pot with some of you to hire someone to work on this full time. Feels
> like a concerted full time effort would bear more fruit than
> occasional toe-dips in the water.

Bryan,

fwiw - and this is merely a view from a bystander - I don't think it
would take a lot to address the Windows build itself today.

Mono does build on Windows, but it doesn't "just work" as people tend to
expect nowadays. It needs some stream-lining imho with some setup script
automation or similar for newbies. There are also some missing links in
how an official Windows release is created versus using make, as we end
up with missing files on install (or I am misunderstanding  something
that needs doing, which in itself would be a documentation issue).

To me this isn't a code issue so much as an ownership and release
management issue. I recognise there is a cost to that and there has to
be an ROI for that cost to be worth bearing.

Releases are made with broken Window builds as Vincent says. So imho
it's a dead work "fixing" master at any given time as it will just
become broken again, although some basic setup scripting to pull down
Cygwin, dependencies, to get the installation step working and such
would help people to get going, I feel.

What's more relevant, I believe, is a maintainer who has committed to
Windows build testing and patching prior to an  offical release of Mono,
a buy-in from other release maintainers that this is worth doing (or
what's the point?), and perhaps some CI running the Mono tests in the
background.

Just my 4 cents,

Alex
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Building mono on Windows issues.

[Jonathan Chambers]

Hello,

I was maintaining the Visual Studio solution for the runtime and doing
Windows development for a while but haven't kept up for a number of years
now. We've had a number of "build mono on Windows" discussions over the
years and various attempts at improving it. Breaking the discussion into
two pieces:

Release/Install/CI for Windows

This was done with cygwin and was packaged by an additional installer step.
The installer step was never very transparent so I can't comment on that.
As for cygwin, the main issues were:
- it's an amalgam of tools, which constantly update. There was never an
easy way to duplicate a working setup from one machine to the next
- given the size and complexity of the mono build and tests, it was
generally not robust. Especially for continuous and automated usage
- it was slow. Slow as in hours on Windows vs minutes on Linux

Developing on Windows

As for actually developing mono on Windows, the main issue was that you
could not easily use Visual Studio to develop mono. The VS support for the
runtime was put together long ago as a way to develop/debug, but it still
required the full cygwin build to configure everything, build the class
libraries, and run the tests. Even if one was brave enough to work in this
setup, iteration time was slow (see above). Miguel and others made efforts
to build everything using MSBuild but nothing quite materialized for a
variety of reasons.


All that to say, if you just want to get the Windows support back to where
it was a few years ago via cygwin it can probably be done in a few
developer weeks. If you actually want to improve the Windows development
story, allowing for actual development and usage of Windows tools like
Visual Studio it's much more work. I'd love for the latter to happen, but
it's would take a lot of effort and coordination. Effort like improving
xbuild where needed if msbuild is the build mechanism of choice.
Coordination like making sure any work done didn't harm other platforms.

- Jonathan



On Thu, Oct 16, 2014 at 2:16 PM, Alex J Lennon <
ajlen...@dynamicdevices.co.uk> wrote:

>
> On 16/10/2014 16:58, Bryan Crotaz wrote:
> > What's the estimation of effort required to get mono buildable in
> > windows and debuggable in VS? 6 man months? 18 man months?
> >
> > I don't have time to donate but I'd be happy to put some money in a
> > pot with some of you to hire someone to work on this full time. Feels
> > like a concerted full time effort would bear more fruit than
> > occasional toe-dips in the water.
>
> Bryan,
>
> fwiw - and this is merely a view from a bystander - I don't think it
> would take a lot to address the Windows build itself today.
>
> Mono does build on Windows, but it doesn't "just work" as people tend to
> expect nowadays. It needs some stream-lining imho with some setup script
> automation or similar for newbies. There are also some missing links in
> how an official Windows release is created versus using make, as we end
> up with missing files on install (or I am misunderstanding  something
> that needs doing, which in itself would be a documentation issue).
>
> To me this isn't a code issue so much as an ownership and release
> management issue. I recognise there is a cost to that and there has to
> be an ROI for that cost to be worth bearing.
>
> Releases are made with broken Window builds as Vincent says. So imho
> it's a dead work "fixing" master at any given time as it will just
> become broken again, although some basic setup scripting to pull down
> Cygwin, dependencies, to get the installation step working and such
> would help people to get going, I feel.
>
> What's more relevant, I believe, is a maintainer who has committed to
> Windows build testing and patching prior to an  offical release of Mono,
> a buy-in from other release maintainers that this is worth doing (or
> what's the point?), and perhaps some CI running the Mono tests in the
> background.
>
> Just my 4 cents,
>
> Alex
> ___
> Mono-devel-list mailing list
> Mono-devel-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Building mono on Windows issues.

[Alex J Lennon]

Hi Jonathan,

Thanks for taking the time to provide the background.

I understand/agree that facilitating development on Windows is a complex
task. I've seen some of the emails over time and can well imagine it's
complex and invasive to the existing build system. People start the
work, but I''ve not seen anything come out of it.

If I take my scope as something much simpler, which is just to
facilitate building Mono on Windows from scratch, on a vanilla Windows
platform, perhaps defined as Windows 7/8.1 x32/x64 or whatever, then I
think that's much more achievable.

I have been looking at this since 3.4.0 and the main issues I have
encountered were having the right dependencies, idiosyncracies of the
build tools, and issues with releases such as missing files/problems
with Cygwin headers.

Perhaps very few of us are fit for purpose when it comes to actually
_contributing_ to Mono, but I can well understand that the first step an
OpenSource developer wants to make is to compile a project from source
and run up the results.

I can also understand the frustration when you've spent a couple of days
on this and just keep encountering problems. People can then give up in
frustration.

Even the longest journey begins with a single step and it strikes me
that it would be a useful thing to facilitate newbies building on
Windows to get them going on that journey, even if that's just by
documenting issues they will encounter.

The emails I get from individuals show me that when they do have the
information they need to build Mono, and how to work around the gotchas,
then they can do it with relative ease.

>- it's an amalgam of tools, which constantly update. There was never an
easy way to duplicate a working setup from one machine to the next

I agree, but that's an issue with any complex software project with
build dependencies surely? I work with Yocto Embedded Linux builds and I
can tell you that it's even more difficult there, but they manage it
extremely well.

To address this seems to me a matter of understanding/documenting the
dependencies and, where necessary, defining the require versions of
those dependencies to ensure a build works in a controlled manner.

I am making an assumption that the dependencies are all on Cygwin (are
there any others?). If so then it should be relatively straightforward
to define the version of Cygwin to use and/or pull down specific
versioned packages.

It was suggested to me that a setup script that pulled down appropriate
dependencies would be useful, and I agree. I have been meaning to do
something on that as I think it is straightforward but haven't yet had
the time.

If this was to be in place do you think there would be any other
toolchain issues that would need consideration?

>This was done with cygwin and was packaged by an additional installer
step. The installer step was never very transparent so I can't comment
on that.

Somebody somewhere must have been building the Windows installer, at
least up until 3.2.3. I believe it would be helpful if somebody could
take time to explain how this works or just provide the automation to
build the installer.

When we execute the 'make install' step what results on Windows is
missing key files such as 'mono.exe' and instead has Linux stubs such as
'mono' which causes problems. I would like to understand how the install
step is supposed to work and to try to fix it instead of having to
manually fix it up each time. Similarly I would like to be able to
generate a non-official installer in the same way as the official
installer is built, which at least
people could then use in the absence of an official installer.

> given the size and complexity of the mono build and tests, it was
generally not robust. Especially for continuous and automated usage

My experience is that once the issues with any given release are
addressed then it builds reliably. Master is of course a different beast
but I am not looking at supporting a build from an arbitrary commit here.

>- it was slow. Slow as in hours on Windows vs minutes on Linux

Yes, my guess is that it's perhaps related to forking on Windows under
Cygwin but who knows.

It would be nice to have a faster build but, for example, building a
Yocto image can take many, many hours. (And don't get me started on
WindowsCE...) I think people can live with this if it actually builds
for them.

To me a first pass at needed actions are:

- define one or more supported Windows build host platforms.
- take the latest Mono 3.10.0 release and create an installer script for
versioned build dependencies
- create a simple build script and test script
- understand how the packaging step works and automate this

- fix issues with installation of Mono files that aren't currently
correct under Windows (e.g. mono 3.8.0 mono.exe, perhaps fixed in 3.10.0) 
- fix issues with needing to change Cygwin headers for the compile to work.

- setup a CI system building and reporting for master.

Ideally, as I've said earl

Re: [Mono-dev] Building mono on Windows issues.

[Mladen Mihajlovic]

Hi Guys,

I took it upon myself to try and get a build up and running on Appveyor
yesterday. Please have a look at https://github.com/mika76/mono and
https://ci.appveyor.com/project/mmihajlovic/mono - so far the only thing
I've edited is the appveyor.yml file and the actual a[[veyor settings.

At the moment it is installing cygwin and packages and running the visual
studio msbuild file - which seems not to work - it fails with "compiler out
of heap space" error.

If the msbuild does not pan out, the cygwin build can always be attempted
as well.

If anybody wants to help, let me know and I'll make you a contributor on
the repository.

Cheers,
Mladen

On 17 October 2014 08:46, Alex J Lennon 
wrote:

>  Hi Jonathan,
>
> Thanks for taking the time to provide the background.
>
> I understand/agree that facilitating development on Windows is a complex
> task. I've seen some of the emails over time and can well imagine it's
> complex and invasive to the existing build system. People start the work,
> but I''ve not seen anything come out of it.
>
> If I take my scope as something much simpler, which is just to facilitate
> building Mono on Windows from scratch, on a vanilla Windows platform,
> perhaps defined as Windows 7/8.1 x32/x64 or whatever, then I think that's
> much more achievable.
>
> I have been looking at this since 3.4.0 and the main issues I have
> encountered were having the right dependencies, idiosyncracies of the build
> tools, and issues with releases such as missing files/problems with Cygwin
> headers.
>
> Perhaps very few of us are fit for purpose when it comes to actually
> _contributing_ to Mono, but I can well understand that the first step an
> OpenSource developer wants to make is to compile a project from source and
> run up the results.
>
> I can also understand the frustration when you've spent a couple of days
> on this and just keep encountering problems. People can then give up in
> frustration.
>
> Even the longest journey begins with a single step and it strikes me that
> it would be a useful thing to facilitate newbies building on Windows to get
> them going on that journey, even if that's just by documenting issues they
> will encounter.
>
> The emails I get from individuals show me that when they do have the
> information they need to build Mono, and how to work around the gotchas,
> then they can do it with relative ease.
>
> >- it's an amalgam of tools, which constantly update. There was never an
> easy way to duplicate a working setup from one machine to the next
>
> I agree, but that's an issue with any complex software project with build
> dependencies surely? I work with Yocto Embedded Linux builds and I can tell
> you that it's even more difficult there, but they manage it extremely well.
>
> To address this seems to me a matter of understanding/documenting the
> dependencies and, where necessary, defining the require versions of those
> dependencies to ensure a build works in a controlled manner.
>
> I am making an assumption that the dependencies are all on Cygwin (are
> there any others?). If so then it should be relatively straightforward to
> define the version of Cygwin to use and/or pull down specific versioned
> packages.
>
> It was suggested to me that a setup script that pulled down appropriate
> dependencies would be useful, and I agree. I have been meaning to do
> something on that as I think it is straightforward but haven't yet had the
> time.
>
> If this was to be in place do you think there would be any other toolchain
> issues that would need consideration?
>
> >This was done with cygwin and was packaged by an additional installer
> step. The installer step was never very transparent so I can't comment on
> that.
>
> Somebody somewhere must have been building the Windows installer, at least
> up until 3.2.3. I believe it would be helpful if somebody could take time
> to explain how this works or just provide the automation to build the
> installer.
>
> When we execute the 'make install' step what results on Windows is missing
> key files such as 'mono.exe' and instead has Linux stubs such as 'mono'
> which causes problems. I would like to understand how the install
> step is supposed to work and to try to fix it instead of having to
> manually fix it up each time. Similarly I would like to be able to generate
> a non-official installer in the same way as the official installer is
> built, which at least
> people could then use in the absence of an official installer.
>
> > given the size and complexity of the mono build and tests, it was
> generally not robust. Especially for continuous and automated usage
>
> My experience is that once the issues with any given release are addressed
> then it builds reliably. Master is of course a different beast but I am not
> looking at supporting a build from an arbitrary commit here.
>
> >- it was slow. Slow as in hours on Windows vs minutes on Linux
>
> Yes, my guess is that it's perhaps related to forking on Windo

Re: [Mono-dev] Building mono on Windows issues.

[Alex J Lennon]

Hi Mladen,

Sounds good to me. I've not encountered Appveyor before but it looks
good. How do you get the Cygwin dependencies in there? Can it be assumed
that what's happening in the Appveyor build is basically the same as on
a standard Windows box?

Cheers,

Alex

On 17/10/2014 08:53, Mladen Mihajlovic wrote:
> Hi Guys,
>
> I took it upon myself to try and get a build up and running on
> Appveyor yesterday. Please have a look
> at https://github.com/mika76/mono
> and https://ci.appveyor.com/project/mmihajlovic/mono - so far the only
> thing I've edited is the appveyor.yml file and the actual a[[veyor
> settings. 
>
> At the moment it is installing cygwin and packages and running the
> visual studio msbuild file - which seems not to work - it fails with
> "compiler out of heap space" error.
>
> If the msbuild does not pan out, the cygwin build can always be
> attempted as well.
>
> If anybody wants to help, let me know and I'll make you a contributor
> on the repository.
>
> Cheers,
> Mladen
>
> On 17 October 2014 08:46, Alex J Lennon  > wrote:
>
> Hi Jonathan,
>
> Thanks for taking the time to provide the background.
>
> I understand/agree that facilitating development on Windows is a
> complex task. I've seen some of the emails over time and can well
> imagine it's complex and invasive to the existing build system.
> People start the work, but I''ve not seen anything come out of it.
>
> If I take my scope as something much simpler, which is just to
> facilitate building Mono on Windows from scratch, on a vanilla
> Windows platform, perhaps defined as Windows 7/8.1 x32/x64 or
> whatever, then I think that's much more achievable.
>
> I have been looking at this since 3.4.0 and the main issues I have
> encountered were having the right dependencies, idiosyncracies of
> the build tools, and issues with releases such as missing
> files/problems with Cygwin headers.
>
> Perhaps very few of us are fit for purpose when it comes to
> actually _contributing_ to Mono, but I can well understand that
> the first step an OpenSource developer wants to make is to compile
> a project from source and run up the results.
>
> I can also understand the frustration when you've spent a couple
> of days on this and just keep encountering problems. People can
> then give up in frustration.
>
> Even the longest journey begins with a single step and it strikes
> me that it would be a useful thing to facilitate newbies building
> on Windows to get them going on that journey, even if that's just
> by documenting issues they will encounter.
>
> The emails I get from individuals show me that when they do have
> the information they need to build Mono, and how to work around
> the gotchas, then they can do it with relative ease.
>
> >- it's an amalgam of tools, which constantly update. There was
> never an easy way to duplicate a working setup from one machine to
> the next
>
> I agree, but that's an issue with any complex software project
> with build dependencies surely? I work with Yocto Embedded Linux
> builds and I can tell you that it's even more difficult there, but
> they manage it extremely well.
>
> To address this seems to me a matter of understanding/documenting
> the dependencies and, where necessary, defining the require
> versions of those dependencies to ensure a build works in a
> controlled manner.
>
> I am making an assumption that the dependencies are all on Cygwin
> (are there any others?). If so then it should be relatively
> straightforward to define the version of Cygwin to use and/or pull
> down specific versioned packages.
>
> It was suggested to me that a setup script that pulled down
> appropriate dependencies would be useful, and I agree. I have been
> meaning to do something on that as I think it is straightforward
> but haven't yet had the time.
>
> If this was to be in place do you think there would be any other
> toolchain issues that would need consideration?
>
> >This was done with cygwin and was packaged by an additional
> installer step. The installer step was never very transparent so I
> can't comment on that.
>
> Somebody somewhere must have been building the Windows installer,
> at least up until 3.2.3. I believe it would be helpful if somebody
> could take time to explain how this works or just provide the
> automation to build the installer.
>
> When we execute the 'make install' step what results on Windows is
> missing key files such as 'mono.exe' and instead has Linux stubs
> such as 'mono' which causes problems. I would like to understand
> how the install
> step is supposed to work and to try to fix it instead of having to
> manually fix it up each time. Similarly I would like to be able to
> generate a 

Re: [Mono-dev] Building mono on Windows issues.

[Mladen Mihajlovic]

Hey Alex

There's a lot that you can do through their yml settings file. Download and
setup pretty much anything. Have a look in the root if the repo:
appveyor.yml.
On 17 Oct 2014 8:59 AM, "Alex J Lennon" 
wrote:

>  Hi Mladen,
>
> Sounds good to me. I've not encountered Appveyor before but it looks good.
> How do you get the Cygwin dependencies in there? Can it be assumed that
> what's happening in the Appveyor build is basically the same as on a
> standard Windows box?
>
> Cheers,
>
> Alex
>
> On 17/10/2014 08:53, Mladen Mihajlovic wrote:
>
> Hi Guys,
>
>  I took it upon myself to try and get a build up and running on Appveyor
> yesterday. Please have a look at https://github.com/mika76/mono and
> https://ci.appveyor.com/project/mmihajlovic/mono - so far the only thing
> I've edited is the appveyor.yml file and the actual a[[veyor settings.
>
>  At the moment it is installing cygwin and packages and running the
> visual studio msbuild file - which seems not to work - it fails with
> "compiler out of heap space" error.
>
>  If the msbuild does not pan out, the cygwin build can always be
> attempted as well.
>
>  If anybody wants to help, let me know and I'll make you a contributor on
> the repository.
>
>  Cheers,
> Mladen
>
> On 17 October 2014 08:46, Alex J Lennon 
> wrote:
>
>>  Hi Jonathan,
>>
>> Thanks for taking the time to provide the background.
>>
>> I understand/agree that facilitating development on Windows is a complex
>> task. I've seen some of the emails over time and can well imagine it's
>> complex and invasive to the existing build system. People start the work,
>> but I''ve not seen anything come out of it.
>>
>> If I take my scope as something much simpler, which is just to facilitate
>> building Mono on Windows from scratch, on a vanilla Windows platform,
>> perhaps defined as Windows 7/8.1 x32/x64 or whatever, then I think that's
>> much more achievable.
>>
>> I have been looking at this since 3.4.0 and the main issues I have
>> encountered were having the right dependencies, idiosyncracies of the build
>> tools, and issues with releases such as missing files/problems with Cygwin
>> headers.
>>
>> Perhaps very few of us are fit for purpose when it comes to actually
>> _contributing_ to Mono, but I can well understand that the first step an
>> OpenSource developer wants to make is to compile a project from source and
>> run up the results.
>>
>> I can also understand the frustration when you've spent a couple of days
>> on this and just keep encountering problems. People can then give up in
>> frustration.
>>
>> Even the longest journey begins with a single step and it strikes me that
>> it would be a useful thing to facilitate newbies building on Windows to get
>> them going on that journey, even if that's just by documenting issues they
>> will encounter.
>>
>> The emails I get from individuals show me that when they do have the
>> information they need to build Mono, and how to work around the gotchas,
>> then they can do it with relative ease.
>>
>> >- it's an amalgam of tools, which constantly update. There was never an
>> easy way to duplicate a working setup from one machine to the next
>>
>> I agree, but that's an issue with any complex software project with build
>> dependencies surely? I work with Yocto Embedded Linux builds and I can tell
>> you that it's even more difficult there, but they manage it extremely well.
>>
>> To address this seems to me a matter of understanding/documenting the
>> dependencies and, where necessary, defining the require versions of those
>> dependencies to ensure a build works in a controlled manner.
>>
>> I am making an assumption that the dependencies are all on Cygwin (are
>> there any others?). If so then it should be relatively straightforward to
>> define the version of Cygwin to use and/or pull down specific versioned
>> packages.
>>
>> It was suggested to me that a setup script that pulled down appropriate
>> dependencies would be useful, and I agree. I have been meaning to do
>> something on that as I think it is straightforward but haven't yet had the
>> time.
>>
>> If this was to be in place do you think there would be any other
>> toolchain issues that would need consideration?
>>
>> >This was done with cygwin and was packaged by an additional installer
>> step. The installer step was never very transparent so I can't comment on
>> that.
>>
>> Somebody somewhere must have been building the Windows installer, at
>> least up until 3.2.3. I believe it would be helpful if somebody could take
>> time to explain how this works or just provide the automation to build the
>> installer.
>>
>> When we execute the 'make install' step what results on Windows is
>> missing key files such as 'mono.exe' and instead has Linux stubs such as
>> 'mono' which causes problems. I would like to understand how the install
>> step is supposed to work and to try to fix it instead of having to
>> manually fix it up each time. Similarly I would like to be able t

Re: [Mono-dev] Building mono on Windows issues.

[Alex J Lennon]

On 17/10/2014 09:09, Mladen Mihajlovic wrote:
>
> Hey Alex
>
> There's a lot that you can do through their yml settings file.
> Download and setup pretty much anything. Have a look in the root if
> the repo: appveyor.yml.
>

Hi Mladen,

I like the look of Appveyor a lot. Thanks for that.

I've been getting going with the configuration file and in parallel
testing the 3.10.0 release builds locally under cygwin
as a sanity check and because each time I test a build with AppVeyor it
starts from a clean OS image (not a bad thing)
which means it takes a long time to clone the Mono repo before the build
starts.

Unfortunately the Windows build of release 3.10.0 fails locally:

libtool: compile:  i686-pc-mingw32-gcc -DHAVE_CONFIG_H -I. -I../..
-I../.. -I../../mono -I../../libgc/include -I../../eglib/src
-I../../eglib/src -DWINVER=0x0502 -D_WIN32_WINNT=0x0502
-D_WIN32_IE=0x0501 -D_UNICODE -DUNICODE -DWIN32_THREADS
-DFD_SETSIZE=1024 -g -O2 -fno-strict-aliasing -fwrapv
-Wdeclaration-after-statement -Wno-unused-but-set-variable -g -Wall
-Wunused -Wmissing-prototypes -Wmissing-declarations -Wstrict-prototypes
-Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wno-cast-qual
-Wwrite-strings -Wno-switch -Wno-switch-enum -Wno-unused-value
-mno-tls-direct-seg-refs -Werror-implicit-function-declaration -MT
sha1.lo -MD -MP -MF .deps/sha1.Tpo -c sha1.c  -DDLL_EXPORT -DPIC -o
.libs/sha1.o
In file included from sha1.c:20:0:
./sha1.h:25:1: error: expected '=', ',', ';', 'asm' or '__attribute__'
before 'void'
sha1.c:46:1: error: expected '=', ',', ';', 'asm' or '__attribute__'
before 'typedef'
sha1.c: In function 'SHA1Transform':
sha1.c:71:2: error: 'CHAR64LONG16' has no member named 'l'

Will have to have a think about what's wrong there.

Regards,

Alex

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Building mono on Windows issues.

[Alex J Lennon]

On 17/10/2014 16:07, Alex J Lennon wrote:
> On 17/10/2014 09:09, Mladen Mihajlovic wrote:
>> Hey Alex
>>
>> There's a lot that you can do through their yml settings file.
>> Download and setup pretty much anything. Have a look in the root if
>> the repo: appveyor.yml.
>>
> Hi Mladen,
>
> I like the look of Appveyor a lot. Thanks for that.
>
> I've been getting going with the configuration file and in parallel
> testing the 3.10.0 release builds locally under cygwin
> as a sanity check and because each time I test a build with AppVeyor it
> starts from a clean OS image (not a bad thing)
> which means it takes a long time to clone the Mono repo before the build
> starts.
>
> Unfortunately the Windows build of release 3.10.0 fails locally:
>
> libtool: compile:  i686-pc-mingw32-gcc -DHAVE_CONFIG_H -I. -I../..
> -I../.. -I../../mono -I../../libgc/include -I../../eglib/src
> -I../../eglib/src -DWINVER=0x0502 -D_WIN32_WINNT=0x0502
> -D_WIN32_IE=0x0501 -D_UNICODE -DUNICODE -DWIN32_THREADS
> -DFD_SETSIZE=1024 -g -O2 -fno-strict-aliasing -fwrapv
> -Wdeclaration-after-statement -Wno-unused-but-set-variable -g -Wall
> -Wunused -Wmissing-prototypes -Wmissing-declarations -Wstrict-prototypes
> -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wno-cast-qual
> -Wwrite-strings -Wno-switch -Wno-switch-enum -Wno-unused-value
> -mno-tls-direct-seg-refs -Werror-implicit-function-declaration -MT
> sha1.lo -MD -MP -MF .deps/sha1.Tpo -c sha1.c  -DDLL_EXPORT -DPIC -o
> .libs/sha1.o
> In file included from sha1.c:20:0:
> ./sha1.h:25:1: error: expected '=', ',', ';', 'asm' or '__attribute__'
> before 'void'
> sha1.c:46:1: error: expected '=', ',', ';', 'asm' or '__attribute__'
> before 'typedef'
> sha1.c: In function 'SHA1Transform':
> sha1.c:71:2: error: 'CHAR64LONG16' has no member named 'l'
>

It looks like perhaps the mono-3.10.0-branch needs Vincent's commit
cherry-picking

"Use G_BEGIN_DECLS instead of __BEGIN_DECLS."

https://github.com/mono/mono/commit/3c920be3e534c8c2d51695f16055e84936fe761e

How would we go about flagging that up with somebody to ask them to look
into it?

Regards,

Alex

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Building mono on Windows issues.

[Alex J Lennon]

Hi Mladen,

On 17/10/2014 16:25, Alex J Lennon wrote:
> On 17/10/2014 16:07, Alex J Lennon wrote:
>> On 17/10/2014 09:09, Mladen Mihajlovic wrote:
>>> Hey Alex
>>>
>>> There's a lot that you can do through their yml settings file.
>>> Download and setup pretty much anything. Have a look in the root if
>>> the repo: appveyor.yml.
>>>
>> Hi Mladen,
>>
>> I like the look of Appveyor a lot. Thanks for that.
>>
>> I've been getting going with the configuration file and in parallel
>> testing the 3.10.0 release builds locally under cygwin
>> as a sanity check and because each time I test a build with AppVeyor it
>> starts from a clean OS image (not a bad thing)
>> which means it takes a long time to clone the Mono repo before the build
>> starts.
>>
>> Unfortunately the Windows build of release 3.10.0 fails locally:
>>
>> libtool: compile:  i686-pc-mingw32-gcc -DHAVE_CONFIG_H -I. -I../..
>> -I../.. -I../../mono -I../../libgc/include -I../../eglib/src
>> -I../../eglib/src -DWINVER=0x0502 -D_WIN32_WINNT=0x0502
>> -D_WIN32_IE=0x0501 -D_UNICODE -DUNICODE -DWIN32_THREADS
>> -DFD_SETSIZE=1024 -g -O2 -fno-strict-aliasing -fwrapv
>> -Wdeclaration-after-statement -Wno-unused-but-set-variable -g -Wall
>> -Wunused -Wmissing-prototypes -Wmissing-declarations -Wstrict-prototypes
>> -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wno-cast-qual
>> -Wwrite-strings -Wno-switch -Wno-switch-enum -Wno-unused-value
>> -mno-tls-direct-seg-refs -Werror-implicit-function-declaration -MT
>> sha1.lo -MD -MP -MF .deps/sha1.Tpo -c sha1.c  -DDLL_EXPORT -DPIC -o
>> .libs/sha1.o
>> In file included from sha1.c:20:0:
>> ./sha1.h:25:1: error: expected '=', ',', ';', 'asm' or '__attribute__'
>> before 'void'
>> sha1.c:46:1: error: expected '=', ',', ';', 'asm' or '__attribute__'
>> before 'typedef'
>> sha1.c: In function 'SHA1Transform':
>> sha1.c:71:2: error: 'CHAR64LONG16' has no member named 'l'
>>
> It looks like perhaps the mono-3.10.0-branch needs Vincent's commit
> cherry-picking
>
> "Use G_BEGIN_DECLS instead of __BEGIN_DECLS."
>
> https://github.com/mono/mono/commit/3c920be3e534c8c2d51695f16055e84936fe761e
>
> How would we go about flagging that up with somebody to ask them to look
> into it?
>
> Regards,
>
> Alex

Well I've made a certain amount of progress with Appveyor, and I like it, but 
I'm going around in circles with a strange problem.

When I get to the end of the autoconf stage under Cygwin it kicks off the 
configure script and early on in that I get this every time:

Skipping configure process.
Done running eglib/autogen.sh ...
Running ./configure --enable-maintainer-mode --enable-compile-warnings 
--prefix=/cygdrive/c/monoinstall --with-preview=yes ...
./configure: line 571: 0: Bad file descriptor

I've tried a range of different permutations but the error is always the same.

The Appveyor VM image is locked down from what I can see so I can't get in 
there to work out why it is failing, although it
seems to be on this line in the configure script

test -n "$DJDIR" || exec 7<&0  NUL
error: unknown (or unsupported) file type `x'
error: unknown (or unsupported) file type `x'
error: unknown (or unsupported) file type `x'

Any thoughts?

Regards,

Alex



___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

[Mono-dev] Building Mono on Windows is extremely slow

[Kornél Pál]

Hi,

Building Mono on Windows is much slower than building it on Linux for
example. The problem seems to be that our scripts use a lot of processes.
Processes on Linux are lightweight but are heavyweight on Windows that
results in delays because of process construction and destruction. Can
anything be done to speed up build?

Kornél

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Building Mono on Windows is extremely slow

[Jonathan Pryor]

On Wed, 2005-10-05 at 13:32 +0200, Kornél Pál wrote:
> Building Mono on Windows is much slower than building it on Linux for
> example. The problem seems to be that our scripts use a lot of processes.
> Processes on Linux are lightweight but are heavyweight on Windows that
> results in delays because of process construction and destruction. Can
> anything be done to speed up build?

Not without using something other than automake/autoconf, since it's the
`configure' script that's responsible for most of that process
generation (creating & compiling test programs to check for libraries
and functions, checking for the presence of programs, checking for...).

Alternatively, create a Makefile (or similar) setup explicitly for Win32
users, so they don't have to run configure (if you want to assume that
all Win32 systems are alike).  Of course, then you'd have to deal with
synchronization issues...

 - Jon


___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Building Mono on Windows is extremely slow

[Wade Berrier]

Could also cross compile from linux :)

Right now ./configure treats mingw and cygwin the same.  You'd have to
make some adjustments for the mingw target, but the compile times would
definitely be faster.

Wade


On Thu, 2005-10-06 at 06:52 -0400, Jonathan Pryor wrote:
> On Wed, 2005-10-05 at 13:32 +0200, Kornél Pál wrote:
> > Building Mono on Windows is much slower than building it on Linux for
> > example. The problem seems to be that our scripts use a lot of processes.
> > Processes on Linux are lightweight but are heavyweight on Windows that
> > results in delays because of process construction and destruction. Can
> > anything be done to speed up build?
> 
> Not without using something other than automake/autoconf, since it's the
> `configure' script that's responsible for most of that process
> generation (creating & compiling test programs to check for libraries
> and functions, checking for the presence of programs, checking for...).
> 
> Alternatively, create a Makefile (or similar) setup explicitly for Win32
> users, so they don't have to run configure (if you want to assume that
> all Win32 systems are alike).  Of course, then you'd have to deal with
> synchronization issues...
> 
>  - Jon
> 
> 
> ___
> Mono-devel-list mailing list
> Mono-devel-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
> 

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

[Mono-dev] Building Mono on Windows - And Having a Windows Installer again

[Daniel Morgan]

I see the latest version of Mono's Windows installer is 3.2.3.  Can this be 
used to build the latest from git?
I see a link for binaries for 3.4.0, but they are not official binaries.

I am going to try build Mono on Windows using Cygwin.  Not sure how web the 
visual studio stuff works.

If I am successful, I will put up somewhere an un-official Windows Installer 
for Mono so others can help.
The nice thing about the Combined Mono and Gtk# Installer for Windows is that 
you have something out-of-the box you can create a GUI app with Mono.   Very 
nice to have an C# gui app that can run on Windows and Linux.

Also, what is the best Linux distro to build mono?  OpenSUSE?  Debian, Ubuntu?  
It has been awhile for me.  Not starting a flame war here - just wanting the 
easiest route to get the dependencies on linux  in order to build the latest 
mono from git.

And I want to play with MonoDevelop too, but Mono comes first.


___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Building Mono on Windows - And Having a Windows Installer again

[Edward Ned Harvey (mono)]

> From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list-
> boun...@lists.ximian.com] On Behalf Of Daniel Morgan
> 
> I see the latest version of Mono's Windows installer is 3.2.3.  Can this be 
> used
> to build the latest from git?
> 
> I see a link for binaries for 3.4.0, but they are not official binaries.
> 
> I am going to try build Mono on Windows using Cygwin.  Not sure how web
> the visual studio stuff works.

Search this list for Appveyor.  I know Alex Lennon was putting some effort in, 
and I think got to the point of having a reliable automated build process - but 
check with folks to be sure (I haven't followed very closely and I could be 
wrong).  At some point, Miguel pulled Duncan Mak into the conversation, so I 
would guess maybe Duncan is involved with distributing windows builds...  All 
of this occurred within the last ~ 1 month or so.


> Also, what is the best Linux distro to build mono?  OpenSUSE?  Debian,
> Ubuntu?  It has been awhile for me.  Not starting a flame war here - just
> wanting the easiest route to get the dependencies on linux  in order to build
> the latest mono from git.

On basically any system I've seen so far, building is easy.  The basic process 
of "./configure && make && make install" usually works.  If it doesn't, then 
add "make get-monolite-latest" before "make EXTERNAL_MCS=..."  as below...

On every redhat-based or debian-based (or even mac) system I've ever used, one 
of these two variants has always worked.

OSX
export BUILDDIR=/Users/whatever/Projects/mono-build
export NUMPROC=3 ; time ( test -d $BUILDDIR && rm -rf $BUILDDIR ; mkdir -p 
$BUILDDIR ; ./autogen.sh --prefix=$BUILDDIR --disable-bcl-opt --enable-nls=no 
&& make -j $NUMPROC && make install && echo "" && echo "Done" && echo "")

Ubuntu 14.04
export BUILDDIR=/home/whatever/Projects/mono-build
export NUMPROC=3 ; time ( test -d $BUILDDIR && rm -rf $BUILDDIR ; mkdir -p 
$BUILDDIR ; ./autogen.sh --prefix=$BUILDDIR --disable-bcl-opt --enable-nls=no 
&& make get-monolite-latest && make -j $NUMPROC 
EXTERNAL_MCS="${PWD}/mcs/class/lib/monolite/gmcs.exe" && make install && echo 
"" && echo "Done" && echo "")


> And I want to play with MonoDevelop too, but Mono comes first.

Building monodevelop is more difficult.  I've never succeeded - but I never 
spent a boat load of time on it either.  You can install MonoDevelop on the 
mac, no problem (they distribute a pre-built binary).  Also, the latest ubuntu 
includes a recent build of monodevelop.  I personally use VS on windows, XS on 
mac, and MD on ubuntu 14.04 desktop x86_64.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Building Mono on Windows - And Having a Windows Installer again

[Alex J Lennon]

Hi Daniel,

On 30/11/2014 02:13, Edward Ned Harvey (mono) wrote:
>> From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list-
>> boun...@lists.ximian.com] On Behalf Of Daniel Morgan
>>
>> I see the latest version of Mono's Windows installer is 3.2.3.  Can this be 
>> used
>> to build the latest from git?
>>
>> I see a link for binaries for 3.4.0, but they are not official binaries.
>>
>> I am going to try build Mono on Windows using Cygwin.  Not sure how web
>> the visual studio stuff works.
> Search this list for Appveyor.  I know Alex Lennon was putting some effort 
> in, and I think got to the point of having a reliable automated build process 
> - but check with folks to be sure (I haven't followed very closely and I 
> could be wrong).  At some point, Miguel pulled Duncan Mak into the 
> conversation, so I would guess maybe Duncan is involved with distributing 
> windows builds...  All of this occurred within the last ~ 1 month or so.
>

As Edward says, I did put a bit of time into this and we do have what I
think is a reliable automated build process on the Windows platform,
although as ever there are improvements that can be made,

Stepping back for a second there's a couple of documents that I've been
maintaining on building Mono under Windows with Cygwin (prior to being
introduced to Appveyor CI)

This covers 3.4.0 - 3.6.0,
http://www.codeproject.com/Articles/769292/How-to-build-Mono-on-Windows

And this covers 3.8.0+
http://www.codeproject.com/Articles/769292/How-to-build-Mono-on-Windows

It gets you to the point you can just about use Mono but there are some
remaining issues I have yet to address,

e.g.

- understanding how the Mono installer works
- dealing with hard coded library references in the build (I think the
installer may do some of this)
- ensuring that Windows batch files for e.g. mcs, mono, xbuild are
correcly created (Again I think the installer may do some of this)

...

Further to that I then created a build script for the Appveyor build
platform, based on work and suggestions from Mladen Mihajlovic, which is
currently automatically building Mono on commits to the repo

You can see the build history here:
https://ci.appveyor.com/project/ajlennon/mono-817

The output "artifact" from any of these builds is currently a set of
Mono binaries which you _should_ be able to download and use straight
away (would love some feedback on any issues here)

e.g. https://ci.appveyor.com/project/ajlennon/mono-817/build/artifacts

You should also be able to take the script I created and use this to
build your own build of Mono, independently of the instruction documents
I reference above. In particular there's a useful line there that
automates installation of needed Cygwin packages.

See here: https://github.com/mono/mono/blob/master/appveyor.yml
(build_script section)

What I'd like to do next is to modify this script to take the bones of
the Windows installer and generate an output artifact which was an MSI
installer.

Unfortunately this is not trivial (to me at least!), and also requires
pulling in some GTK# dependencies and so forth. I want to progress this
but have not yet had time due to work commitments.

Also, and perhaps more importantly the Cygwin build may all become
somewhat deprecated as Jo Shields appears to be doing some excellent
work to make Mono build under MSVC.

Once this is achievable, to my mind it will be a vastly superior way to
build Mono, instead of the 2 hour+ Cygwin build with all the faff.

>> Also, what is the best Linux distro to build mono?  OpenSUSE?  Debian,
>> Ubuntu?  It has been awhile for me.  Not starting a flame war here - just
>> wanting the easiest route to get the dependencies on linux  in order to build
>> the latest mono from git.
> On basically any system I've seen so far, building is easy.  The basic 
> process of "./configure && make && make install" usually works.  If it 
> doesn't, then add "make get-monolite-latest" before "make EXTERNAL_MCS=..."  
> as below...
>
> On every redhat-based or debian-based (or even mac) system I've ever used, 
> one of these two variants has always worked.
>
> OSX
> export BUILDDIR=/Users/whatever/Projects/mono-build
> export NUMPROC=3 ; time ( test -d $BUILDDIR && rm -rf $BUILDDIR ; mkdir -p 
> $BUILDDIR ; ./autogen.sh --prefix=$BUILDDIR --disable-bcl-opt --enable-nls=no 
> && make -j $NUMPROC && make install && echo "" && echo "Done" && echo "")
>
> Ubuntu 14.04
> export BUILDDIR=/home/whatever/Projects/mono-build
> export NUMPROC=3 ; time ( test -d $BUILDDIR && rm -rf $BUILDDIR ; mkdir -p 
> $BUILDDIR ; ./autogen.sh --prefix=$BUILDDIR --disable-bcl-opt --enable-nls=no 
> && make get-monolite-latest && make -j $NUMPROC 
> EXTERNAL_MCS="${PWD}/mcs/class/lib/monolite/gmcs.exe" && make install && echo 
> "" && echo "Done" && echo "")
>

Possibly a bit off-topic but fwiw I maintain and use Yocto for Embedded
Linux with meta-mono layer. The recipes for building Mono are here,

http://git.yoctoproj

Re: [Mono-dev] Building Mono on Windows - And Having a Windows Installer again

[Alexander Köplinger]

Hey Alex,
 
Jo Shields is currently working on revamping the Windows Installer in his repo: 
https://github.com/directhex/newbuilder
I contributed the WiX setup files for creating an MSI installer. Jo sent me 
this link for a preview build (the usual caveats apply): 
https://drive.google.com/file/d/0Bz6-k9ELOQf3YTE1RHV3Y0dNaFU/view
 
Btw. while developing the WiX setup I used the binaries from your AppVeyor 
build, it all worked fine :)
 
Can you maybe also make changes to 
http://www.mono-project.com/docs/compiling-mono/windows/ (just click the "edit 
page on github" link), so it reflects what is necessary right now to build Mono 
on Windows? I think that page is pretty outdated right now.
 
-- Alex
 
 
> Date: Fri, 28 Nov 2014 14:29:29 +0100
> From: ajlen...@dynamicdevices.co.uk
> To: monodanm...@yahoo.com
> CC: mono-devel-list@lists.ximian.com
> Subject: Re: [Mono-dev] Building Mono on Windows - And Having a Windows   
> Installer again
> 
> Hi Daniel,
> 
> On 30/11/2014 02:13, Edward Ned Harvey (mono) wrote:
> >> From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list-
> >> boun...@lists.ximian.com] On Behalf Of Daniel Morgan
> >>
> >> I see the latest version of Mono's Windows installer is 3.2.3.  Can this 
> >> be used
> >> to build the latest from git?
> >>
> >> I see a link for binaries for 3.4.0, but they are not official binaries.
> >>
> >> I am going to try build Mono on Windows using Cygwin.  Not sure how web
> >> the visual studio stuff works.
> > Search this list for Appveyor.  I know Alex Lennon was putting some effort 
> > in, and I think got to the point of having a reliable automated build 
> > process - but check with folks to be sure (I haven't followed very closely 
> > and I could be wrong).  At some point, Miguel pulled Duncan Mak into the 
> > conversation, so I would guess maybe Duncan is involved with distributing 
> > windows builds...  All of this occurred within the last ~ 1 month or so.
> >
> 
> As Edward says, I did put a bit of time into this and we do have what I
> think is a reliable automated build process on the Windows platform,
> although as ever there are improvements that can be made,
> 
> Stepping back for a second there's a couple of documents that I've been
> maintaining on building Mono under Windows with Cygwin (prior to being
> introduced to Appveyor CI)
> 
> This covers 3.4.0 - 3.6.0,
> http://www.codeproject.com/Articles/769292/How-to-build-Mono-on-Windows
> 
> And this covers 3.8.0+
> http://www.codeproject.com/Articles/769292/How-to-build-Mono-on-Windows
> 
> It gets you to the point you can just about use Mono but there are some
> remaining issues I have yet to address,
> 
> e.g.
> 
> - understanding how the Mono installer works
> - dealing with hard coded library references in the build (I think the
> installer may do some of this)
> - ensuring that Windows batch files for e.g. mcs, mono, xbuild are
> correcly created (Again I think the installer may do some of this)
> 
> ...
> 
> Further to that I then created a build script for the Appveyor build
> platform, based on work and suggestions from Mladen Mihajlovic, which is
> currently automatically building Mono on commits to the repo
> 
> You can see the build history here:
> https://ci.appveyor.com/project/ajlennon/mono-817
> 
> The output "artifact" from any of these builds is currently a set of
> Mono binaries which you _should_ be able to download and use straight
> away (would love some feedback on any issues here)
> 
> e.g. https://ci.appveyor.com/project/ajlennon/mono-817/build/artifacts
> 
> You should also be able to take the script I created and use this to
> build your own build of Mono, independently of the instruction documents
> I reference above. In particular there's a useful line there that
> automates installation of needed Cygwin packages.
> 
> See here: https://github.com/mono/mono/blob/master/appveyor.yml
> (build_script section)
> 
> What I'd like to do next is to modify this script to take the bones of
> the Windows installer and generate an output artifact which was an MSI
> installer.
> 
> Unfortunately this is not trivial (to me at least!), and also requires
> pulling in some GTK# dependencies and so forth. I want to progress this
> but have not yet had time due to work commitments.
> 
> Also, and perhaps more importantly the Cygwin build may all become
> somewhat deprecated as Jo Shields appears to be doing some excellent
> work to make Mono build under MSVC.
> 
> Once this is achievable, to my mind it will be a vastly superior way to
> build Mon

Re: [Mono-dev] Building Mono on Windows - And Having a Windows Installer again

[Alex J Lennon]

Hi Alex

On 30/11/2014 15:09, Alexander Köplinger wrote:
> Hey Alex,
>  
> Jo Shields is currently working on revamping the Windows Installer in
> his repo: https://github.com/directhex/newbuilder
> I contributed the WiX setup files for creating an MSI installer. Jo
> sent me this link for a preview build (the usual caveats apply):
> https://drive.google.com/file/d/0Bz6-k9ELOQf3YTE1RHV3Y0dNaFU/view

That sounds great. Maybe I will try to bolt that onto the Appveyor
script then. I'd love for the CI builds to just result in an MSI anybody
can grab and use easily.

>  
> Btw. while developing the WiX setup I used the binaries from your
> AppVeyor build, it all worked fine :)

Really good to hear that thanks Alex :)

>  
> Can you maybe also make changes to
> http://www.mono-project.com/docs/compiling-mono/windows/ (just click
> the "edit page on github" link), so it reflects what is necessary
> right now to build Mono on Windows? I think that page is pretty
> outdated right now.


Yes it's definitely on my TODO list. I was hoping to grab the content of
my CodeProject article and massage it into that page. Things have just
been so hectic here I haven't had the chance yet :)

Cheers,

Alex

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Building Mono on Windows - And Having a Windows Installer again

[Daniel Morgan]

I am glad to see others trying to build a Mono for Windows Installer.  

Removing un-needed static libraries could make the installer much smaller.  
Unless, you are doing embedded. Well, if you are doing embedded, you are most 
likely building mono yourself anyways.   Mono's static library is huge.    
Usually on Windows, these static libraries would have a .lib extension, but 
since these libraries were originally built using gcc, they probably have a .a 
or .dll.a extension.  If you include glib/gtk 2.0, there are static libraries 
there we do not need for gtk+ libraries.   However, keep those static libraries 
which can help re-building mono from git.

We could also save space in the installer if we only include the latest 4.5 
profile.  Another words, remove 2.0, 3.5, and 4.0..
Just my 2 cents.

  From: Alex J Lennon 
 To: Alexander Köplinger  
Cc: "mono-devel-list@lists.ximian.com"  
 Sent: Sunday, November 30, 2014 9:28 AM
 Subject: Re: [Mono-dev] Building Mono on Windows - And Having a Windows 
Installer again
   
 Hi Alex
 
 On 30/11/2014 15:09, Alexander Köplinger wrote:
  
 #yiv6734285822 #yiv6734285822 --.yiv6734285822hmmessage 
P{margin:0px;padding:0px;}#yiv6734285822 
body.yiv6734285822hmmessage{font-size:12pt;font-family:Calibri;}#yiv6734285822  
Hey Alex,
  
 Jo Shields is currently working on revamping the Windows Installer in his 
repo: https://github.com/directhex/newbuilder
 I contributed the WiX setup files for creating an MSI installer. Jo sent me 
this link for a preview build (the usual caveats apply): 
https://drive.google.com/file/d/0Bz6-k9ELOQf3YTE1RHV3Y0dNaFU/view
  
 
 That sounds great. Maybe I will try to bolt that onto the Appveyor script 
then. I'd love for the CI builds to just result in an MSI anybody can grab and 
use easily.
 
 
  
 Btw. while developing the WiX setup I used the binaries from your AppVeyor 
build, it all worked fine :)
  
 
 Really good to hear that thanks Alex :) 
 
 
  
 Can you maybe also make changes to 
http://www.mono-project.com/docs/compiling-mono/windows/ (just click the "edit 
page on github" link), so it reflects what is necessary right now to build Mono 
on Windows? I think that page is pretty outdated right now.
  
 
 
 Yes it's definitely on my TODO list. I was hoping to grab the content of my 
CodeProject article and massage it into that page. Things have just been so 
hectic here I haven't had the chance yet :)


 
 Cheers,
 
 Alex
 
 
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list


  ___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Building Mono on Windows - And Having a Windows Installer again

[Edward Ned Harvey (mono)]

> From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list-
> boun...@lists.ximian.com] On Behalf Of Daniel Morgan
> 
> We could also save space in the installer if we only include the latest 4.5
> profile.  Another words, remove 2.0, 3.5, and 4.0..

Wed Oct 22, 2014:  "Heads up: Elimination of the 2.0 and 4.0 profiles"
http://lists.ximian.com/pipermail/mono-devel-list/2014-October/042145.html

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Building Mono on Windows - And Having a Windows Installer again (Mono-devel-list Digest, Vol 115, Issue 58)

[Jo Shields]

On 30/11/14 14:09, Alexander K?plinger wrote:
> Hey Alex,
>  
> Jo Shields is currently working on revamping the Windows Installer in his 
> repo: https://github.com/directhex/newbuilder
> I contributed the WiX setup files for creating an MSI installer. Jo sent me 
> this link for a preview build (the usual caveats apply): 
> https://drive.google.com/file/d/0Bz6-k9ELOQf3YTE1RHV3Y0dNaFU/view

IN THEORY, the current state of things is:

Check out newbuilder.git

Run ./mono-MDK-windows

This will download Mono from git, a compiled Mono MDK (used as the
"source" for a lot of the non-runtime components), and GTK# for Windows
(ditto). I didn't feel like learning how to build GTK# and F# and
IronPython and Boo and IronRuby on Windows.

However, this will likely break because I make assumptions relating to
the upcoming 3.12 release (my target right now), and master differs in
important ways (i.e. the 4.5-only thing). It also assumes VS2013 is
installed, doesn't massage the Cygwin environment the way the Appveyor
config does, needs an older Mono (for bootstrapping) in $PATH, and so on.

Step 1 is getting it good enough to do everything right in my Windows
VM. Then I can subtree it into the regular github/mono/release.git repo,
and people are encouraged to send pull requests to fix
not-running-on-Jo's-laptop assumptions. FWIW the existing Windows build
system in github.com/mono/release.git/windows-installer/ has a LOT of
running-on-a-former-employee's-desktop assumptions, so at least things
aren't moving backwards per se.

The current status with a primed 3.12 build (`defs/mono download
mono-3.12.0-branch` and `defs/managed-components download
http://path-to-3.12-MDK` where I don't think those MDK builds are public
right now) *should* be fully functional. I did a lot of work on
Thursday/Friday to integrate all the junk we ship with Mac (Boo, IPy,
IR, F#) but haven't tested all those changes as I ran out of time.
Monday is testing/fixing, and posting a "this should work, honest"
preview rather than a "this might partially work" preview.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Building Mono on Windows - And Having a Windows Installer again (Mono-devel-list Digest, Vol 115, Issue 57)

[Jo Shields]

On 30/11/14 01:13, Edward Ned Harvey (mono) wrote:
>> From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list-
>> boun...@lists.ximian.com] On Behalf Of Daniel Morgan
>>
>> I see the latest version of Mono's Windows installer is 3.2.3.? Can this be 
>> used
>> to build the latest from git?
>>
>> I see a link for binaries for 3.4.0, but they are not official binaries.
>>
>> I am going to try build Mono on Windows using Cygwin.? Not sure how web
>> the visual studio stuff works.
> 
> Search this list for Appveyor.  I know Alex Lennon was putting some effort 
> in, and I think got to the point of having a reliable automated build process 
> - but check with folks to be sure (I haven't followed very closely and I 
> could be wrong).  At some point, Miguel pulled Duncan Mak into the 
> conversation, so I would guess maybe Duncan is involved with distributing 
> windows builds...  All of this occurred within the last ~ 1 month or so.
> 
> 
>> Also, what is the best Linux distro to build mono?? OpenSUSE?? Debian,
>> Ubuntu?? It has been awhile for me.? Not starting a flame war here - just
>> wanting the easiest route to get the dependencies on linux? in order to build
>> the latest mono from git.
> 
> On basically any system I've seen so far, building is easy.  The basic 
> process of "./configure && make && make install" usually works.  If it 
> doesn't, then add "make get-monolite-latest" before "make EXTERNAL_MCS=..."  
> as below...
> 
> On every redhat-based or debian-based (or even mac) system I've ever used, 
> one of these two variants has always worked.
> 
> OSX
> export BUILDDIR=/Users/whatever/Projects/mono-build
> export NUMPROC=3 ; time ( test -d $BUILDDIR && rm -rf $BUILDDIR ; mkdir -p 
> $BUILDDIR ; ./autogen.sh --prefix=$BUILDDIR --disable-bcl-opt --enable-nls=no 
> && make -j $NUMPROC && make install && echo "" && echo "Done" && echo "")
> 
> Ubuntu 14.04
> export BUILDDIR=/home/whatever/Projects/mono-build
> export NUMPROC=3 ; time ( test -d $BUILDDIR && rm -rf $BUILDDIR ; mkdir -p 
> $BUILDDIR ; ./autogen.sh --prefix=$BUILDDIR --disable-bcl-opt --enable-nls=no 
> && make get-monolite-latest && make -j $NUMPROC 
> EXTERNAL_MCS="${PWD}/mcs/class/lib/monolite/gmcs.exe" && make install && echo 
> "" && echo "Done" && echo "")
> 
> 
>> And I want to play with MonoDevelop too, but Mono comes first.
> 
> Building monodevelop is more difficult.  I've never succeeded - but I never 
> spent a boat load of time on it either.  You can install MonoDevelop on the 
> mac, no problem (they distribute a pre-built binary).  Also, the latest 
> ubuntu includes a recent build of monodevelop.  I personally use VS on 
> windows, XS on mac, and MD on ubuntu 14.04 desktop x86_64.

If you just want access to the latest crack, remember that every git
commit of Mono and of MonoDevelop gets turned into RPM and DEB packages,
and can be downloaded from jenkins.mono-project.com - the
mono-snapshot-latest and monodevelop-snapshot-latest packages will keep
you up to date with master.

http://www.mono-project.com/docs/getting-started/install/linux/ci-packages/

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list