Re: [Wengophone-devel] Still a compilation problem...
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.
Re: [Wengophone-devel] Still a compilation problem...
Le 4 janv. 07 à 17:06, Tanguy Krotoff a écrit : Because there are no good libraries/tools (or buggy bindings) available for the D language. Do you know why Java was adopted so quickly by everybody? probably because of marketing from Sun yes, also because of the JVM, portability helped aswell but mainly because the set of libraries was simply AMAZING when released: xml, network, regexp, gui, ssl, thread, mutex... Using C you need to choose/intall/use 10 different libraries that are not always well designed/documented/tested or portable Using C++ you just need to install Qt and you have almost everything you need. That's why Qt is so nice and will be more and more popular over time! In C++, the problem is same as in C, you need to install lots of external libraries to really code something. In WengoPhone we use Qt, boost, curl,... Qt is good but is not THE solution. A language without good libraries worths nada, peanuts, que dalle and I think D is dead if they try to create yet another language since what people need is a complete framework And this is also why script languages work so well... They provide complete framework to do almost everything. Future will tell us... -- Philippe BERNERY [EMAIL PROTECTED] http://dev.openwengo.org ___ Wengophone-devel mailing list Wengophone-devel@lists.openwengo.com http://dev.openwengo.com/mailman/listinfo/wengophone-devel
Re: [Wengophone-devel] Still a compilation problem...
Hi Philippe, Philippe BERNERY wrote: Le 2 janv. 07 à 22:37, Dave Neary a écrit : CMake Error: portaudio: alsa_INCLUDE_DIRS and alsa_INCLUDE_DIR empty It seems alsa development files are now installed on your workstation. Thanks for the answer, but... [EMAIL PROTECTED]:~/src/wengophone-2.1$ dpkg -l libasound*-dev snip ii libasound2-dev1.0.10-2ubuntu4 ALSA library development files [EMAIL PROTECTED]:~/src/wengophone-2.1$ dpkg -L libasound2-dev snip ... /usr/include/alsa/asoundlib.h ... snip ... /usr/lib/libasound.a /usr/lib/libasound.la /usr/lib/pkgconfig /usr/lib/pkgconfig/alsa.pc /usr/share/doc/libasound2-dev /usr/lib/libasound.so So everything's installed fine. If I run find_package(alsa) it's found fine. But FindAlsa.cmake doesn't set alsa_INCLUDE_DIR or alsa_INCLUDE_DIRS. And in any case, FindAlsa.cmake doesn't get run before we call ow_use_private_libraries(alsa). I have attached a patch I used to work around the problem - it calls PKGCONFIG for alsa, which sets alsa_INCLUDE_DIR, and the compile goes fine. There may be a better way to fix this - I'm open to suggestions. This shows one of the problems of using owbuild, though - it seems like there are only 4 or 5 people who can start answering questions like these - I spent a couple of hours tracking down this problem. By using owbuild macros, rather than standard cmake, we're reducing the number of people who can help when we have a problem, and increasing the learning curve for new people coming into the project. Is there any example of a cmakefile using standard cmake and owbuild so that I can compare the benefits that the owbuild macros bring? Cheers, Dave. -- Dave Neary OpenWengo Community Development Manager Email: [EMAIL PROTECTED] Index: libs/3rdparty/portaudio/CMakeLists-internal.txt === --- libs/3rdparty/portaudio/CMakeLists-internal.txt (revision 9083) +++ libs/3rdparty/portaudio/CMakeLists-internal.txt (working copy) @@ -1,3 +1,5 @@ +include(UsePkgConfig) + ow_create_shared_library(portaudio) ow_add_public_include_dirs( @@ -85,6 +87,8 @@ endif (PORTAUDIO_OSS_SUPPORT) if (PORTAUDIO_ALSA_SUPPORT) + PKGCONFIG(alsa alsa_INCLUDE_DIR alsa_LINK_DIR alsa_LINK_FLAGS alsa_CFLAGS) + ow_add_sources( pa_linux_alsa/pa_linux_alsa.c ) ___ Wengophone-devel mailing list Wengophone-devel@lists.openwengo.com http://dev.openwengo.com/mailman/listinfo/wengophone-devel
Re: [Wengophone-devel] Still a compilation problem...
Le 2 janv. 07 à 22:37, Dave Neary a écrit : CMake Error: portaudio: alsa_INCLUDE_DIRS and alsa_INCLUDE_DIR empty It seems alsa development files are now installed on your workstation. -- Philippe BERNERY [EMAIL PROTECTED] http://dev.openwengo.org ___ Wengophone-devel mailing list Wengophone-devel@lists.openwengo.com http://dev.openwengo.com/mailman/listinfo/wengophone-devel
Re: [Wengophone-devel] Still a compilation problem...
Dave Neary wrote: I have attached a patch I used to work around the problem - it calls PKGCONFIG for alsa, which sets alsa_INCLUDE_DIR, and the compile goes fine. There may be a better way to fix this - I'm open to suggestions. http://dev.openwengo.com/trac/openwengo/trac.cgi/browser/owbuild/trunk/libs-3rdparty-cmakelists/alsa/CMakeLists.txt This is a script that sets alsa_INCLUDE_DIRS (via function ow_add_public_include_dirs()) since FindAlsa.cmake don't do it All scripts inside libs-3rdparty-cmakelists were made because Find*.cmake are a bit messy: all the guys named their variables like they wanted, some defined _INCLUDE_DIR, others _INCLUDE_DIRS and of course sometimes like in FindAlsa.cmake case just nothing. Sometimes everything is uppercase, sometimes it is not (like original FindBoost.cmake for example) So scripts from libs-3rdparty-cmakelists are supposed to solve this problem: everything looks and works the same Fix: http://dev.openwengo.com/trac/openwengo/trac.cgi/changeset/9101 http://dev.openwengo.com/trac/openwengo/trac.cgi/changeset/9102 alsa was declared after portaudio so of course portaudio couldn't use alsa, simple as that (and this not particulary due to OWBuild, it's like using a variable without declaration: it simply does not work) 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!!! This shows one of the problems of using owbuild, though - it seems like there are only 4 or 5 people who can start answering questions like these - I spent a couple of hours tracking down this problem. By using owbuild macros, rather than standard cmake, we're reducing the number of people who can help when we have a problem, and increasing the learning curve for new people coming into the project. ok so let's rewrite everything using CMake macros instead 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 + all functions are documented inside: http://dev.openwengo.com/trac/openwengo/trac.cgi/browser/owbuild/trunk/owbuild/owbuild yes documentation is not enough for the moment I like to troll so let's troll well: 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) And to make it clear for everybody: why do I have to learn driving a car?? you are so stupid guys! this is too complicated, why don't you go by walk? 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. I take the bet no problem Like we say in french faut pas jeter le gamin avec l'eau du bain don't throw away the kid with the water from his bath (1) and then you end up with something like GTK+ where they just re-invented a square wheel by implementing inheritance in C rather than to use a tool specially designed and studied to solve this particular problem please feed me!!! :D -- Tanguy Krotoff [EMAIL PROTECTED] http://openwengo.org ___ Wengophone-devel mailing list Wengophone-devel@lists.openwengo.com http://dev.openwengo.com/mailman/listinfo/wengophone-devel
[Wengophone-devel] Still a compilation problem...
Hi,
I am still having an issue compiling the 2.1 branch from svn - the
configure step for portaudio fails with the following error:
[EMAIL PROTECTED]:~/src/wengophone-2.1/build$ ./build_make.sh debug
-- OS: Linux-2.6.15-27-386
-- Processor: unknown
-- Compiler: /usr/bin/gcc
-- Build type: Debug
-- Build tool: /usr/bin/make
-- Build directory: /home/dneary/src/wengophone-2.1/build/debug
-- svn revision: 9073
CMake Error: portaudio: alsa_INCLUDE_DIRS and alsa_INCLUDE_DIR empty
-- Configuring done
Generate graphviz: /home/dneary/src/wengophone-2.1/build/wengophone.dot
I activated the compilation of Portaudio with ALSA support in
DefineWengoOptions.cmake at the svn root
by setting PORTAUDIO_ALSA_SUPPORT to ON by default.
The problem is this bit of OWBuild, in
owbuild/owbuild/OWUsePublicLibraries.cmake:
foreach (loop ${ARGN})
if (NOT ${loop}_INCLUDE_DIRS)
if (NOT ${loop}_INCLUDE_DIR)
message(FATAL_ERROR ${PROJECT_NAME}:
${loop}_INCLUDE_DIRS and ${loop}_INCLUDE_DIR empty)
endif (NOT ${loop}_INCLUDE_DIR)
endif (NOT ${loop}_INCLUDE_DIRS)
ow_add_public_include_dirs(
${${loop}_INCLUDE_DIRS}
${${loop}_INCLUDE_DIR}
)
That gets called with alsa as an argument, but we never test
beforehand for ALSA, and even if we did, the ALSA CMake script doesn't
set either alsa_INCLUDE_DIRS or alsa_INCLUDE_DIR.
I'm still feeling my way around CMake - anyone able to point out the fix
for this issue in OWBuild?
I can attach DefineWengoOptions if you can't reproduce, just let me know.
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
