Hi Tanguy, Tanguy Krotoff wrote: > Fix: > http://dev.openwengo.com/trac/openwengo/trac.cgi/changeset/9101 > http://dev.openwengo.com/trac/openwengo/trac.cgi/changeset/9102
Thank you. > I've improved a bit the error message about "_INCLUDE_DIR is empty". At > least this error message exists, *with CMake it does NOT exist*, CMake > let you alone with this!!! >From what I can tell, that's because there was no obligation to define INCLUDE_DIR or INCLUDES (although this is now policy for modules). >> Is there any example of a cmakefile using standard cmake and owbuild >> so that I can compare the benefits that the owbuild macros bring? > > http://dev.openwengo.com/trac/openwengo/trac.cgi/wiki/OWBuild Thanks for that example. I'm not completely convinced by the argument "We have 100s of build files, so we need a new API to refactor common code". I do believe that owbuild can give compelling benefits to a project with lots of dependencies and modules - what would be nice, for example, would be to show very common situations where owbuild shortens cmakefiles or makes them easier to understand. In this situation, the tricky thing was figuring out all the indirection which got me to the error message; I didn't know that I shouldn't use FindAlsa.cmake, it wasn't clear to me that every find_package should define INCLUDE_DIR or INCLUDE_DIRS, and I didn't know anything about libs-3rdparty-cmakelists (or the fact that script in there get run transparently across ow_add_public_include_dirs). We need to do a better job explaining how owbuild's conventions diverge from cmake's (if they diverge). > I like to troll so let's troll well: Well, I don't think I was trolling, but... > It's like people saying: "Java is shit, what is heritance, what is a > class + private and public? do we need that anyway? these guys are > stupid, I prefer the good old C" (1) Staying with the programming languages idea, it would be a little like if I proposed that we write software in D. D's a lovely language, advocates swear by it. Why wouldn't you want to use the best programming language out there? The problem is that if we started developing D, we'd have to teach all the existing developers how to code D first. Our pool of volunteers would be much reduced, because there just aren't a lot of D programmers. And for those who want to learn D, there isn't much in the way of books or documentation, so they're going to have a hard time doing it by trial and error. What you would have to do, which both Python and Ruby have done, is work on getting interpreters and compilers included in distributions, start advocating and writing software in the language, get books published on the language, and try to catch a wave of interest (Ruby got it with Ruby on Rails, Python got interest through Unix sysadmins). Then, when you have a critical mass of programmers and documentation, propose writing software in it. Of course, if you're only writing software for your own use and enjoyment, you can use any language you want. Which brings us to OWBuild... > The fact is: > you want to build a software with a *lot* of dependencies (FFmpeg, Alsa, > Gaim, cURL, IAXClient...) with a *lot* of internal libraries (Wenbox, > IMWrapper, SipWrapper...) on 3 different OS (Linux, Windows, MacOSX) > + of course you want to switch all libraries from static to shared (why > the hell they invented .dll, .so, .lib, delspec export...) > + you want to choose between svn repo/system 3rd party libraries > + you want to compile each library separately (for example webcam or > pixertool) + other stuffs like this > then you will end up with something similar to OWBuild in the idea, if > you are smarter than me your OWBuild will be better/easier/whatever else > it will be a big mess. We need to make a compelling case for owbuild. We need to be sure that the abstraction layer works well, and we need to document how to use it, so that other projects can use it. And then we need to work with other projects so that they *do* use it. And if they're happy with it, maybe we'll have to remove all the ow prefixes, so that it can be upstreamed to cmake (if Brad King likes it) and then everyone can benefit from it, and anyone who learns CMake will automatically be able to look at an OpenWengo cmakefile, and know what's happening. The first step in that is to make a compelling case for someone to learn OWBuild. Just saying that it makes it easier to handle a ton of dependencies doesn't help people understand what you mean by that any better, nor does it make people believe it more. A good way to make that compelling case might be to show, for some well-defined project, which uses cmake now, how much shorter, more cross platform and nicer their CMakeLists.txt are if they use owbuild. I know this will take time, but it will be worth it for the adoption of owbuild afterwards. > Like we say in french "faut pas jeter le gamin avec l'eau du bain" In English, we have the same: "Don't throw out the baby with the bathwater". We also say "an ounce of prevention is worth a pound of cure" :) Cheers, Dave. -- Dave Neary OpenWengo Community Development Manager Email: [EMAIL PROTECTED] _______________________________________________ Wengophone-devel mailing list Wengophone-devel@lists.openwengo.com http://dev.openwengo.com/mailman/listinfo/wengophone-devel
