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
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
wxlua-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wxlua-users
