Hi!
Am 01.05.2013 20:43 schröbte Hisham:
> It didn't? I just tested it here and it seems to pass the flag. Just
> to be clear, this 'defines' table is supposed to be inside each
> module's entry in a builtin-type build section, like this:
>
> build = {
> type = "builtin",
> modules = {
> foo = {
> sources = { "foo.c" },
> defines = { "dummy -std=c99" },
> },
> re = "re.lua"
> }
> }
>
> Running that, I get the following line here:
>
> gcc -O2 -fPIC -I/Programs/Lua/Current/include -c foo.c -o foo.o -Ddummy
> -std=c99
This is printed from the local `execute` function in
`luarocks/build/builtin.lua`, which later calls `fs.execute`, which ends
up to be the one defined in `luarocks/fs/lua.lua`, which quotes its
arguments, so
-Ddummy -std=c99
really is
'-Ddummy -std=c99'
Btw., I believe compiler support for C99 should be some form of
(external?) dependency (maybe like the magic "lua" in the dependencies
table), so that Visual C++ users get a more informative error message
why some module wouldn't build for them.
dependencies = {
"lua ~> 5.1",
"c >= 99", --> maybe like this? one could even do
-- "c == gnu99" --> for compiler specific modules, but IMHO
this is going too far ...
}
An alternative (or maybe an additional feature) would be some form of
compiler overrides like the current platform overrides, but I think a
clear message what went wrong is more difficult in this case.
>
> -- Hisham
Philipp
------------------------------------------------------------------------------
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with <2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1
_______________________________________________
Luarocks-developers mailing list
Luarocks-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/luarocks-developers
