Correct way to build wxLua applications

[solemnwarning]

I have two problems currently unsolved in my application:

How to get the correct compiler flags to build against wxlua (cflags, ldflags) - wxLua doesn't seem to install any pkg-config files, and on top of that the library names include the version number and build configuration - not easy to guess in a Makefile.

How to build bindings that build on top of the wxbind ones (i.e. reference wx types) - I'm currently setting datatype_cache_input_fileTable = { "/home/solemnwarning/wxlua/wxLua/bindings/wxwidgets/wxcore_datatypes.lua" } in my _rules.lua file, but thats obviously a hack. The distribution doesn't include or install the _datatypes.lua files normally.

Is there a recommended way of doing either of these?

Thanks

[solemnwarning]

Another observation: There aren't any symlinks and the sonames include the full version, so applications need to be rebuilt on every single version of wxlua - is the ABI intentionally broken on every version?

I'm split between building wxlua as part of the build process for my application or building Debian/Redhat packages of wxlua, but thats a lot less appealing if there is no guarantee of ABI compatibility between any versions.

[pkulchenko]

How to get the correct compiler flags to build against wxlua (cflags, ldflags)

I do use makefiles that build wxwidgets and wxlua for all supported platforms in ZeroBrane Studio, but I don't pass any custom cflags or ldflags. wxlua relies on wx-config to inform it about the module configuration and you can use it to report cpp and cxx flags (for example, wx-config --cppflags). Is that sufficient for your purposes?

How to build bindings that build on top of the wxbind ones (i.e. reference wx types) - I'm currently setting datatype_cache_input_fileTable = { "/home/solemnwarning/wxlua/wxLua/bindings/wxwidgets/wxcore_datatypes.lua" } in my _rules.lua file, but thats obviously a hack. The distribution doesn't include or install the _datatypes.lua files normally.

I don't use *datatypes.lua files for my projects, so it's difficult for me to say what use cases that may support. There was a recent discussion on adding these and the only reason why I would hesitate is that they can be easily regenerated at any time by running genwxbind.lua script (and the fact that wx_datatypes.lua is already included is a historical artifact more than anything else). I don't mind include all these files, but would like to understand why it's better than regenerating them...

There aren't any symlinks and the sonames include the full version, so applications need to be rebuilt on every single version of wxlua - is the ABI intentionally broken on every version?

We'll have to discuss this. I'm not sure what I can do if the content of the library being built (and the API produced) depends on the version of wxwidgets you are building more than on the version of wxlua that is being used. I have not introduced any incompatible changes; the only one that comes to mind was reordering of parameters in one of the methods for consistency and associated change in the version number from 3.0 to 3.1 (for wxlua).

In my own application (ZeroBrane Studio) all the checks are being done in the Lua code based on version or capability conditions, so the same application works for a DLL from any version of wxlua and wxwidgets from 2.9 up to the current master. I'm sure this is different in your case, but I'd like to understand what is different and how it can be best accommodated by the current setup.

[solemnwarning]

I do use makefiles that build wxwidgets and wxlua for all supported platforms in ZeroBrane Studio, but I don't pass any custom cflags or ldflags. wxlua relies on wx-config to inform it about the module configuration and you can use it to report cpp and cxx flags (for example, wx-config --cppflags). Is that sufficient for your purposes?

I was hoping for a way to get the flags for building against the wxlua installed on the system - for example -lwxlua-wx30gtk2ud-3.1.0.0 -lwxlua_bind-wx30gtk2ud-3.1.0.0 on my system at this time.

I don't use *datatypes.lua files for my projects, so it's difficult for me to say what use cases that may support. There was a recent discussion on adding these and the only reason why I would hesitate is that they can be easily regenerated at any time by running genwxbind.lua script (and the fact that wx_datatypes.lua is already included is a historical artifact more than anything else). I don't mind include all these files, but would like to understand why it's better than regenerating them...

Generating them from the source isn't a problem, but this is again for being able to use a system-provided wxlua package rather than building it myself. If there's no reason not to do it, I could make some Debian/Redhat packages that install them under /usr/share/ (for example), but it would be best if it was a standard thing rather than some convention I've thrown together.

We'll have to discuss this. I'm not sure what I can do if the content of the library being built (and the API produced) depends on the version of wxwidgets you are building more than on the version of wxlua that is being used. I have not introduced any incompatible changes; the only one that comes to mind was reordering of parameters in one of the methods for consistency and associated change in the version number from 3.0 to 3.1 (for wxlua).

In my own application (ZeroBrane Studio) all the checks are being done in the Lua code based on version or capability conditions, so the same application works for a DLL from any version of wxlua and wxwidgets from 2.9 up to the current master. I'm sure this is different in your case, but I'd like to understand what is different and how it can be best accommodated by the current setup.

I think wxWidgets guarantees API/ABI compatibility for the same major.minor versions (e.g. 3.0.5 and 3.0.4 should be compatible), so perhaps the wxLua libraries could be versioned as wxlua-<wxwidgets config/major/minor>.so.<wxlua api version>.

The above would mean applications linked against wxlua would only need recompiling on a new wxWidgets release or a wxlua release that increments the API version (e.g. that reordering change you mentioned).

I've been experimenting with building wxlua as part of my application due to the above issues, but it would be nice to package it up independently for distros rather than continuing down this path.

[pkulchenko]

Generating them from the source isn't a problem, but this is again for being able to use a system-provided wxlua package rather than building it myself. If there's no reason not to do it, I could make some Debian/Redhat packages that install them under /usr/share/ (for example), but it would be best if it was a standard thing rather than some convention I've thrown together.

@solemnwarning, yes, I can likely add them if you find it useful, as you are not the only one asking for this.

I think wxWidgets guarantees API/ABI compatibility for the same major.minor versions (e.g. 3.0.5 and 3.0.4 should be compatible), so perhaps the wxLua libraries could be versioned as wxlua-<wxwidgets config/major/minor>.so..

I like this idea; I build and distribute wxlua myself for my own project (on all platforms), but if it's going to work for others, I'm definitely going to consider this. Do you know enough cmake to provide a patch that generates proper names?

[solemnwarning]

I don't really know any cmake, but I'll try to take a look sometime over the next few weeks and see what I can do. I started working on packaging wxlua for Debian/Ubuntu over the weekend too.

[pkulchenko]

Sounds good. So, you'd need all wx*_datatypes.lua files generated in bindings/wxwiidgets folder added?

[solemnwarning]

If they're guaranteed not to change between systems, sure. Otherwise I was planning on just making the build process regenerate the bindings anyway.

[pkulchenko]

Would the files need to be installed in a specific location? If you are generating the bindings anyway, then the files will get regenerated as part of the process.

[pkulchenko]

I'm closing this one, but feel free to continue the discussion as needed.