On Wed, Dec 21, 2011 at 10:13 AM, klaas.holwerda <n...@klaasholwerda.nl> wrote:
>> I give my out-of-tree build dir the complete build name, compiler,
>> 32/64... to fully describe it.
> Oke, but that i have to explain to users wanting to use wxart2d with wxlua.
> Saying if you want to compile different versions( deb/uni) of wxart2d with
> wxLua, you have to make
> paths like this and that, else i don't know how to detect it.
No it's far simpler. You simply add a variable in your CMakeLists.txt file
set(wxLua_ROOT_DIR ${wxLua_ROOT_DIR} CACHE PATH "Set the path to the
root directory of wxLua containing the CMakeLists.txt file")
They set this variable in the cmake-gui or the command line and you
can easily check it in your CMakeLists.txt file with
IF (EXISTS ${wxLua_ROOT_DIR}/CMakeLists.txt)
# Note that wxLua could be anywhere
ADD_SUBDIRECTORY(${wxLua_ROOT_DIR} ${CMAKE_BINARY_DIRECTORY}/wxLua)
ELSE()
MESSAGE(WARNING "Invalid path to the wxLua library : '${wxLua_ROOT_DIR}'")
ENDIF()
When the user builds wxArt2D they will also build wxLua with the same settings.
Getting the Config stuff worked out may take a little longer for me,
but I think it's necessary and will do it.
> And on Linux, imagine installing wxLua, what is it (unicode or not etc.)
There is no good solution to this, the libs can be
libwxlua_gtk2ud_2.9_blah.so, but the executables can't really contain
unicode/debug info in their names so the last one you install
overwrites the previous ones. I imagine that people that are building
or working on an app would only choose one flavor and use that. If you
are a developer of a library that uses wxLua/wxArt2D then, yes, you do
have to worry about testing all the build types, but you wouldn't want
to install them.
> I find my way out, but for the starting developer it is all to complex. They
> think configure/make
> install.
> Which is close enough to cmake-gui/configure/make install.
> On windows it is always more XXX_ROOT_DIR driven, but even there install is
> possible.
...
> But if every wxCode module produces a library, there might be a problem at
> install stage.
> That is what i try to figure out.
Once the libs are given full names and the BlahConfig.cmake file the
install will work ok. I never install libraries like these, I just
leave them in their build dir in my home directory, but I understand
that others do want to install them.
>> I am open to suggestions about the two files I have above. I will add
>> a function to create a wxlike-libname, wx{your-lib-name}[u][d]-2x...
>> to make that part easier.
>
> Maybe have a look at my FindwxWidgets, it seems you use the one from Cmake
> itself.
> Which i think is not very good. If we manage to sync up a common
> FindwxWidgets delivering what we
> need, we might be able to get it into Cmake and/or wxCode
> Like your WX_HASLIB stuff, is very much like i do search for all available
> libs, unless i missed
> something.
Your FindwxWidgets looks nice. The CMake one in 2.8.6 is awful, it
doesn't give any indication about why it failed. I would like to have
one that prints out exactly what was found since the idea is that the
user will need to select one of them.
> We need something simple. The package system from Fransesco did not work out.
> Hopefully this is the solution.
It was a shame, I really appreciated his help on Bakefile and it
did/does work well, but I have been struggling with it since. Even
doing the simplest things took hours and I still can't get configure
to respect --prefix. I will probably keep them around and CMake will
be an additional build system.
I do not love relying on the CMake executables, but the ability to
configure the directories for dependent libraries sure beats using
environment variables. I think the key to getting the most out of
CMake with wxCode is being able to load them all (the maintained ones)
into Visual Studio. This allows people to very easily browse them,
build and run the samples, and allows components to very easily link
with each other.
--------------------
In any case, I won't have too much time to work on anything for the
next couple weeks.
Regards,
John
------------------------------------------------------------------------------
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create
new or port existing apps to sell to consumers worldwide. Explore the
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev
_______________________________________________
wxlua-users mailing list
wxlua-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxlua-users
