On 21-12-2011 0:30, John Labenski wrote:
>> 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.
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.
And on Linux, imagine installing wxLua, what is it (unicode or not etc.)
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.
>
>> 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.
Yes i get that. That is why for wxCode like stuff ( just one lib), your
approach might be better.
But if others start installing the same libraries (on Linux), and i would
install wxLua/wxStedit as
part of wxart2d, it becomes scary.
>
> 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.
That is what FindXXX.cmake + UseXXX.cmake is about i think.
Maybe sometimes like in wxCode, the FindXXX is not really needed, and only the
last will do.
>
> 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).
Right, i think the generalized approach of Find_Package in Cmake, is working
with XXXConfig.cmake.
The generalized FindPackage uses that file. And together with UseXXX it is
complete.
Which for wxart2d i do generate, using the assembled lists like you do.
I somehow feel that what you suggest is the same, but less formal. The major
ingredient, is to have
such a file (call it XXXConfig.cmake), with the settings.
Find_Package only looks for paths where it can be found.
I myself do something in between (still have a FindwxArt2D.cmake but should not
be needed) :
http://wxart2d.svn.sourceforge.net/viewvc/wxart2d/trunk/wxArt2D/packages/wxart2d/share/wxart2d/FindwxArt2D.cmake
See INCLUDE(${WXART2D_DIR_SHARE}/wxArt2DConfig.cmake)
Used like:
FIND_PACKAGE( wxArt2D )
IF( WXART2D_FOUND )
INCLUDE(${WXART2D_USE_FILE})
>
> 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
Yep my own FindwxWidgest, sets thing like lib name pre/post stuff variables to
use by the user.
That is how i synchronize libraries to wxLua and wxWidgets looking at how they
are named.
I also, like you do, have functions, to assemble lists of what was added in
terms of libraries and
includes, defines etc.
(wxart2dMacros.cmake).
http://wxart2d.svn.sourceforge.net/viewvc/wxart2d/trunk/wxArt2D/packages/wxart2d/share/
I needed that to later generate a cmake configure file for users of the
software.
I still need the build.cfg file (wxwidgets produces that), and seeing your
trick to get version.h
info, i think that is better, will copy that ;-)
And other things you talk about, might be interesting for me too.
> 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.
That is right, i also do like to have everything in one. And sofar i did it
using
"include_external_msproject", which works for VC.
code blocks i just included into it into the workspace.
But like you do, it just is one big pile of code producing libraries etc. Which
is simple, and often
simple is best.
I am just trying to oversee the consequences, where it might go wrong.
>> 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.
To me too!
But if every wxCode module produces a library, there might be a problem at
install stage.
That is what i try to figure out.
> 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.
Yep, will look how you did it, maybe i can improve my own versions, or just use
yours.
It helps to see how others solve a similar problem.
_ADD_SUBDIRECTORY did not know about the underscore, to call what i think is
the original version??
That's a nice trick.
>
> 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.
Maybe add your component checking in there and have something which can be used
in general.
>
> 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.
I get it.
> 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.
I am all with you.
We need something simple. The package system from Fransesco did not work out.
Hopefully this is the solution.
Thanks,
Klaas
------------------------------------------------------------------------------
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
