On Tuesday, 2 April 2013 at 16:37, Hisham wrote:

> > Finding them is then trivial, for the code itself and for users: just browse
> > around the code. For example lub.path uses the debug library to find
> > running script path so this is robust and relocatable.
> > 
> 
> 
> Oh great, so you already have relocation support! That simplifies things.
> 
> On 2 April 2013 08:10, Gaspard Bucher <gasp...@teti.ch 
> (mailto:gasp...@teti.ch)> wrote:
> > But why not change the rules and decide that assets are OK in
> > /usr/local/share/lua/5.1 and find a way for luarocks to install them there ?
> > 
> 
> 
> All right, I found a way to convince LuaRocks to install assets
> alongside modules.
> It's a bit of a hack but I ran some tests and think it works for now. See 
> below!
> 
> > Just decide on some sub-path in modules so these assets are easily detected
> > if there needs to be some house keeping...
> > 
> > Rubygems have not been rejected by the linux community because of this...
> > And the rule to keep things separate holds as long as they end up in well
> > known paths which is not the case for relocatable lua installations (which
> > is good).
> > 
> 
> 
> Good points.
> 
> > Requiring a "post-install-fix" is even worse and is a no-go: move the folder
> > around and... "lub" breaks. No thanks.
> > 
> 
> 
> The idea is that one shoudn't move the folders around when relocating
> a rock. One should `luarocks pack foo` and then `luarocks install
> foo-xyz.rock` in the new location (just moving things around would
> break the LuaRocks housekeeping manifest). But I get your point.
> 
> And now for the solution.
> 
> build = {
> type = "builtin",
> modules = {
> -- other modules
> },
> install = {
> lua = {
> ["bla.biscoito"] = "bla/biscoito.jpg"
> }
> }
> }
> 
> This installs bla/biscoito.jpg in the proper place. The
> build.install.lua table just copies files around blindly. (The
> build.modules table was my first try, but it will default to trying to
> compile it as C when then code does not have a .lua extension.) The
> string key in the table is necessary in order to create the proper
> directories, but the last part of the name is ignored, so if you need
> to add two files with the same extension (e.g lub.css and lub.js),
> just hack it like this:
> 
> install = {
> lua = {
> ["some.dir.lub_css"] = "src/foo/lub.css",
> ["some.dir.lub_js"] = "src/foo/lub.js"
> }
> }
> 
> 

Thanks Hisham,

This is a very good solution that has the advantage of not needing image 
serialization as lua code !

I will do some testing and release the first two modules rapidly so that the 
documentation generator lub.Doc, testing lub.Test and C++ binder dub can be 
easily used by others.

"lub" only depends on "lfs"
"dub" depends on modified versions of LuaXML by Gerald Franz and yaml by Andrew 
Danforth. So for this I probably need to release "lubyk.xml" and "lubyk.yaml" 
modules first.

Cheers,

Gaspard
------------------------------------------------------------------------------
Own the Future-Intel(R) Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest. Compete 
for recognition, cash, and the chance to get your game on Steam. 
$5K grand prize plus 10 genre and skill prizes. Submit your demo 
by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2
_______________________________________________
Luarocks-developers mailing list
Luarocks-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/luarocks-developers

Reply via email to