Build configuration via defines

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Build configuration via defines

Daurnimator
Hi Roberto,

Have you considered allowing (some) things in luaconf.h to be easily
configurable from compiler command line options?
This usually means allowing configuration via `-D` switches.
To make this possible, luaconf.h should only define things if they are
not already defined.

e.g,
Currently there is:

#define LUA_ROOT "/usr/local/"


It would be easier for packaging if this was instead:

#ifndef LUA_ROOT
#define LUA_ROOT "/usr/local/"
#endif


I assume this doesn't occur today as luaconf.h is installed as a
header onto end user systems.
There are some ways around this:
  - some of the defines (such as LUA_ROOT) probably don't need to be
available for compiling modules
  - for values that do need to exist at runtime, they could be made
available through externs, or some new function
lua_compilation_flags();

Reply | Threaded
Open this post in threaded view
|

Re: Build configuration via defines

Roberto Ierusalimschy
> I assume this doesn't occur today as luaconf.h is installed as a
> header onto end user systems.
> There are some ways around this:
>   - some of the defines (such as LUA_ROOT) probably don't need to be
> available for compiling modules
>   - for values that do need to exist at runtime, they could be made
> available through externs, or some new function
> lua_compilation_flags();

I did not understand your points here.

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: Build configuration via defines

Daurnimator
On 9 July 2018 at 22:44, Roberto Ierusalimschy <[hidden email]> wrote:

>> I assume this doesn't occur today as luaconf.h is installed as a
>> header onto end user systems.
>> There are some ways around this:
>>   - some of the defines (such as LUA_ROOT) probably don't need to be
>> available for compiling modules
>>   - for values that do need to exist at runtime, they could be made
>> available through externs, or some new function
>> lua_compilation_flags();
>
> I did not understand your points here.

Lets ignore my assumption then:
Is there a reason that lua isn't configurable by command line defines
instead of editing luaconf.h?

Reply | Threaded
Open this post in threaded view
|

Re: Build configuration via defines

Roberto Ierusalimschy
> On 9 July 2018 at 22:44, Roberto Ierusalimschy <[hidden email]> wrote:
> >> I assume this doesn't occur today as luaconf.h is installed as a
> >> header onto end user systems.
> >> There are some ways around this:
> >>   - some of the defines (such as LUA_ROOT) probably don't need to be
> >> available for compiling modules
> >>   - for values that do need to exist at runtime, they could be made
> >> available through externs, or some new function
> >> lua_compilation_flags();
> >
> > I did not understand your points here.
>
> Lets ignore my assumption then:
> Is there a reason that lua isn't configurable by command line defines
> instead of editing luaconf.h?

Several configurations affect the API. So, if you compile Lua with
some options and then compile your code with other options, they will
not match. Moreover, there are many configurations, and a .h file is
more portable than a makefile. But I guess we can add '#if !defined'
around several of them (like LUA_ROOT).

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: Build configuration via defines

Marc Balmer
 

Am 09.07.2018 um 15:13 schrieb Roberto Ierusalimschy <[hidden email]>:

>> On 9 July 2018 at 22:44, Roberto Ierusalimschy <[hidden email]> wrote:
>>>> I assume this doesn't occur today as luaconf.h is installed as a
>>>> header onto end user systems.
>>>> There are some ways around this:
>>>>  - some of the defines (such as LUA_ROOT) probably don't need to be
>>>> available for compiling modules
>>>>  - for values that do need to exist at runtime, they could be made
>>>> available through externs, or some new function
>>>> lua_compilation_flags();
>>>
>>> I did not understand your points here.
>>
>> Lets ignore my assumption then:
>> Is there a reason that lua isn't configurable by command line defines
>> instead of editing luaconf.h?
>
> Several configurations affect the API. So, if you compile Lua with
> some options and then compile your code with other options, they will
> not match. Moreover, there are many configurations, and a .h file is
> more portable than a makefile. But I guess we can add '#if !defined'
> around several of them (like LUA_ROOT).
>

I‘d very much appreciate that, esp. for Lua in NetBSD.


> -- Roberto
>
- mb

Reply | Threaded
Open this post in threaded view
|

Re: Build configuration via defines

Pierre Chapuis
On Mon, Jul 9, 2018, at 15:18, Marc Balmer wrote:

> I‘d very much appreciate that, esp. for Lua in NetBSD.

Same here, it would probably help for Android / iOS (even though I think they would probably still require patching luaconf.h).

Reply | Threaded
Open this post in threaded view
|

Re: Build configuration via defines

Daurnimator
In reply to this post by Roberto Ierusalimschy
On 9 July 2018 at 23:13, Roberto Ierusalimschy <[hidden email]> wrote:

>> On 9 July 2018 at 22:44, Roberto Ierusalimschy <[hidden email]> wrote:
>> >> I assume this doesn't occur today as luaconf.h is installed as a
>> >> header onto end user systems.
>> >> There are some ways around this:
>> >>   - some of the defines (such as LUA_ROOT) probably don't need to be
>> >> available for compiling modules
>> >>   - for values that do need to exist at runtime, they could be made
>> >> available through externs, or some new function
>> >> lua_compilation_flags();
>> >
>> > I did not understand your points here.
>>
>> Lets ignore my assumption then:
>> Is there a reason that lua isn't configurable by command line defines
>> instead of editing luaconf.h?
>
> Several configurations affect the API. So, if you compile Lua with
> some options and then compile your code with other options, they will
> not match.

That is the issue I was trying to say above.
I proposed that this issue could be avoided by compiling the values
into the binary.
e.g. a new function: const char* lua_compilation_flags(const char* flag_name);

> Moreover, there are many configurations, and a .h file is
> more portable than a makefile.

Keeping a patch (or writing a sed script) is more complex than passing
an extra command line argument to your compiler.

> But I guess we can add '#if !defined'
> around several of them (like LUA_ROOT).

That would be great!

Reply | Threaded
Open this post in threaded view
|

Re: Build configuration via defines

Roberto Ierusalimschy
> > Several configurations affect the API. So, if you compile Lua with
> > some options and then compile your code with other options, they will
> > not match.
>
> That is the issue I was trying to say above.
> I proposed that this issue could be avoided by compiling the values
> into the binary.
> e.g. a new function: const char* lua_compilation_flags(const char* flag_name);

How can I use this function to define a type of a compile-time constant?

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: Build configuration via defines

Reinder Feenstra
In reply to this post by Pierre Chapuis
On Mon, 9 Jul 2018, 15:41 Pierre Chapuis, <[hidden email]> wrote:
On Mon, Jul 9, 2018, at 15:18, Marc Balmer wrote:

> I‘d very much appreciate that, esp. for Lua in NetBSD.

Same here, it would probably help for Android / iOS (even though I think they would probably still require patching luaconf.h).

I've built and used liblua 5.3.4 with success on Android and iOS. For iOS I patched the os_system function, as system() isn't available on iOS.
And made some changes in the Makefile. I didn't need to change luaconf.h

Reinder

Reply | Threaded
Open this post in threaded view
|

Re: Build configuration via defines

Pierre Chapuis
On Mon, Jul 9, 2018, at 16:47, Reinder Feenstra wrote:
On Mon, 9 Jul 2018, 15:41 Pierre Chapuis, <[hidden email]> wrote:
On Mon, Jul 9, 2018, at 15:18, Marc Balmer wrote:

> I‘d very much appreciate that, esp. for Lua in NetBSD.

Same here, it would probably help for Android / iOS (even though I think they would probably still require patching luaconf.h).

I've built and used liblua 5.3.4 with success on Android and iOS. For iOS I patched the os_system function, as system() isn't available on iOS.
And made some changes in the Makefile. I didn't need to change luaconf.h

That's a bit out of the topic but I build for both platforms.

For system, I do this in luaconf.h to avoid patching the rest of the sources:

    +#if defined(__APPLE__)
    +#include <TargetConditionals.h>
    +#if defined(TARGET_IPHONE_SIMULATOR) || defined(TARGET_OS_IPHONE)
    +#define LUA_USE_IOS
    +#endif
    +#endif

    +/* iOS does not have system() (Seriously, Apple...) */
    +#ifdef LUA_USE_IOS
    +#include <stdlib.h>
    +#undef system
    +#define system(command) ({ command ? -1 : 0; })
    +#endif

Regarding Android, I have a patch related to LOCALE:

    +#if defined(LUA_USE_ANDROID) && !defined(lua_getlocaledecpoint)
    +#define lua_getlocaledecpoint() ('.')
    +#endif

... and I have a patch in lmathlib.c to avoid using log2().

I have a few other patches for Windows / MinGW. I should Open Source that fork...

-- 
Pierre Chapuis
Reply | Threaded
Open this post in threaded view
|

Re: Build configuration via defines

Dibyendu Majumdar
In reply to this post by Daurnimator
Hi.

On 9 July 2018 at 04:27, Daurnimator <[hidden email]> wrote:
> Have you considered allowing (some) things in luaconf.h to be easily
> configurable from compiler command line options?

I find that there are two different scenarios:

1. When building Lua I want to set various options
2. When distributing a binary package I want those options frozen to
match what I had built with - I have had several crashes because Lua
headers allow stuff to be over-ridden by anyone including them.

If feasible, perhaps there ought to be a a generated config file - so
that once generated, it is frozen with respect to the build?

Thanks and Regards
Dibyendu

Reply | Threaded
Open this post in threaded view
|

Re: Build configuration via defines

Luiz Henrique de Figueiredo
> If feasible, perhaps there ought to be a a generated config file - so
> that once generated, it is frozen with respect to the build?

That is exactly the role of luaconf.h: it is meant to be edited if
needed and frozen for build and distribution. The support for
command-line defines is just a convenience.