USES=python does not provide /usr/local/bin/python. There are countless places in the build system that call "python" instead of "python2.7" (not shebangs) and I couldn't possibly patch them all just to get this to build. What alternative do we have?

In D15780#333772, @feld wrote:

USES=python does not provide /usr/local/bin/python. There are countless places in the build system that call "python" instead of "python2.7" (not shebangs) and I couldn't possibly patch them all just to get this to build. What alternative do we have?

BINARY_ALIAS=  python=${PYTHON_CMD}

5.17. Use BINARY_ALIAS to Rename Commands Instead of Patching the Build

In D15780#333783, @mat wrote:

In D15780#333772, @feld wrote:

USES=python does not provide /usr/local/bin/python. There are countless places in the build system that call "python" instead of "python2.7" (not shebangs) and I couldn't possibly patch them all just to get this to build. What alternative do we have?

BINARY_ALIAS=  python=${PYTHON_CMD}

5.17. Use BINARY_ALIAS to Rename Commands Instead of Patching the Build

Thank you for showing me this! I did not realize we gained this capability.

I'm seeing a few issues with my mono apps I am testing. After speaking with a developer he strongly suggests we follow the "very stable" release which is what they ship with Visual Studio for Mac. That would be slightly older version 5.10.1.47. I will see if I can get it building and if it passes my requirements I will adjust this review to target that release instead. I'd really like us to have a very stable release of mono to rely on. If we need a separate port for people who want the absolute latest version we could do it.

In D15780#333902, @feld wrote:

Disable USES=display by default. Only used for tests, can hide behind X11 option for now.

I think there is a USES=display:test that should be used in conjunction with X11

In D15780#333908, @dbn wrote:

In D15780#333902, @feld wrote:

Disable USES=display by default. Only used for tests, can hide behind X11 option for now.

I think there is a USES=display:test that should be used in conjunction with X11

I'm currently using

X11_USES=       display

for this. I think the framework is bugged here because display:test causes it to build the X11 components always even when you're not running "make test".

In D15780#333909, @dbn wrote:

I have been working on an update and I think some of the changes in that patch [1] will be useful.

I will take any improvements you have available! :)

Given that your tests are all passing I suggest we go with your version.

I have not confirmed tests are all passing. This may be a misunderstanding.

I do however see the latest version is 5.10.1.57 (but mono versioning just confuses me).

After conferring with some others, it was suggested that for best reliability we should track the releases used by Visual Basic found here http://www.mono-project.com/download/vs/ as they get more thorough testing.

Some useful changes in my patch [1] that I think will be of use include:

• Updating mono-basic: the bootstrap compiler does not run with newer versions of mono

I'll go with your gut instinct here.

• Patching gtk-sharp30: changes in the mono profiler API require this change

Ahh, good to know

• Dropping GitHub: GitHub was originally used to get full test suite coverage, however acceptance tests were never working, and I see the source tarball now includes many (all?) tests. It just makes updating a lot easier.

Simple, agreed.

• Add ODBC dependency: required by System.Data

Sounds good as well.

I was surprised to see that we can use the linux version of monolite. My understanding is that there is specific OS code that gets included per "verb". I had also added freebsd as a "verb", but you say it works with "linux" for you... I'll track down some freebsd specific code and see if it really does differ to linux (e.g. kqueue/kevent).

Even the AIX platform uses the linux version of monolite. I've been told it has no specific OS code, so this confuses me as well.

I'll happily run an exp-run for you. The exp-run for patch [1] is at [2] (note it was a cumulative exp-run, all other ports depending on mono had succeeded in previous builds).

Please and thanks! Let's finish polishing this and get the exp-run completed.

If there is anything else I can do to help, please let me know.

[1] https://people.freebsd.org/~dbn/mono.diff
[2] http://dbn.westeurope.cloudapp.azure.com/mono.html

The analyzed output of "make tests" seems to indicate we are passing them all. They reported results look like this:

Results: total tests: 22, all pass

The lines say "all pass" with varying numbers of tests.

1. Exp-run started: http://dbn.westeurope.cloudapp.azure.com/mono.html
   • Known issues are games/openar and devel/nant
   • games/openar: periodic failures (likely build concurrency issue)
   • devel/nant: does not build on FreeBSD-12 on a FreeBSD-11 kernel
2. I had difficulty applying your patch regarding the eglib patch files (there is a duplicate entry for the patches).
3. I did find some OS specific code in System.Data [a], although the build system only included a Unix generic file [b]. So I think we are good to go without changing the build system.
4. This update fixes PR 211367

a) external/corefx/src/Common/src/Interop/
b) mcs/class/System.Data/linux_net_4_x_System.Data.dll.sources

For the record, I found a bug related to HTTP headers with my apps that I was able to reproduce with Mono 5.10, so my apps that were "failing" with 5.12 might not have been a 5.12 issue but something else in the 5.x train that caused it. I'd rather we push this out the barn door before 2018Q3 and then we can look at 5.12 in ports again. It should be much easier to upgrade now.

Exp-run done and a few new failures (see [1]). I think you need to restore the following patches:

• patch-mcs_tools_xbuild_data_12.0_Microsoft.CSharp.targets
• patch-mcs_tools_xbuild_data_14.0_Microsoft.CSharp.targets

It would help with my exp-run if you bump PORTREVISION. I can then do an incremental exp-run, which will save ~4 hours in turnaround time.

[1] http://dbn.westeurope.cloudapp.azure.com/mono.html

In D15780#334798, @feld wrote:

For the record, I found a bug related to HTTP headers with my apps that I was able to reproduce with Mono 5.10, so my apps that were "failing" with 5.12 might not have been a 5.12 issue but something else in the 5.x train that caused it. I'd rather we push this out the barn door before 2018Q3 and then we can look at 5.12 in ports again. It should be much easier to upgrade now.

I see mono has 4 "channels": nightly, preview, stable and visual studio. This release, as you have indicated, is the latest on the visual studio channel. I agree that we proceed with this release and that we stick with the visual studio (hopefully less updates and more stability).

! In D15780#334798, @feld wrote:
For the record, I found a bug related to HTTP headers with my apps that I was able to reproduce with Mono 5.10, so my apps that were "failing" with 5.12 might not have been a 5.12 issue but something else in the 5.x train that caused it. I'd rather we push this out the barn door before 2018Q3 and then we can look at 5.12 in ports again. It should be much easier to upgrade now.

To actually address the HTTP headers issue, there is a known issue with FreeBSD and a newer implementation of System.Net.Http in dotnet core. Since mono is now sharing a lot of code from dotnet core this may have come over as well. Worth investigating a bit...

See this [1] issue on GitHub, specifically search for DOTNET_SYSTEM_NET_HTTP_USESOCKETSHTTPHANDLER. I think the exact issue was discussed in another issue but I cannot find that one.

[1] https://github.com/dotnet/coreclr/issues/18067

Side note, you may want to read Chapter 15. Order of Variables in Port Makefiles to reorder the Makefile.