Hi,<br><br>Thank you for anwsering so fast. <br><br>&gt;&gt; 1. What solution do you think is the best: &quot;A main master script&quot; that<br>
&gt;&gt; knows every dependencies of every projects VS &quot;Completly indenpendant build<br>
&gt;&gt; script&quot; that we could simply include if we need them and their dependencies<br>
&gt;&gt; ? Please justify.<br>
<br>
&gt; If these are independent solutions, then there is no real choice. If there is<br>
&gt; such one, then they are not really independent and you could use the simplest<br>
&gt; approach of a master script.<br><br>Actually, I would like to be able to build &quot;A&quot; and &quot;B&quot; independantly. If I decide to build &quot;B&quot;, then &quot;B&quot; and only &quot;B&quot; is built. If I decide to build &quot;A&quot;, then &quot;B&quot; and &quot;A&quot; are built. This is the actual definition of &quot;independance&quot;.
<br><br>&gt;&gt; 2. How can I achieve the first solution with CMake ? (Is it possible ?)<br>
<br>
&gt; You can let cmake write another cmake script with SET statements that you<br>
&gt; include in yet another cmake script.<br><br>It sounds like a big &quot;configuration&quot; file. But how could this solve the src/file1.cpp problem ? Do you have any little practical example ?<br><br>&gt;&gt; 3: Is there any better solution that I don&#39;t see ?
<br>
<br>&gt; Yes.<br>
<br>&gt; Every solution comes down to a classic common thing: a development kit for C<br>
&gt; (used by B) and B (used by A).<br>&gt; An automatically written cmake script is one solution (somewhat limiting the<br>
&gt; dependent build environments to cmake) or something else like pkgconfig, or<br>
&gt; shell scripts that set environment variables, or whatever. Very much depends<br>
&gt; on the target audience and personal preferences.<br><br>Could you please elaborate on &quot;an automatically written cmake script&quot;. I would like to know more about it and how it can be acheived. The use of pkgconfig is prohibited, just like shell scripts and env. variables. The solution has to be as portable as it can be (win32, linux, macosx, etc.)
<br><br>Thank you again,<br>Félix C. Morency<br><br>------------------------------<br><br>Message: 3<br>Date: Thu, 27 Sep 2007 04:26:32 +0200<br>From: Hendrik Sattler &lt;<a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:post@hendrik-sattler.de">
post@hendrik-sattler.de</a>&gt;<br>Subject: Re: [CMake] Interresting dependency problem<br>To: <a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:cmake@cmake.org">cmake@cmake.org</a><br>Message-ID: &lt;
<a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:200709270426.32513.post@hendrik-sattler.de">200709270426.32513.post@hendrik-sattler.de</a>&gt;<br>Content-Type: text/plain; &nbsp;charset=&quot;utf-8&quot;
<br><br>Am Donnerstag 27 September 2007 schrieb Félix C. Morency:<br>&gt; 1. What solution do you think is the best: &quot;A main master script&quot; that<br>&gt; knows every dependencies of every projects VS &quot;Completly indenpendant build
<br>&gt; script&quot; that we could simply include if we need them and their dependencies<br>&gt; ? Please justify.<br><br>If these are independent solutions, then there is no real choice. If there is<br>such one, then they are not really independent and you could use the simplest
<br>approach of a master script.<br><br>&gt; 2. How can I achieve the first solution with CMake ? (Is it possible ?)<br><br>You can let cmake write another cmake script with SET statements that you<br>include in yet another cmake script.
<br><br>&gt; 3: Is there any better solution that I don&#39;t see ?<br><br>Yes.<br><br>Every solution comes down to a classic common thing: a development kit for C<br>(used by B) and B (used by A).<br>An automatically written cmake script is one solution (somewhat limiting the
<br>dependent build environments to cmake) or something else like pkgconfig, or<br>shell scripts that set environment variables, or whatever. Very much depends<br>on the target audience and personal preferences.<br><br>HS
<br><br><br>------------------------------