From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from aibo.runbox.com (aibo.runbox.com [91.220.196.211]) by sourceware.org (Postfix) with ESMTPS id 9788C386EC54 for ; Sun, 22 Nov 2020 01:29:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 9788C386EC54 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=bothner.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=per@bothner.com Received: from [10.9.9.73] (helo=submission02.runbox) by mailtransmit02.runbox with esmtp (Exim 4.86_2) (envelope-from ) id 1kgeCG-0007Qs-FQ for kawa@sourceware.org; Sun, 22 Nov 2020 02:29:44 +0100 Received: by submission02.runbox with esmtpsa [Authenticated alias (524175)] (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) id 1kgeC2-00044x-OJ for kawa@sourceware.org; Sun, 22 Nov 2020 02:29:31 +0100 Subject: Re: Kawa source tree organization To: kawa@sourceware.org References: From: Per Bothner Message-ID: <639409ed-2b09-6d8c-3444-081fe7c9eb58@bothner.com> Date: Sat, 21 Nov 2020 17:29:27 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: kawa@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Kawa mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2020 01:29:51 -0000 On 11/21/20 4:23 PM, Arvydas Silanskas via Kawa wrote: > Perhaps it could be worthwhile splitting things up? For example: > > * kawa-the-compiler base project, that'd consist basically of > language-agnostic compiler what now are gnu.bytecode, gnu.expr, etc. > Ideally one could just use it to create a jvm targeting language. > * kawa-the-scheme project, which would be what implements the minimal core > scheme, such as the native syntax forms seen in kawa.lang package. Depends > on kawa-the-compiler project. Ideally one could just use it as a > self-sufficient minimal scheme library. > * various feature-projects, that depend on either just kawa-the-compiler, > or kawa-the-scheme, but not on other feature-projects. > * the main kawa project, which includes everything listed above, implements > the public static main, and handles command line arguments. Basically, the > module that compiles to what now is kawa.jar. I think that would be good, but it may be a lot of work (and hard thought) to split things up. There are lots of cross-dependencies. We do have one advantage, in that Kawa has always been able to bootstrap from just Java, without requiring an earlier version of itself (or some other version of Scheme). This has forced some separation. I have also tried to separate out compile-time-only clases, but that still needs a lot of work. I have generally preferred relatively shallow directory trees, with the source for class X.Y as file X/Y.java with no extra nesting. It is probably reasonable to change that, though I don't think going as far as Maven's src/main/java/X/Y.java would be desirable. A first draft: core-utils (packages such as gnu.lists gnu.math gnu.kawa.io gnu.text. These are used by both compiler and the runtime.) kawa-compiler (gnu.bytecode gnu.expr) scheme-language (maybe split into parts such as separate scheme-library) extras (probably split this up) commonlisp-language xquery-language jemacs-language and brl-language are probably not used by anyone (gnu.ecmascript can probably be removed) A lot of gnu/kawa/functions and gnu/kawa/lis Perhaps the first step would be to create a core-utils sub-directory with classes that does not depend on any classes outside of it. That may require some re-factoring and moving classes around. Or start from the other end: classes that are definitely *not* needed to build or run a functional Scheme. I am not convinced that replacing make+autotools would be worthwhile. They're clunky, but they work without installing some other major subsystem, and it is not clear to me that any alternative is sufficiently clearly better. Specifically, I don't see writing build/configuration files using XML syntax (as needed for Ant or Maven) is an improvement. And I'm not quite ready to embrace Gradle (or the Groovy language), though I could be talked into it if that is the consensus and someone else does the heavy lifting. Regardless, I suggest changing build tools is a separate and orthogonal task: switching both directory layout and build tools at the same time is probably too much. -- --Per Bothner per@bothner.com http://per.bothner.com/