On Tue, Dec 20, 2011 at 1:49 PM, klaas.holwerda <n...@klaasholwerda.nl> wrote:
> And 2.9.3 has the same OpenGl issue.
See other email about having fixed it. (hopefully)
> Apart from that, all that is compiled is rather different from what it was.
> Libraries named different, locations also.
> The naming was rather handy for me, to have debug/unicode/release versions
> etc. seperated when
> detecting stedit and wxlua (after install).
> Now i don't know what to do.
I didn't get too fancy since I'm just starting to iron-out the details
for the CMake scripts.
> WxStedit becomes part of wxLua, using an include.
> But what if there is more flavors of wxWidgets (univ, unicode etc. ).
> How will i now what was compiled in what fashion?
I give my out-of-tree build dir the complete build name, compiler,
32/64... to fully describe it.
> Or i need to switch over to the same big project approach with includes, in
> that case it does not
> matter, since it is all compiled as one.
> So no more find packages (and install) for wxstedit and wxlua in that case. A
> bit against Cmake its
> FindXXX method, but then again it is easier.
1) The FindXXX methods could be nice, but for small libraries like
wxstedit seem like overkill.
2) Simply adding the sources to your CMake project ensures that they
are built *exactly* the same as your project and the dependencies work
great if anything gets updated.
3) An alternative would be to create a USE_wxStEdit.cmake file in the
build dir that another app/lib would call
INCLUDE("USE_wxStEdit.cmake") to have the correct definitions,
variables for libs, and whatnot set.
I think for me #2 and #3 should suffice. The FindXXX requires too much
information that is not provided by the default FindwxWidgets.cmake
script (version, unicode, debug). #3 is dead simple, the generated
file in the build dir contains exactly what is needed to link to that
library which is known when it's configured. (OpenCV does something
like this).
You may be interested in this, I have a wrapper FIND_WXWIDGETS()
function to give much better info about why wxWidgets wasn't found. I
also find the version number and get linking to stc/scintilla right
for 2.8/2.9.
http://wxlua.svn.sourceforge.net/viewvc/wxlua/trunk/wxLua/build/CMakewxAppLib.cmake?revision=33&view=markup
> It seems an always use the source code approach, but only when using Cmake,
> which i don't mind ;-)
> But what when installing the libraries in the end. That can become confusing
> on linux, wonder if its
> a wxWidgets problem only to have several types of libs, and maybe the problem
> is soon gone when
> there is only unicode. And debug is all local to the project (before install).
>
> Hmmm, i am confused now what is best :-(
I really like linking together the CMake files since you get a great
Visual Studio or Code::Blocks project that you can use to build,
debug, etc... The only downside is that rebuilding cleans a little
more than it should. They need to have a 'clean' that only cleans the
current project, not every dependent project.
> We best find a single Cmake approach for wxCode components. Looking around
> there, it seems you
> Cmaked yours already.
>
> What is your idea about all this?
There are some other projects in wxCode that I would have liked to
use, but was afraid to get involved in their build system. I think a
clear set of CMakeLists.txt files to allow you to link a few wxCode
projects together with your own executable makes a lot of sense. I
have tried to make everything in CMakewxAppLib.cmake and
CMakeFunctions.txt (I want to rename both of them eventually) so they
don't overwrite anybody's settings.
You'll notice that I have some wrapper functions for ADD_LIBRARY() and
ADD_EXECUTABLE(), ADD_LIBRARY_FULL() and ADD_EXECUTABLE_FULL() which
keep track of what has been added so that you can make lists of them
and do a lot of interesting things. It would not even be so hard to
setup an automated build system.
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.
Eventually, we can add a CMakeLists.txt at the root of
wxCode/components to make it very simple to load all of them that have
CMakeLists.txt. In fact, I already do this, but I also include wxLua
and two other personal projects. What stops people (including myself)
from using wxCode components is that it's hard to learn how to build
other people's projects and if we can unify them everything becomes
simple and the wxCode projects can be tried with little effort.
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
