> -----Original Message-----
> From: Tom N Harris [mailto:tellia...@whoopdedo.org]
> Sent: dinsdag 27 augustus 2013 11:56
> To: luarocks-developers@lists.sourceforge.net
> Subject: Re: [Luarocks-developers] Define system specific flags.
>
> On Tuesday, August 27, 2013 04:28:01 AM Alexey Melnichuk wrote:
> > I do not want have constant version in rockspec.
> > I want to get version number of system on which my module will be run.
> > Lurocks do not provide way to discovery system on which it installed.
> > Some functionality depend on Windows major version, some depend on
> version
> > of SP and some even depend on version of internet explorer.
> > And i do not insist that luarock should provide bultin WINVER variable.
> > But it should provide way to determinate such runtime variables.
> > I think different between `UNICODE` macro and `WINVER` macro is
> > `WINVER` describe API version, `UNICODE` serve to configure specific
> API.
>
> I can agree with the need to know the current version of the build host
> OS.
> The equivalent of Linux's uname. May as well make it a general variable
> for
> all platforms. Or expand the platform override system to work with version
> numbers.
>
> build.platforms = { ["win32 >= 5.1"] = { ... } }
>
> Do we need architecture overrides too? x86, x86_64, armv7, et. al.
>
> But using this to directly set WINVER isn't appropriate. As you pointed
Wasn't the intent to let LuaRocks define an automatically set internal variable
(also called WINVER) with the detected windows version? From there it is up to
the rockspec author to determine whether he/she puts that variable to good use
in the rockspec.
So if one doesn't include;
defines = { "WINVER=$(WINVER)" }
in the rockspec, nothing changes.
On top of that one could then extend this with 'smarter' auto discovery tools
like Lake.
Thijs
> out,
> the build host has nothing to do with the API version. I can't just define
> WINVER=0x602 and expect the new API to magically appear in MinGW. I'd be
> building with an effective API version of 0x601, which could lead to
> compile
> errors if the source tries to use any Windows 8 features. The ideal
> setting
> for WINVER is the minimum of the API version the source is compatible
> with,
> and the API version that can be supplied by the SDK.
>
> An intelligent build system would help just as Linux developers use
> autoconf
> to detect compiler features. But lacking a reliable environment to run
> scripts
> in, we prefer the builtin method for Windows rocks. And you've encountered
> one
> of its limitations.
>
> Lake isn't a defined backends. But it could be if LR had build-time
> dependencies. This is on the roadmap, isn't it?
>
> ps. I still say it would be easier to build one universal module that
> detects
> the available functions at runtime using GetProcAddress. See
> http://blogs.msdn.com/b/vcblog/archive/2012/03/13/10282397.aspx
>
> --
> tom <tellia...@whoopdedo.org>
------------------------------------------------------------------------------
Introducing Performance Central, a new site from SourceForge and
AppDynamics. Performance Central is your source for news, insights,
analysis and resources for efficient Application Performance Management.
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
_______________________________________________
Luarocks-developers mailing list
Luarocks-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/luarocks-developers
