I just noticed I botched commit messages on ilmbase and openEXR; they're versions 2.3.0, not 2.0.3.

they're versions 2.3.0, not 2.0.3

You can always reword and force-push, PRs are temporary branches in this project.

A few other comments:

• Does the boost update work with all its downstream packages? The primary reason it isn't updated is that it has broken those in the past, and they are hard to update themselves
• please use git format-patch style instead of diff-style patches
• please check your editor settings and/or run make cleanup-style to normalise tabs/spaces

they're versions 2.3.0, not 2.0.3

You can always reword and force-push, PRs are temporary branches in this project.

I was going to do that yesterday but was tired and forgot, actually.

A few other comments:

• Does the boost update work with all its downstream packages? The primary reason it isn't updated is that it has broken those in the past, and they are hard to update themselves

Haven't tested all of them, probably. Any specific ones I should test?

• please use git format-patch style instead of diff-style patches

I make my patches using git diff --no-index because I had no idea git format-patch existed. I assumed it was the same with some comments written on top. õ_õ

• please check your editor settings and/or run make cleanup-style to normalise tabs/spaces

Will do. Should I use tabs or spaces? Or it doesn't matter as long as each file is consistent with itself?

Any specific ones I should test?

$ make show-downstream-deps-boost
assimp cgal cpp-netlib hyperscan json_spirit libtorrent-rasterbar luabind openscenegraph osgearth pcl pe-util wt xmlwrapp

pcl and wt are the most problematic.

...git format-patch existed. I assumed it was the same with some comments written on top. õ_õ

It is very similar - the comments give future maintainers context around what can removed from the patch (especially if those have been submitted upstream). In some cases it provides something close to a workflow where mxe patches are just a series of commits that can be rebased.

Should I use tabs or spaces?

Always spaces in src/*.mk - there are cases in other Makefile rules that make cleanup-style may not correct. (my personal preference is always spaces and strip trailing, but preserve actual tabs).

Or it doesn't matter as long as each file is consistent with itself?

It doesn't matter per-se, review the diffs the PR is generating and avoid generating whitespace changes (unless you are certain).

Any specific ones I should test?

$ make show-downstream-deps-boost
assimp cgal cpp-netlib hyperscan json_spirit libtorrent-rasterbar luabind openscenegraph osgearth pcl pe-util wt xmlwrapp

pcl and wt are the most problematic.

...git format-patch existed. I assumed it was the same with some comments written on top. õ_õ

It is very similar - the comments give future maintainers context around what can removed from the patch (especially if those have been submitted upstream). In some cases it provides something close to a workflow where mxe patches are just a series of commits that can be rebased.

Should I use tabs or spaces?

Always spaces in src/*.mk - there are cases in other Makefile rules that make cleanup-style may not correct. (my personal preference is always spaces and strip trailing, but preserve actual tabs).

Or it doesn't matter as long as each file is consistent with itself?

It doesn't matter per-se, review the diffs the PR is generating and avoid generating whitespace changes (unless you are certain).

I really need to get more familiar with MXE targets. I ended up running a regex search for boost among deps and left it running. By default I build most things as shared though so I'll need to try a static build also later. Anyway, if there are build failures you can expect me to either look into them and/or update the problematic packages also.

I've always preferred tabs but as I said my editor can go from one to the other easily so I'll fix that later also.

@tonytheodore I was working further on this over the weekend. I had to make some more changes to these and a few other packages but so far most things are building fine, including pcl and wt.

I'm currently facing some issues with cgal and libtorrent-rasterbar possibly among a few others. Will rebase and push again once I've got them sorted.

_{Sent with GitHawk}

P.S. Jesus. The format patch tool makes work so much more straightforward and easier. I can't believe I was working the badwrong™️ way until now.

_{Sent with GitHawk}

Using the format-patch style enables a workflow like:

# initialise repo based on tarball + patches in $mxe-dir/gits/foo-1.2.3
make init-git-foo
make import-patch-foo

# make changes in gits/foo-1.2.3 or find fix an apply with
curl -L 'https://github.com/foo/foo/commit/1a2b3c4d.patch' | git am

# check changes with
make foo foo_SOURCE_TREE=gits/foo-1.2.3

# commit changes and export patch
make export-patch-foo
make foo

# send PR to mxe

Once you get used to it, git handles lots of things nicely.

Once you get used to it, git handles lots of things nicely.

Yeah that's what I've been doing now that I realized how it works.

This should be good to go now. I've tested, fixed and updated pretty much every thing that depends on boost. I've also updated cmake and even made some fixes (OpenEXR and IlmBase) I've committed PRs upstream for.

It's conflicting with a couple of your updates though, I'm not sure whose commits fixing those issues are better.

For openthreads and openscenegraph, I changed the TRY_RUN to TRY_COMPILE... for openal, I remove and added patches as appropriate, but I also fixed one (mmdevapi is actually an old name for wasapi; I'm not sure if you caught that)

I know this PR is humongous but think you could take a look at merging it at some point?
I checked the conflicts and tries as much as possible to merge the fixes in master with the ones I made.

@tonytheodore think somebody could take a serious look at this PR? even if you don't end-up merging all of it (some parts already might have become obsolete but some solve problems outstanding on master or a few that were solved already but in different ways) but a lot of work went into making everything play nice with pthreads; most of the updates after that are me having noticed certain broken downstream packages and fixing them.

And, there are many plain-old package updates in here also.
If any build-failures remain I'm committed to fix them, most of the things here I've been using in practice to produce working 32 and 64-bit installers for perfornous.

Thanks for the updates @Lord-Kamina, I do appreciate the effort that you've put into it and will have a look soon - it's been a long time coming.

Large PRs are hard to merge upfront, even when most the changes could be merged individually without much review. Over time, the only (sane) option is to use git diff master to find the current delta - I've tried various cherry-picking and rebase strategies in the past and end up in all sorts of trouble.

A couple of pthreads-related cleanups I'll add from a toolchain perspective:

• pthreads package can be removed (I only kept it for future testing)
• add independent post-gcc|cmake test packages
• remove make show-direct-downstream-deps-pthreads deps
• use [POSIX | WIN32]_THREADS variable instead of MXE_GCC_THREADS tests

Keep in mind I've been actively using this branch (or at least an offshoot of it), so I can work to solve current conflicts with master.

There's probably four phases I would approach this in:

• pthreads cleanup
• win32threads removal and related updates
• unrelated updates
• boost update

It's probably not worth your effort to resolve conflicts since there's also whitespace and style changes, and I'll most likely leave the boost update as a new open PR.

It's probably not worth your effort to resolve conflicts since there's also whitespace and style changes, and I'll most likely leave the boost update as a new open PR.

Too late.

Also, keep the following in mind: The reason that this PR is so big is that I began changing stuff and seeing downstream packages broken; so I began fixing those and that eventually turned into updating those many times.

The boost update will break many things if you isolate it.

The one thing you'll most likely want to pick-out (unless you changed your mind since I last asked) is that this PR updates the core gcc to gcc8.

Conflicts solved again.

I agree. This needs to be merged.

EDIT: But it has file overlap with my GTK update PR for sure. Since I was migrating the whole GTK stack to the meson build system. See: melroy89#1