Dave Neary wrote:
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?
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!
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
Future will tell us...
Of course, if you're only writing software for your own use and
enjoyment, you can use any language you want.
Creating a build system is sooo fun
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" :)
I 100% agree with all this, it is simply common sense. But just let me
the time to write the documentation and improve OWBuild! The
documentation is too short for the moment and of course I know it
and telling me "I'm not sure OWBuild is better than CMake blahblah"
doesn't help me on that
--
Tanguy Krotoff <[EMAIL PROTECTED]>
http://openwengo.org
_______________________________________________
Wengophone-devel mailing list
Wengophone-devel@lists.openwengo.com
http://dev.openwengo.com/mailman/listinfo/wengophone-devel
