From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) by sourceware.org (Postfix) with ESMTPS id D08343858C2B for ; Sun, 22 Nov 2020 23:22:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org D08343858C2B Received: by mail-lj1-x231.google.com with SMTP id y10so592584ljc.7 for ; Sun, 22 Nov 2020 15:22:28 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7HKk6Fro4xRqNvExexmpQRn9k9Dro+QO9ypd69CSOCM=; b=r/EI1zieMH1UXSA4sz8q9epG5DDKJv7Ro7t7CqtNvcPJKuxYdS3fhQCtrL3BY2zWpf ZdeRGs9tN3ih2GcWBuPWdUEfTgoatbgh4eW/Eojw88bkNM/IDD+FCjH24opjEfIHMwrd 7u4tlp8vVQQBUKWXM2vrqqG774iRkjKQidrh+uNNMbJ2GEHjlGzGAIIZht/kCFkI0zid fB9trBTE5om8oDCgiufv5faQpTt6U1m5FtpcMRgcBylU3jOF10INkYqwgSCWodYSfez9 0zh/bM4Shok/Ph5qHAR6rikS2EL4B+s3a7cCstgWi4UzoVW5G/6FcC7JuIsFpI6MilSF 1QUQ== X-Gm-Message-State: AOAM533g9hJUeUM05OTprpOBbPejXdC55K3OaipSJLhe+7tpWyiws+Jg JpMgnTl3XB/7fvhOvANZSC+iXSX4nq3ECeNQJEuylmGvugI= X-Google-Smtp-Source: ABdhPJwomsJJnE1nXFLHLljGopmIx/Gzu3YZJ819tNsNSpBDjSamZv9reoG/RB6XkO31n68Ytvv8BzFh336thmkHzwM= X-Received: by 2002:a2e:a0ca:: with SMTP id f10mr11577430ljm.204.1606087347531; Sun, 22 Nov 2020 15:22:27 -0800 (PST) MIME-Version: 1.0 References: <639409ed-2b09-6d8c-3444-081fe7c9eb58@bothner.com> In-Reply-To: <639409ed-2b09-6d8c-3444-081fe7c9eb58@bothner.com> From: Arvydas Silanskas Date: Mon, 23 Nov 2020 01:22:17 +0200 Message-ID: Subject: Re: Kawa source tree organization To: Per Bothner Cc: kawa mailing list X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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 23:22:31 -0000 Hmm I agree the toolchain and grouping are orthogonal changes, and I won't do changes to the former now. Regarding make/autotools alternatives, specifically maven and gradle, I think they're great if for nothing else then at least for the consequences of their mainstream use and popularity -- great IDE support and familiarity for java programmers (which consequently mean preexisting understanding of structure and where to look for things if project has idiomatic layout, as well as having necessary things already installed). Aside that, their merits are mostly dependency installment & management (for 3rd party like jline, but also for internal use, say like kawa-compiler would have dependency on core-utils) and taking care of invoking javac with right classpaths. I'm also fairly sure those tools are more friendly for developers using windows. That said, I'm somewhat fine with the "don't fix if it's not broke" reasoning, because I'm not entirely sure how maven or gradle would play out with preprocessing that's being done in kawa. While fully new source file generation (eg vector primitives like FVector) seems solvable with annotation processor code generation, the inline preprocessing looks trickier. Arvydas 2020-11-22, sk, 03:30 Per Bothner ra=C5=A1=C4=97: > 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-compile= r, > > 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 on= e > 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 stil= l > 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-librar= y) > 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 coul= d > be talked into it if that is the consensus and someone else does the heav= y > 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/ >