Re: [wxlua-users] Cmake how?

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

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