On Tue, Oct 7, 2008 at 3:47 PM, klaas.holwerda wrote: > I started to improve the cmake stuff o wxArt2D. > So if you update, you will get some different now. > 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.
Will do! >> 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 ?? For building the project, I used the generated .vcproj files to compile with. It compiled the library and samples after I had the wxwidgets paths set up correctly. I believe Cmake actually generates its own INSTALL "project" that handles all the file relocation, etc. Unfortunately, I think it doesn't properly copy all things over (like the art folder), or it makes different assumptions than what you intended for the cmake files. It might be the reason I'm having these pathings issues for the includes and lib files. I noticed that all the sample project settings don't depend on the install folder hierarchy, only the build directory's. > 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. wxWidgets' header files do appear in its /include/wx/ folder; however, the root directory it actually installs to is the base /include folder, requiring the user to put "wx" into the path of the #include directive (e.g. #include <wx/setup.h>). > 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. Actually it'd just be: modules/wxart2d/canvas/include/ I guess what I'm used to the directory structure of other libraries, where I only need to point my include path to a base /include/ folder and then all header file paths are relative to that point. They also separate all the header files, placing them in the include folder, and then have all source files (.c, .cpp, etc.) in the src folder, instead of in those respective folders within separate modules. The current setup for wxArt2D also works, and is probably easier for the developers of it as well. There are still some problems with it though, such as having each path to a header file also have a "/include/" within it, instead of a shorter path, and also having to point the include directory path to a sub-directory of the include/ directory instead of the include/ directory itself. It's really your call on how to lay out the files in the library though, since you're the developer. > 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. It does do that, but when wxart2d is installed, that folder gets placed in the same base include folder as the wxart2d: /include/wxart2d /include/kbool However, unlike kbool, wxArt2d does not have a preceding "wxart2d" in any of its header file paths (e.g. #include "canvas/include/..."), so the wxart2d subdirectory of the base include/ directory must be added to the include directory list. This is different than kbool's header file pathing, which *does* have "kbool" preceding any paths. So I end up having to include both /include and /include/wxart2d in the include folder list. > 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. Yes, I downloaded wxLua and looked at how it organizes itself, and it does look much like how you have yours. It's not how I'd organize it, but it's not my call. >> 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. That script I provided earlier will automatically fix all paths for you, and could even be provided to other people who need to update their own projects that link to your library. I wrote it with the expectation that it would be a pain to change over the entire source tree to a new or different structure. >> 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 for taking it into consideration. It really is a nice library, just sometimes hard to dive right in. In the mean time, I'll check out the new version. I'm eager to get this library working with my stuff. ------------------------------------------------------------------------- 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
