wxmac: disable monolithic build; erlang: build with wx support

[adamv]

No description provided.

[adamv]

10.9 build error here is unrelated and known.

[leoliu]

I need this too. I have to manually edit some makefile under wx in the erlang git source tree to get it to build. re-build wxmac takes very long time.

[adamv]

Getting an Erlang build failure on Lion; possibly due to a race condition in install? The install is deparallelized so I'm not sure what's going on here.

[adamv]

@BrewTestBot test this please

[adamv]

Erlang built this time, but not last time, so it would appear that the build step still has a (potentially rare) race condition, and should be reported upstream and run under ENV.j1.

This is sad, though, since building Erlang takes a very long time even with full use of cores.

[adamv]

I've updated this with a wxMac bottle. Now would be a good time to put some eyes on the code changes.

[mistydemeo]

Using the provided wxmac bottle, the wxpython bindings build and pass brew test for me.

[mistydemeo]

I think the first two lines were supposed to be separate thoughts.

[mistydemeo]

This looks good to me.

[mistydemeo]

Should the wxmac patches still be included?

[adamv]

Which patches? I haven't pushed anything yet.

[mistydemeo]

Might have happened when you rebased my older wxmac branch (which is from before the patch was added) - the current wxmac formula has a patch that's removed in your version of my commit.

[adamv]

Oh right, good catch!

[adamv]

Rebuilding the bottle with the patch.

[mistydemeo]

Thanks!

[mistydemeo]

Tested with a wxpython app (Twine, not via app bundle) and it works, BTW!

[adamv]

Erlang passed a wx smoke test as well.

[adamv]

I seem to be stuck, the uploaded wxmac bottle may not match the most recently built one

[adamv]

Looks correct locally though:

$ brew fetch --force-bottle wxmac
==> Downloading https://downloads.sf.net/project/machomebrew/Bottles/wxmac-3.0.0.mavericks.bottle.tar.gz
######################################################################## 100.0%
Downloaded to: /Library/Caches/Homebrew/wxmac-3.0.0.mavericks.bottle.tar.gz
SHA1: 6a5b2ff59a3f7b4c78658ed4f3cda543bfc7f325
SHA256: b75314828f700ca37e1db97551509e8470c3773b2057ffc25f59d730cd2f76df

[MikeMcQuaid]

@adamv Weird intermittent SF issue with new bottles. It only seems to happen in the first e.g. 24H. Perhaps I should tell the bot to always use a particular mirror or something. I'll SSH in and do a fetch.

Also, can someone remind me why we're splitting these up?

[MikeMcQuaid]

Let's use double-quotes everywhere now.

[adamv]

We're splitting them explicitly so we can bottle wxmac.

[MikeMcQuaid]

@adamv I realise I should have said this earlier but we might want to hold-off on this. This applies to a bunch of widely-used packages like e.g. libxml. I've got a half-written issue about this but basically we need to think of a strategy that lets us bottle Python packages too.

[adamv]

I think we want to split the wxPython build out anyway, since many things depend on wx without needing the Python bindings, which themselves also take a long time to compile.

[adamv]

A note on the change of wx to build --disable-monolithic: MacPorts seems to get saga to build with this option, though it may be applying a patch.

I can't build saga locally though due to:

In file included from soci.cpp:9:
./soci.h:306:23: error: use 'template' keyword to treat 'value' as a dependent template name
            return p->value<T>();
                      ^
                      template 

[adamv]

@MikeMcQuaid if you think a Python bottling solution is coming "soon", I can hold off on this, otherwise I'd rather see this start to go in.

[MikeMcQuaid]

@adamv I think it is. I'll create an issue.

[MikeMcQuaid]

@adamv Issue is up in #27112.

[adamv]

I'll pull the wxpython/bottle changes out of here and just test the wx/erlang ones.

[mistydemeo]

@MikeMcQuaid I changed this originally because the wxpython bindings take a good fifteen minutes to build and 60MB of space on disk. There's no reason to ask users who don't want wxpython to use them just because we think they should come in the same package. (They don't come in the same package upstream, and it was always a weird decision on our part to forcibly bundle them together.)

I'd been testing rebuilding both wxmac and wxpython independently of each other, and being forced to rebuild wxmac (30-40 minutes) just to test changes to wxpython was really, really painful.

Even if we have a python bottling solution coming soon, I would still want us to make this change - we'd just end up bottling wxpython as its own formula.

[MikeMcQuaid]

@mistydemeo If they don't come in the same upstream package I'm OK with them being separated. Apologies for the unnecessary intervention.

[adamv]

Continuing in #27116.