Updating to v1.2.11

[HCLJason]

Code copied over from source repo at zlib.net.

I have a matching update file for tools/ports in the emscripten repo.

[kripken]

Do we have local changes in this repo? It looks like the official zlib website points to https://github.com/madler/zlib as the canonical github location for it. I think we can switch tools/ports/zlib.py in emscripten to that, and delete this repo, which would be simpler?

[HCLJason]

No local changes. I unzipped the .tar.gz from zlib into my local git clone and uploaded it as-is. I tested using a modified zlib.py to pull from the updated GH branch.

There was discussion about moving zlib.py into this repo to get it out of emscripten. Moving the repo target in zlib.py to the madler/zlib would block that, unless you merge zlib.py upstream.

Leaving zlib.py and having it reference the official location instead of an old fork makes upgrading easier, since there's only one repo and file you need to change.

[kripken]

I see, good point @HCLJason

I think this raises a big question: do we prefer to have the config files in the emscripten repo, which would allow using unmodified upstream? Or do we prefer to have a forked repo, which can then contain the config file?

(I am assuming upstreams would likely not want our baked config files.)

I lean towards using unmodified upstream repos, which would mean we keep config files in emscripten. @sbc100 ?

[sbc100]

I see, good point @HCLJason

I think this raises a big question: do we prefer to have the config files in the emscripten repo, which would allow using unmodified upstream? Or do we prefer to have a forked repo, which can then contain the config file?

(I am assuming upstreams would likely not want our baked config files.)

I lean towards using unmodified upstream repos, which would mean we keep config files in emscripten. @sbc100 ?

I generally agree. But assuming we do have forked repo, in that case the config makes more sense there.

Specifically in the case of SDL, I think they are an exception because they do allow hardcoded/pre-baked config files for certain platforms. Other projects such as zlib I imagine would not want that.

So I think the rules should be:

1. Use an upstream config file if upstream repo allows such things (or if we have our own fork).
2. Prefer to use unmodified upstream, and don't fork purely to include our config file.

[sbc100]

Applying those rules here would mean we should delete this repo.

[kripken]

I agree about this repo, let's move forward with that then - so, to update emscripten to use upstream zlib, and a newer version. And then we can delete this repo.

More generally, I think it might be more consistent to keep all such config files in emscripten then? But I don't feel strongly.

[sbc100]

I agree about this repo, let's move forward with that then - so, to update emscripten to use upstream zlib, and a newer version. And then we can delete this repo.

More generally, I think it might be more consistent to keep all such config files in emscripten then? But I don't feel strongly.

I think config files embedded in the python scripts are pretty ugly and we should avoid them when we can (but not at the cost of creating a fork just to hold the config).

[kripken]

We could move config files out of the python scripts, into a file on the side - would that be better for you?

[sbc100]

We could move config files out of the python scripts, into a file on the side - would that be better for you?

That would be nicer yes.. but not as nice as keeping the config file alongside the sources for the library :)

[sbc100]

We could move config files out of the python scripts, into a file on the side - would that be better for you?

That would be nicer yes.. but not as nice as keeping the config file alongside the sources for the library :)

At least for the SDL case I think moving it upstream made a lot sense since that is where it belongs. I don't think we need to move the other ones any time soon.

[kripken]

Ok, sounds good.