Sylvain Benner wrote:
So can you explain what do you mean by "inheritance system" please ?
Some explanations here:
http://dev.openwengo.org/trac/openwengo/trac.cgi/wiki/OWBuild
you create a library A that depends on cURL and Boost
A uses privately cURL and uses Boost publicly, example:
file A.h:
#include <boost.h>
int toto();
file A.cpp:
#include <curl.h>
int toto() {...}
This means that B uses A but B really don't care A uses curl internaly
on the other hand B cares that A is using boost since #include <boost.h>
is inside A.h
so in A' compilation script you will write:
ow_create_library(A)
ow_use_public_libraries(boost)
ow_use_private_libraries(curl)
in B's script:
ow_create_executable(B)
ow_use_private_libraries(A)
B will inherit the public interface from A: boost include path,
definitions, flags, link libraries... but won't inherits all the curl stuff
See the schema attached
In OOP you write something like this:
class A {
public:
int boost();
private:
int curl();
}
class B : public class A {
public:
//int boost() inherited
}
What is nice with this approach is that you can represent your build
system as a UML diagram! See the UML diagram attached.
You can easily communicate with your team/dev community about the build
system because you use a standard representation that everybody understands.
This example does not seem straightforward but public/private notion
permits to optimize compilation and to separate things in a nice and
clean way. For example, on a huge project you want to shorten the
include path because the shorter it is the faster the compilation will be.
+ now you add the dll (=> so shared library under UNIX) problematic...
Imagine you want to choose with a simple variable if A is a dll or a
static lib. if A is a dll, B won't have to link with boost and curl. If
A is a static lib, B has to link with boost and curl.
With this kind of inheritance no problem, inside
ow_use_public_libraries() you check whether the child libs are static or
shared and propagate or not the link libraries.
Imagine that A depends on curl, ffmpeg, boost, tinyxml...
C depends on Qt, directx, ALSA....
and B the executable depends on A and C
starts to be complex and you really would like the compilation system
take care of it for yourself...
Here is a schema of such a program:
http://www.cynapses.org/tmp/wengophone/wengophone.png
I don't know if you understand my explanation. if you have already
encounter the problematic you will understand.
--
Tanguy Krotoff <[EMAIL PROTECTED]>
http://openwengo.org
_______________________________________________
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake