From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: Re: [PATCH] build: pull: Compile .scm files in one process. Date: Fri, 04 Dec 2015 15:11:32 +0100 Message-ID: <87d1uml2wb.fsf@gnu.org> References: <87si4kxtge.fsf@T420.taylan> <87611gdul8.fsf@gnu.org> <87h9kzy09b.fsf@T420.taylan> <87bnb6c0nh.fsf@gnu.org> <874mgyxhgy.fsf@T420.taylan> <877flpohu6.fsf@gnu.org> <87mvuku444.fsf@T420.taylan> <87pozgfyzt.fsf@gnu.org> <87io57tt2s.fsf@T420.taylan> <876117mnef.fsf@igalia.com> <87egfvtnbw.fsf@T420.taylan> <87y4e3l7hm.fsf@igalia.com> <87a8qjtje8.fsf@T420.taylan> <876117t0ax.fsf@gnu.org> <877flmrn2m.fsf@T420.taylan> <87a8q0ies5.fsf@gnu.org> <87fuzrlt6f.fsf@T420.taylan> <87bnafbvrs.fsf@gnu.org> <87bnaflbg2.fsf@T420.taylan> <87k2ovd02r.fsf@netris.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:57957) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a4yVu-0001HM-17 for guix-devel@gnu.org; Fri, 04 Dec 2015 17:07:39 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a4yVs-00058G-Ui for guix-devel@gnu.org; Fri, 04 Dec 2015 17:07:37 -0500 In-Reply-To: <87k2ovd02r.fsf@netris.org> (Mark H. Weaver's message of "Thu, 03 Dec 2015 10:27:24 -0500") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org To: Mark H Weaver Cc: guix-devel@gnu.org Mark H Weaver skribis: > taylanbayirli@gmail.com (Taylan Ulrich "Bay=C4=B1rl=C4=B1/Kammer") writes: > >> It would be great if the whole circular import problem could somehow be >> solved by Guile (no idea how feasible it is). > > I think we should eliminate circular module dependencies. They cause > nasty problems, and there's no compelling reason that we need them, > since our package dependency graph is necessarily a DAG. I think that this would mean having essentially one file per package, which in turns would add a lot of I/O overhead. More importantly, the problems we are facing here have nothing to do with circular dependencies. The main issue remains . The next issue would be multi-threaded compilation, which I think may be fragile due to unsynchronized accesses to module objects and obarrays, as discussed in this thread. WDYT? I would be happy to see more eyeballs looking into it! :-) Ludo=E2=80=99.