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.
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

Reply via email to