search

conda-forge / lua-feedstock

A conda-smithy repository for lua.
BSD 3-Clause "New" or "Revised" License
3 stars 16 forks source link

Fix Lua 5.2 builds on OS X #6

Closed jakirkham closed 8 years ago

jakirkham commented 8 years ago

Fixes https://github.com/conda-forge/lua-feedstock/issues/5

Closes https://github.com/conda-forge/lua-feedstock/pull/3 Closes https://github.com/conda-forge/lua-feedstock/pull/4

This fixes the Lua 5.2 builds on OS X. Tested locally on my Mac and it build fine. The fix works by also setting the rpath on OS X similarly to how it does on Linux. Also, we absorb the pinning PRs ( https://github.com/conda-forge/lua-feedstock/pull/3 ) ( https://github.com/conda-forge/lua-feedstock/pull/4 ). This is done so that we can control the versions we build against are compatible with the ones we install.

Please review and merge when satisfied @alexbw.

conda-forge-linter commented 8 years ago

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

jakirkham commented 8 years ago

Passing. 💚

alexbw commented 8 years ago

Wow, thanks!

alexbw commented 8 years ago

I've left this on the back-burner, but might have time to get back into porting Lua-ecosystem packages this week. Still unsure of how to have multiple Lua versions in this same repository. Do I maintain separate branches? Will need to maintain Lua 2.0, 2.1, 5.1, 5.2 and 5.3 into perpetuity, most likely. They will not receive e.g. 2.0.x updates, though, so they'll be static once they're built the first time.

jakirkham commented 8 years ago

I've left this on the back-burner, but might have time to get back into porting Lua-ecosystem packages this week.

That's great news! I'm pretty excited to get Lua up and running in conda-forge.

Still unsure of how to have multiple Lua versions in this same repository. Do I maintain separate branches?

Yes. So, you already have 2 releases now. 5.1 is in its own branch also 5.2 and master branches are in sync (just resynced them myself). Though you only need branches for non-current versions.

Will need to maintain Lua 2.0, 2.1, 5.1, 5.2 and 5.3 into perpetuity, most likely. They will not receive e.g. 2.0.x updates, though, so they'll be static once they're built the first time.

So, 5.1 and 5.2 are done. I'd PR 5.3 to master. It doesn't need a branch as it is the most current version.

When 5.4 comes out, it will also go into master. If you need a 5.3 patch release after adding 5.4, I would then add a branch for 5.3 (based on the last 5.3 commit) on this repo and PR the patch release from your fork to this repo. Once merged you would get this patch release.

As for the 2.x releases, we had a very recent discussion about this w.r.t. Python. One of the most active maintainers of Python wanted to start building some very old unmaintained Python versions for curiosity mainly. Initially we considered having the branch model. Though it is a bit extreme as they are not maintained. Also we didn't want to suggest to people these would actually be maintained Instead we settled on a historic branch. Take a look to get an idea. I'm not sure if that is your use case here or not. Is 2.x something you would like to keep in good working order for people to use (think resolving bug reports) or is it more of a one off? If it is the former, I would suggest the branch model. If it is the latter, I would go for the historic branch. Please let me know your thoughts.

alexbw commented 8 years ago

Ok, this all makes sense. Basically, if a build successfully goes through, it's saved in conda-forge. So, work on one 5.x release at a time, and just merge them directly into master. I can probably then just tag specific commits as belonging to e.g. 5.1, and leave them there.

The 2.x releases are not very old versions of Lua. They are a branch of the language called LuaJIT which is in very active use, but the internals of conda-build made it much easier to use version numbers to discriminate them rather than features or other named packages. Think of LuaJIT vs. Lua like PyPy vs CPython. However, development is done on 2.0 and is basically not moving on 2.1, so a luajit-2.0 and luajit-2.1 branch will probably take care of that.

Another question -- there are a lot of packages for Lua, managed by the semi-official package manager luarocks, that I have conda recipes for (internally using the luarocks system, just doing a local install during build). Think of luarocks as pip. What's conda-forge's stance on conda packages that wrap pip-installable packages? Just build them and upload them en masse to conda-forge?