Giters

m-schmoock / lcpp

A Lua C PreProcessor

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Configuration

catwell opened this issue · comments

commented

Hello,

great project! I think there is an issue with the way you handle configuration though.

You set the configuration variables (lcpp.LCCP_LUA, lcpp.LCCP_FFI, lcpp.LCPP_TEST) in the source and you use them when the module is required. That means you cannot actually load lcpp without running the tests or overloading the FFI.

There are several solutions to this, the simplest being to replace those options by functions of the lcpp module that would have to be called explicitly (e.g. lcpp.use_ffi()). That would mean everything is off by default.

Another possibility would be to make the module return a function that takes a table of options and returns the actual lcpp table, so you would use it (for instance) like that:

local lcpp = (require "lcpp"){test = false, lua = true}

Anything not set explicitly (nil) could take a default value of your choice.

commented

I see what you mean.

LCPP_FFI, LCPP_LUA and LCPP_TEST were not meant to be configured during runtime (or load time). Their current (shipped) values should can be manually changed (by code) if user needs to.

  • LCPP_FFI := true This is the main usecase of lcpp. And its failsafe, because it checks for ffi mod to be available. Almonst nobody would like/need to turn it of.
  • LCPP_LUA is not doing anything good (yet).
  • LCPP_TEST does not harm to be enabled.

However I see that there may be the need to disable and restore LCPP_FFI during runtime. So i will add two functions:

  • lcpp.register();
  • lcpp.unregister();

... or maybe disable()/enable() or something like that. Btw, nice you mentioned... the variables have the wrong name (LCCP instead of LCPP). Is that okay for you?

regards,
Michael

commented

Hmm, do you intend to publish this as a library, e.g. on LuaRocks? Something that can be installed on a system? Because if that's the case you cannot rely on the user changing the code.

I think lcpp can make writing FFI bindings easier, and it would be great to be able to publish a rock that depends on lcpp. But if that's the case you probably don't want to run the lcpp tests every time you require that binding, and you do not want requiring that binding to change the behavior of the FFI everywhere.

So, having register / unregister functions (or disable / enable) would be fine as long as there is a way to require lcpp and have it not do anything by default, but that probably means disabling everything by default...

commented

A luarocks package is planned when i have the time. did you ever made a luarock? maybe you can help there (if you want).

Back to the topic:

  • tests can be disabled per default, as i run them anyway before releasing.
  • concerning LCPP_FFI: i dislike the module factory function thingy with the parameters because its so uncommon to use a module this way in lua. But I also think that FFI wrapper must be enabled per default (if ffi is available), because this is really the standard usecase for lcpp. So I have no other option than to add an disable/enable function, correct?

regards,
Michael

commented

I can write you a rockspec if you want, yes :) For a simple one-file module like this it is easy, those for one of my modules can be found here.

As long as you disable the tests I'm OK with FFI by default. Although now that I think about it, why do you need to monkey patch ffi.cdef at all? Couldn't you just expose a lcpp.cdef function instead?

EDIT: just saw you fixed the issue, I can do with the enable / disable scheme so if you want to leave it like that it's fine with me.

commented

agreed. offering an alternative function would be a solution.
for now tests are disabled. and ffi / lua wrappers can be disabled, re-enabled.

how does the luarocks thing work? write and host a rockspec somewhere and send them a mail with the link? or how do i get into the luarocks mirror?

will

commented

Yes, you must write the rockspec, host it somewhere (the easiest is to add it to the repository) and send it to the LuaRocks mailing list. Hisham actually looks at all the rockspecs and adds them to the main repo himself (!), then this repo is replicated to the mirrors daily by rsync.

You can also publish on MoonRocks, which is down now... To publish them you don't need validation. Usually I publish SCM rockspecs to MoonRocks and real relases to LuaRocks.

As far as I know there is no syntax to depend on LuaJIT yet, so you need to depend on Lua 5.1 and add a comment in the rockspec stating that you actually need LuaJIT like here.

commented

Hey Catwell,

can you have a quick look at lcpp rockspec and tell me if it can be accepted this way?
https://github.com/willsteel/lcpp/blob/master/lcpp.rockspec

Edit: Is a stupid a git HEAD rock allowed, or do i need to make versioned releases for each rock?

cheers,
Michael

commented
  • The name of the package should be lcpp, not lcpp.git.
  • The version should probably be scm-1. scm means "source code management" (i.e. git...) and the number after the dash is the version of the rockspec itself. You need that number, otherwise you can never update it again.
  • You should add a comment next to the requirement of Lua 5.1 to say that LuaJIT is actually required.
  • For the license I think you should write MIT/X11 because there are several MIT licenses, probably doesn't matter much though.

Also, I am not sure it is a good idea to add a pure SCM rockspec to LuaRocks (you never know when to update...). What you could do is tag a revision in git (e.g. 1.0), change the version to 1.0-1 and use source.tag (see doc). You can look here for an example, it's written by Hisham (LuaRocks author) so it's a good reference ;)

commented

the rockspec runs now... but when i want to use lcpp it says "module not found".
It turns out that lcpp is installed to: /usr/lib64/lua/luarocks/share/lua/5.1/lcpp.lua
but that path is not within lua package loader. im just asking because I can use other luarocks and their module path does not seem to be a problem (on the same machine).

commented

The name of the rockspec file isn't right:

$ luarocks install lcpp.rockspec
Using lcpp.rockspec... switching to 'build' mode

Error: Expected filename in format 'name-version-revision.rockspec'.

You should rename it lcpp-scm-1.rockspec. After that it should work.

The issue about the installation path appears to be a luarocks configuration problem on your machine. I have tried on mine and it works fine. Check out here (Variables section).