On Thu, Jun 14, 2012 at 4:40 PM, klaas.holwerda <[email protected]> wrote:
>
> 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 )
Ok, done.
> 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
I not sure if what these files contain is useful or not. They're what
cmake generates, but they'll be wrong once installed or if moved. I
think I may try to use REGEXP to replace the hard coded absolute path
with a relative path from ${CMAKE_CURRENT_SOURCE_DIR} so that when
installed to .../share/wxlua/wxLua-config.cmake (for example) it will
still be able to correctly point to the libs and headers.
I also think that putting their dependencies on the wxWidgets libs is
nice, but may be more problematic than helpful. In other words, let
the person who is linking to wxStEdit/wxLua and wxWidgets control the
cxx/linker flags and libs for their app/lib. Do you agree?
> 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/
These look very nice.
> 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.
wxLua and wxStEdit still build in 28 without problems, so I think I
should skip the version number.
> Finally I decided to move all headers to one include directory, but in there
> still per/as module.
>
> .....\wxLua\include\wx\luamodule
>
> Although I preferred to have headers and source in the same directory tree,
> as you say with install it did not fit very well.
I have been thinking that this might be the best.
wxLua/
build/
docs/
wxlua/
wxlstate.h
wxlstate.cpp
the headers and sources currently in modules/wxlua/*
debug/
wxldebug.h
wxldebug.cpp
the headers and sources currently in modules/wxluadebug/*
lua/
all of modules/lua/
and so on.
While being slightly unconventional,
1) Makes it easy to load the .h/cpp files in an editor since they're
in the same dir
2) #include "wxlua/wxlstate.h" or "wxlua/debug/wxldebug.h"
3) Only one -I"/root/of/wxLua/" include search path needed to get them all.
> [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" )
I don't understand, what automatically adds this? I don't think I have
any include paths using the BUILD_INSTALL_PREFIX.
Extra paths can be added in the CMake GUI by checking "advanced" and
adding them to CMAKE_C/CXX_FLAGS. To set the linker path use
CMAKE_EXE_LINKER_FLAGS.
> 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.
Yes, sorry. I separate the two since someone may want to link to less
of wxLua than they do of wxWidgets. I suppose I could give a cmake
error if you have less in wxWidgets_COMPONENTS than you do
wxLuaBind_COMPONENTS.
> 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?
wxlua_bind-wx29gtk2u-2.9.4;wxlua_socket-wx29gtk2u-2.9.4;wxlua_debug-wx29gtk2u-2.9.4;wxlua-wx29gtk2u-2.9.4;wxlua_lua-wx29gtk2u-2.9.4
This order would be better. I've named the lua lib
wxlua_lua-wx29gtk2u-2.9.4 so we definitely link to our own. Eventually
I will make it so that you can link to a system version of Lua or any
other one, perhaps even LuaJit.
Regards,
John
------------------------------------------------------------------------------
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