12d52be921
Oops; missed a spot.
2019-04-08 20:38:17 -04:00
9bcb6d0af0
And made copies of the old files so we can properly rebuild them.
2019-04-08 20:37:31 -04:00
992d8694a9
Let's start the remodel. Move almost everything out of the way.
2019-04-08 20:36:21 -04:00
6247f94a74
Fixed the only-on-tags check. This documentation is unclear.
2019-04-07 23:38:28 -04:00
ab58d0053c
Oh, I had to make the connectiona vailable to use on all pipelines.
2019-04-07 23:31:08 -04:00
88a3267cdd
Merge branch 'meson'
...
This switches the build system from CMake to Meson. This also switches from Travis CI to Azure Pipelines.
Fixes #450 .
Fixes #449 .
2019-04-07 23:24:01 -04:00
425c920952
And updated the README with both the Azure Pipelines badge and Meson merge date. We're good to go!
2019-04-07 23:22:09 -04:00
c9ae167d90
I'm a dumb
2019-04-07 23:08:08 -04:00
1761f99e81
Triple oops, maybe??
2019-04-07 23:03:43 -04:00
7fb9cfae21
Double oops
2019-04-07 23:01:50 -04:00
50f019abef
Oops
2019-04-07 23:00:50 -04:00
d62e767056
That didn't work; try it with template syntax instead.
2019-04-07 22:58:21 -04:00
6d1e1d7f26
Try to fix Azure Pipelines. I won't be able to make a tag to test the binaries until I merge back in, but I can't figure out how to set the default branch with YAML configurations (unless I have to do it on master), so.
2019-04-07 22:55:28 -04:00
e8daaf659e
windows/direct2d: fix ID2D1RenderTarget::GetPixelFormat() and ID2D1RenderTarget::GetSize() typedefs in MinGW-w64 ABI workaround
...
MinGW-w64 recently added manual workarounds directly into the class via overloads that make existing Direct2D code source-compatible. However, that exposed an error in my definition of the typedefs I was using in my own workaround: both of these methods are const, even in MSVC, but I neglected to include the const qualifier. I'm not sure how this code compiled in the past, but now the overload resolution engine finds no match.
I want to remain compatible with versions of MinGW-w64 old enough to not have their fix, so our fix remains.
Fixes #446 .
2019-04-07 21:56:35 -04:00
9c164a2c5c
Okay, at this point I'm betting pushd/popd just don't work on AppVeyor's cmd.exe. I'm betting it has to do with popd /? showing me the output of call /? instead. Just use cd.
2019-04-07 21:03:20 -04:00
73e4e58c80
Okay, let's see if it's because of the multiline scripts.
2019-04-07 20:53:32 -04:00
0b319032b6
Other way
2019-04-07 20:44:19 -04:00
fbdd84ac86
Not sure why popd is exiting with status 1...
2019-04-07 20:43:49 -04:00
d08ab7d260
Double oops. But this should work now!
2019-04-07 20:35:56 -04:00
6e915321cc
Oops
2019-04-07 20:29:46 -04:00
52f07b0533
No reason pip shouldn't work...
2019-04-07 20:23:07 -04:00
acc0586fd6
Okay so .appveyor.yml cmd scripts must not have multiline commands, ugh.
2019-04-07 20:16:04 -04:00
3f815718b1
Oops
2019-04-07 18:17:10 -04:00
3037d7b87f
Completely update the AppVeyor proejct. It now only handles MinGW and VS2013 builds, and uses YAML better. Partially based on guidance in the meson documentation.
2019-04-07 18:15:45 -04:00
69bfbbf19c
And set up tagging and GitHub releases. That'll be all for the Azure Pipelines configuration; now we just need the AppVeyor configuration.
2019-04-07 17:47:30 -04:00
102693e1be
Wrong backup
2019-04-07 17:22:10 -04:00
36594e3759
Okay, so it seems I can't insert template names as matrix fields, and I'd rather not have a bunch of tiny jobs for all these different templates. So forget it for now.
2019-04-07 17:20:52 -04:00
5492d34bce
Do I need to use variables.?
2019-04-07 17:13:59 -04:00
a0ef6f6ca7
Okay, I guess I need to use the full pathname for templates?
2019-04-07 17:09:45 -04:00
c0c9a3ae92
Ah
2019-04-07 17:06:23 -04:00
9af82be7f7
Oops again
2019-04-07 17:03:50 -04:00
ac26cf7521
Oops
2019-04-07 17:02:32 -04:00
c2eb806992
Start the matrixification
2019-04-07 17:01:28 -04:00
9b483d972d
Wrote a script to diff all the jobs we have so I can matrix-ify them.
2019-04-07 16:34:22 -04:00
0969f43196
Delete the now-merged files.
2019-04-07 16:12:12 -04:00
b85c5c542a
Merged all the files back together.
2019-04-07 16:11:59 -04:00
851bbfe74f
And the MinGW-w64 in Ubuntu 16.04 is too old. Oh well.
2019-04-07 16:06:17 -04:00
93383cd45a
Oh, the altenratives use win32 by default.
2019-04-07 15:57:53 -04:00
46459dc8b2
OK then, it's a meson bug. Also -win32 doesn't have C++11 threads :|
2019-04-07 15:52:41 -04:00
31a91d6fc0
Hm.
2019-04-07 15:45:27 -04:00
8b908aedc1
Oops, MinGW-w64 isn't installed by default.
2019-04-07 15:34:40 -04:00
2dcdbe02c9
Let's try using Linxu MinGW-w64.
2019-04-07 15:32:01 -04:00
87bdb4e736
Moved the linux 386 steps to azure-pipelines_linux. Next up is trying the MinGW-w64 setup again, but using the MinGW-w64 in Linux instead of Windows.
2019-04-07 14:28:08 -04:00
30a363baf1
Normalized template filenames and split the 64-bit apt-get step into its own template.
2019-04-07 14:24:16 -04:00
9dc7a2bc7f
Try to speed up the build process by consolidating all the apt-get installs into one. These 386 binaries do work, at least.
2019-04-07 14:04:57 -04:00
85544275d0
All right, now split all those steps into its own file, clean up all the debugging nonsense, and apply it to the static build as well. Let's hope the artifacts are useful!
2019-04-07 13:45:02 -04:00
dffdb63f01
All right, that's the full list of packages. Now let's actually try this!
2019-04-07 13:27:48 -04:00
9660c15fd1
More missing packages
2019-04-07 13:13:44 -04:00
b2c44efd7f
More complete package list
2019-04-07 13:07:37 -04:00
d53d68226d
I guess we'll need to do this :/
2019-04-07 13:02:23 -04:00
Pietro Gagliardi