Re: [wxlua-users] stedit lib location

[klaas.holwerda <ng...@kl...>]

Hi John,

Tested it for as far as possible.
I am still adding this in the stedit and wxlua cmakelists files.
Having all generated libs in one location makes things easier to get form the outside.

set (LIBRARY_OUTPUT_PATH ${wxStEdit_BINARY_DIR}/lib )

set (LIBRARY_OUTPUT_PATH ${wxLua_BINARY_DIR}/lib )
set (EXECUTABLE_OUTPUT_PATH ${wxLua_BINARY_DIR}/bin )

Wonder if you could add them, and maybe skip them if files are includes from a higher level (as you 
do i believe) using a variable set at higher level.
That works well i experienced for a situation here.

The install of headers is done now.
But i do not see (although you do generate them in the build dir):
/usr/local/share/wxlua/wxLua-config.cmake
/usr/local/share/wxstedit/wxStEdit-config.cmake

If they would be there,  i see, i can not already use them to find all that is in /user/local/lib 
and /user/local/include/wxlua and /user/local/include/wx/wxstedit.
It would need to contain different paths in case using of an installed devel version of wxlua and 
wxstedit.
I still use WXLUA and WXSTEDIT environment variables to the source location for some stuff.
For the moment like this (works for old (2.8) and new (2.9.3) wxWidgets with wxLua):
http://wxart2d.svn.sourceforge.net/viewvc/wxart2d/trunk/wxArt2D/packages/wxart2d/share/wxlua/
http://wxart2d.svn.sourceforge.net/viewvc/wxart2d/trunk/wxArt2D/packages/wxart2d/share/wxstedit/

Wonder also if putting the wxstedit headers in /usr/local/include/wx-2.9 would be better, to prevent 
confusion with old pre 2.9 wxwidget and cmake wxstedit versions.
Not sure what is best here.

Some more on the testing and remarks down here.

On 14-6-2012 6:47, John Labenski wrote:
> wxLua is a different story. I should move the files around in the wxLua
> project so that the headers are included as "wxlua/wxlua.h" and
> "wxlua/wxluadebug/wxldebug.h" whereas now they are
> "wxlua/include/wxlua.h" and "wxluadebug/include/wxldebug.h" which is
> strange, especially when installed to/usr/  include.
[Klaas]
I think I was the cause of this problem in the first place, had it like this in art2d.
Finally I decided to move all headers to one include directory, but in there still per/as module.

.....\wxLua\include\wx\luamodule
.....\wxLua\include\wx\wxlua
.....\wxLua\include\wx\wxbind

Although I preferred to have headers and source in the same directory tree, as you say with install it did not fit very well.
Also like this much less include paths of course.
In the source files i use:

#include "wx/luamodule/somefile.h"

In here luamodule as a sort of namespace in wx headers.

Eventually the end up here in my case.

/usr/local/include/wxart2d-1.2/wx/luawraps/luawrap.h
Etc.

But this could also be a good idea (same as wxWidgets its headers for submodules):

/soft/usr/local/include/wx-2.9/wx/luawraps/luawrap.h
Etc.


> In order to avoid overwriting people's system Lua headers I've put all the
> installed #includes into "include/wxlua/*", an extra "wxlua" dir.
> This means that an extra #include search path is required if they're installed
> to/usr/local/include/.
[Klaas]
Exactly, the above prevents that, or gives more freedom.
Although I still use a directory (with version), deals with the not overwriting "people's system headers".
But as you do now, should be oke.


>> /home/klaas/soft/wxLua/modules/lua/src/luaconf.h:275:31: error:
>> readline/readline.h: No such file or directory
>>
>> Do not know how this should be fixed using prefix something??
> You need to install the readline-devel package. While it's not strictly
> necessary, it is a tiny package and every Linux distribution has it.
[Klaas]
I understand, but since I do not have that freedom in other cases, I often have my own /home/klaas/usr/local.
If this is set for say wxLua cmake:
BUILD_INSTALL_PREFIX ="/home /klaas/soft/usr/local/usr/local"

It somehow feels this needs to be added automatically:

INCLUDE_DIRECTORIES(  "${ BUILD_INSTALL_PREFIX }/include" )

(understand that wxstedit, wxwidgets etc. is all installed there too, it is like an extra /usr/local ).

  

> Remove it from wxLuaBind_COMPONENTS in the cmake gui and it won't be
> built and hopefully not needed for the rest of the build either.
[Klaas]
That was not enough,
wxWidgets_COMPONENTS also needs media removed.

> Ok, but put into a wxlua/bindings directory.
[Klaas]
Great. With the configure scripts wxLua-config.cmake wxStEdit-config.cmake also there, not much should be missing to make it work.
  

> You mean you had to include "wx/generic/progdlgg.h"? That shouldn't ever
[Klaas]
I think It was before I discovered I was mixing up headers file from older versions of wxLua, or something.
Can not find it back, still it was a copy paste, so where did I find it?? :-)
In any case, it only included "wx/generic/progdlgg.h" at that point, and now the #include "wx/progdlg.h", which is what is of course is the thing to do.
When I find this problem again will come back on it.


>> And I need to compile wxWidgest with -fPIC again (something to do with
>> shared libraries in lua, see mailinglist archive):
>>
>> make CXXFLAGS=-fPIC CFLAGS=-fPIC
> You shouldn't have to do this. I've never had to, you're building 64 bit?
[Klaas]
Yes, it is 64 bit. And this problem was the same on Ubuntu 64 bit.
Without it, it get weird reallocation errors when linking things.

BTW had several problems with linking to wxLua.
At least this linking order seems to be right (from left to right, more right is needed by more left.):

wxLua_LIBRARIES =>  wxlua_bind-wx29gtk2u-2.9.4;wxlua_debug-wx29gtk2u-2.9.4;wxlua_socket-wx29gtk2u-2.9.4;wxlua-wx29gtk2u-2.9.4;wxlua_lua-wx29gtk2u-2.9.4;lua

Is that the right order in dependencies?

Thanks!

Klaas