Hi, I started to improve the cmake stuff o wxArt2D. So if you update, you will get some different now.
It looks you are working on windows, and that is what i am testing currently. With cpack.exe -C debug and the nsis.sourceforge.net and www.7-zip.org You can make a zip and exe distribution. It has its include files in $installdir /wxart2d Maybe you should take a look at it first, i had to change things a bit to make it all work. Also see the new myapp directory. Bionic Badger wrote: > On Mon, Oct 6, 2008 at 9:40 AM, Klaas Holwerda wrote: > >> $(WXART2D)/include/wxart2d i don't have it?? >> Where did it come from? >> >> Did you build outside the wxArt2D source tree? >> > > With Cmake I configured it to build the libraries in a separate > folder, and then ultimately install it into a third: > > Source code path: C:/Sourcecode/Libraries/wxart2d.source > Where to build the binaries: C:/Sourcecode/Libraries/wxart2d.lib > > CMAKE_INSTALL_PREFIX = C:/Sourcecode/Libraries/wxart2d > > This keeps the source files separate from the build files, and then > produces a final installation directory containing only. The > installation directory, $(WXART2D) = C:/Sourcecode/Libraries/wxart2d > contains the following (when cmake installed it for me): > So how do you install on windows. Did you use nmake ?? > bin/ > include/ > -- kbool/ > -- wxart2d > lib/ > -- wxart2d > -- kbool.lib > share/ > Different now. bin wxart2d -- wxart2d.h -- canvas etc. kbool -- header kbool lib > (I had to copy over art/ later to get the samples working) > Oke, do need to take care of that too. > So the above should have everything that is needed to compile apps > using wxArt2D, as all the lib and .h files are there. > > When I add the include path to my include folder list, it ends up being: > > $(WXART2D)\include\wxart2d > Now is i think $WXART2D_DIR/wxart2d > I really would prefer it to just be "$(WXART2D)\include" for three > reasons: 1) to keep all wxArt2D include file paths prefixed with > "wxart2d/" in the same manner that wxWidgets has "wx/" before its; But the prefix in wxart2d is the name of the module, and that is to be able to use those module separately and without a wxart2d in it. So in principle that is the same as the "wx". I believe we did have the wxart2d prefix one day, but somehow we removed it for a reason, being many more includes needed. I now made such that on Linux it installs in /include/wxart2d. This is what wxWidgets does. > 2) > to keep a more standard vanilla "include" path instead of an > "include/wxart2d" which is is how most libraries do; Its complex, since headers files in the samples are found relative to the modules directory, and there there is no wxart2d in the paths. So when compiling samples all header includes would be different, from includes after install. I think the current approach is best to leave the structure during build and install the same. Only if in each module the include would be in say: modules/canvas/wxart2d/include it would work. But that i find rather ugly. > 3) the kbool > library is pathed from include/ instead of include/wxart2d. > kbool is a thirdparty something. so it has its own. I like it to be on Linux like /include/kbool. > The third reason above is the real reason why I have to use both > "$(WXART2D)\include" and "$(WXART2D)\include\wxart2d" in my include > paths. In include directives in include files, such as wxart2d.h and > canvas/include/booloper.h, both require "kbool/booleng.h" or something > like that, which require just "$(WXART2D)\include" as the include > folder. This isn't so bad in itself, but it's redundant to have to > also include a subdirectory of that directory in the include paths. > That should be improved now. Or at least the idea is that there are only $WXART2_DIR/wxart2d and $WXART2_DIR/kbool > >> I like to be able to seperate modules, so that is why i made them relative >> to the modules directory. >> > > Separate modules are definitely good. I'm not asking to abandon that > practice. I'm just seeking out a more consistent organization method > at least with respect to interfacing the library itself after it is > compiled. > That oke, but i hope you understand that modules and its include directories requires to do things a little different. See also wxLua same problem/approach. > >> Therefore its not clear to me why you think its better to do this: >> >> #include canvas/include >> #include wxart2d/canvas/include >> > > No, this is exactly what I want to avoid. I'd prefer to have it only > use the second include directive you've depicted above: > > #include <wxart2d/canvas/include/...> > And i meant to say that i need #include canvas/include are else by samples and apps fall apart, unless i change all module include dirs to something else. So really its not that simple. > so that everything is prefixed with "wxart2d" for organization > purposes. It'll also ensure that other libraries such as kbool can be > placed in the base include folder without need for a separate path in > the folder list, so that I can just include: > > #include <wxart2d/canvas/include/...> > This is a problem > #include <kbool/...> > This is already the case, and should be. > > It just seems like this would make more sense. > I agree, but because i choose to strictly seperate things into modules, it seems that we needed a different approach. But lets wait until i finished a bit more what i am working on now. Thanks, Klaas ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Wxart2d-users_dev mailing list Wxart2d-users_dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxart2d-users_dev