Re: [wxlua-users] stedit lib location

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

On 15-6-2012 6:08, John Labenski wrote:
> 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.
Did not know that CMake generated them. I thought you made them. What exactly triggers that??

>   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? 

Yes, already simplified my own a little with that in mind. But some typical wxWidgets variables i 
keep around, like wxWidgets_PORT etc.
And also a wxLua_wxWidgets_SELECTED_CONFIG, to check that all packages (find_package()) are in sync 
with the wxWidgets choosen.
Like all shared, are all static like the wxWidgets choosen, mixing them gives weird problems. Like 
multiple registering of the same class at runtime.

>> 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.

Use what you want, since these/such files would be best placed in wxStedit/wxLua itself, if i 
understand well CMake its intention.
I just placed there to have them. And since i install them to /usr/local/share/wxlua i more or less 
cheating, as if wxLua installed them there itself ;-)

>
>> 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.
Oke. It was also more to have a version number for the wxstedit and wxlua headers installed.
It happened to be several times that i was using headers from /usr/local from an older version of 
wxstedit/wxlua, without me knowing that.
But maybe it is more a matter of being alert on such a things.

>
> and so on.
>
> While being slightly unconventional,
> 1) Makes it easy to load the .h/cpp files in an editor since they're

That is indeed annoying when working without an IDE.
> in the same dir
> 2) #include "wxlua/wxlstate.h" or "wxlua/debug/wxldebug.h"
That is the same as collecting all headers in the same include directory, and make the same 
directory structure in there.
Like i do currently.
> 3) Only one -I"/root/of/wxLua/" include search path needed to get them all.
That is also the same for me.

But i also did see what you propose in more Linux packages, so not that strange i think.
Still after install, the will be placed  /usr/local/include and /usr/local/lib, meaning in the end 
the directory structure in say /usr/local/include/wxlua, must be the same as in the wxLua source 
tree when it comes to headers.

>
>> [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.
That is what i say. And that it might be a good idea o add it standard when using a central install 
directory.
Like if wxstedit uses  BUILD_INSTALL_PREFIX location the same as wxLua and wxWidgets wxArt2d etc., 
it is clear that wxLua
will need to look there also for the installed wxstedit headers.
But thinking again, it is of course wxSteditConfig.cmake which will deliver such a location.
Anyway i myself do automatically add INCLUDE_DIRECTORIES( "${ BUILD_INSTALL_PREFIX }/include" ) in 
wxart2d, assuming where i install, is very like where other stuff is installed, and should be taken 
from. That is the same for the normal /usr/local. CMake looks automaticallly in there, you need to 
force to not to do that.
But it not big problem, i can add such includes by hand in the cmake-gui as you say.

>
>> 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.
Right, that would help. Like a hint to the user.

>
> This order would be better. I've named the lua lib
> wxlua_lua-wx29gtk2u-2.9.4 so we definitely link to our own.
Noticed that. That is fine i think.
> Eventually
> I will make it so that you can link to a system version of Lua or any
> other one, perhaps even LuaJit.
It is not that big, i don't mind it. But for sure that would be more elegant.
All in all very happy you started using CMake too, it already makes things simpler for me :-)
It is still amazing how much effort is/i needed to make it all work correctly in all situations :-(

Regards,

Klaas