Lua for Windows on GitHub?
Ryan Pusztai
> then for LfW we need a place to track source checkinYou would likely maintain your own repo on github for LfW specific
stuff (e.g. Windows installer scripts). But all the modules would be
in the main shared meta-repo [1]. The current issues being worked on
in the meta-repo are [2].
Ryan
Peter Drahoš
steve donovan
> Also Lua for Windows is hosted on GoogleCode so there is an SVN repository
> already supported there. Should we use that? Should we switch to GitHub?
> Should we just make the "install/distribute" part of the LuaDist GitHub
> submodule?
Well, personally speaking SVN always gives me a headache - and Git
allows the killer feature of keeping separate but synchronized
repositories.
Where the actual binaries go, is probably a separate issue. I think
it's easier to host them as static files so that people don't need Git
directly, only us actual developers. Would make sense to set up a
luarocks repository populated with binary rocks for the supported
platforms.
We could offer a small, basic install which has an easy GUI interface
to luarocks (which of course can always be used from the
command-line).
One thing which is very much on my mind is the perceived 'extra value'
which we are offering people who are presumably reasonably happy with
the existing LfW. One of the things offered would be 'batteries on
demand' although a 15 meg download is probably not considered
heavyweight anymore. Some of the components will be fresher (e.g. new
SciTE 2.11 +) but I would like to see a more integrated help system
(which is probably a utopian ideal given the wide range of
documentation styles actually offered)
Another serious value-add would be a 'Lua for Windows Cookbook'
bringing together the tricks and tips needed to do real-life things.
This is perhaps outside the scope of our current discussions about
building, of course.
Another value-add is that the source is all available and found in the
same place. For this the LuaDist repositories would work well.
For 32-bit, can offer LuaJIT2.0 as an alternative to vanilla Lua - so
LfW can advertise itself as a distribution build around the fastest
dynamic language implementation on the planet. That remains a very
cool thing.
As for 64-bit Windows, mingw64 cannot yet handle the 64-bit Windows
exception handling that LuaJIT demands. A small obstacle on the road
to global domination
steve d.
steve donovan
> I recommend switching to GH and using submodule functionality either to LD
> or projects relevant to the effort. No need to duplicate the
> repositories,its better to submit issue to them.
Yes, it's a good idea to have one canonical place where an interested
party can find the source to modules, which becomes the place where
issues are raised and patches are made.
The users of a particular distribution of course use the provided
channels, but the distribution maintainers have a central place to
keep issues and fixes.
I have a preference for keeping final binaries on a static webserver,
but the name & location of that is immaterial.
steve d.
Peter Drahoš
On Mar 15, 2011, at 2:14 PM, steve donovan wrote:
> ...
> I have a preference for keeping final binaries on a static webserver,
> but the name & location of that is immaterial.
Just a small note. GitHub supports downloads, not just for the repository tags/releases but any uploaded file. Linking that to a static site works well and GH can even host that. No additional infrastructure required.
pd
steve donovan
> Just a small note. GitHub supports downloads, not just for the repository tags/releases but any uploaded file. Linking that to a static site works well and GH can even host that. No additional infrastructure required.
Yeah, I was thinking of the interesting things that happen when you
put a tag release URL into a rockspec ... so the actual uploaded files
are served statically?
I presume there is some API to mechanize this since it could get
rather tedious otherwise. The GH static site support is particularly
easy to automate.
steve d.
Peter Drahoš
On Tue, Mar 15, 2011 at 3:19 PM, Peter Drahoš <dra...@gmail.com> wrote:Just a small note. GitHub supports downloads, not just for the repository tags/releases but any uploaded file. Linking that to a static site works well and GH can even host that. No additional infrastructure required.
Yeah, I was thinking of the interesting things that happen when you
put a tag release URL into a rockspec ... so the actual uploaded files
are served statically?
I presume there is some API to mechanize this since it could get
rather tedious otherwise. The GH static site support is particularly
easy to automate.
Thijs Schreijer
Should we switch to GitHub?
Peter Drahoš
steve donovan
> There is an ongoing effort on GitHub to reproduce the Lua For Windows
> functionality in a cross-platform manner
This is (I think) the only sane way forward, since it lets us easily
switch to (say) mingw for LfW, and provide a very similar Lua
distribution for Linux and OS X.
(CMake may make my eyes bleed, but it does get the job done!)
steve d.