From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1NJla0-00038G-5S
	for qemu-devel@nongnu.org; Sun, 13 Dec 2009 05:21:32 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1NJlZv-000360-Bq
	for qemu-devel@nongnu.org; Sun, 13 Dec 2009 05:21:31 -0500
Received: from [199.232.76.173] (port=42690 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1NJlZu-00035i-9N
	for qemu-devel@nongnu.org; Sun, 13 Dec 2009 05:21:26 -0500
Received: from mx1.redhat.com ([209.132.183.28]:25413)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <avi@redhat.com>) id 1NJlZt-0005YX-QP
	for qemu-devel@nongnu.org; Sun, 13 Dec 2009 05:21:26 -0500
Message-ID: <4B24C01C.7050607@redhat.com>
Date: Sun, 13 Dec 2009 12:21:16 +0200
From: Avi Kivity <avi@redhat.com>
MIME-Version: 1.0
References: <1260645057-19819-1-git-send-email-andreas.faerber@web.de>
	<1260645057-19819-2-git-send-email-andreas.faerber@web.de>
	<1260645057-19819-3-git-send-email-andreas.faerber@web.de>
	<1260645057-19819-4-git-send-email-andreas.faerber@web.de>
	<m3fx7fzz8v.fsf@neno.neno>
	<62024FDC-0214-49BF-BC69-14167AC4C034@web.de>
In-Reply-To: <62024FDC-0214-49BF-BC69-14167AC4C034@web.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Subject: [Qemu-devel] Re: [PATCH 3/3] Workaround --whole-archive on Solaris
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: =?ISO-8859-1?Q?Andreas_F=E4rber?= <andreas.faerber@web.de>
Cc: Palle Lyckegaard <palle@lyckegaard.dk>, Juan Quintela <quintela@trasno.org>, QEMU Developers <qemu-devel@nongnu.org>

On 12/13/2009 01:07 AM, Andreas F=E4rber wrote:
>
> Certainly I would prefer having one shared linking mechanism.
>
> The three separate Makefiles (Makefile, Makefile.hw, Makefile.target)=20
> that govern which objects are to be compiled pose the problem.
> In the end, we need some mechanism to get the right set of objects=20
> into Makefile.target. Previous attempts were
> (i) writing object file paths to a file (me not satisfied), or
> (ii) printing them from within make (Avi objected), and now
> (iii) extracting them from archives (Juan objected for Linux).

Out of the three above, I prefer (ii) despite my objection.

>
> Juan, being our Makefile inventor, what about
> (iv) moving the assembling of some of the obj-y variables to a shared=20
> file included by all three Makefiles?
> Would that work? If we had, e.g., common-obj-y and libhw{32,64}-obj-y=20
> accessible in Makefile.target, we could use them for both dependency=20
> modelling and linking.

But out of the four, I prefer this.

In fact, why not have one large makefile, with different targets called=20
for different subdirectories?

--=20
error compiling committee.c: too many arguments to function