From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Marco Antoniotti Newsgroups: gmane.emacs.help Subject: Re: Retrieving the "include" directory for Emacs Modules Date: Mon, 23 Dec 2024 21:56:49 +0100 Message-ID: References: <6769c4ea.170a0220.d60c5.1423SMTPIN_ADDED_BROKEN@mx.google.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="34441"; mail-complaints-to="usenet@ciao.gmane.io" Cc: help-gnu-emacs@gnu.org To: =?UTF-8?B?QmrDtnJuIEJpZGFy?= Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Mon Dec 23 21:57:41 2024 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1tPpUj-0008ny-Dp for geh-help-gnu-emacs@m.gmane-mx.org; Mon, 23 Dec 2024 21:57:41 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tPpUD-0006KR-3X; Mon, 23 Dec 2024 15:57:09 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tPpUA-0006KJ-Tg for help-gnu-emacs@gnu.org; Mon, 23 Dec 2024 15:57:07 -0500 Original-Received: from mail-yb1-xb29.google.com ([2607:f8b0:4864:20::b29]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tPpU7-0005Ub-Vb for help-gnu-emacs@gnu.org; Mon, 23 Dec 2024 15:57:06 -0500 Original-Received: by mail-yb1-xb29.google.com with SMTP id 3f1490d57ef6-e4963c2de19so318127276.0 for ; Mon, 23 Dec 2024 12:57:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1734987421; x=1735592221; darn=gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=7A5CSEuKCOIf1iRg2RjhxPJTn8epVOvxdYk76rpgnIk=; b=SZT2Ql8uefeIqlyFkxSLea9vGuQUE6zlQ1tc59hBTsjlB4vrVYq/zy4vUkySolE++q iRXoE/O4WMQ8LUpTbQ/i+sTdQ1iH6Ghy2oLRXa64cI7Av9AYgQWUWj097Ii5I8wcTQNG PELM7UrGTYJqSCJtUozqldk3DkdfSx5Ns8GBIGXHto9d0K6Z2sYynC4x5qA/jIY535it AJZI1VKFyT3wB4+5LwsFD9BTPe963wlP4GCBJ6A89n4Ej3waHpfs2kUnjUa98GeA4fDy C2iT2kMpx6t9PkjTg1YYixxT/gaUHWLE9p+KwJnljUfZbMCUfg7mGMqps9U4mG+SiJFi gphg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1734987421; x=1735592221; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=7A5CSEuKCOIf1iRg2RjhxPJTn8epVOvxdYk76rpgnIk=; b=l/11gUHbTcmo/P9v3Z/fPxU1Ob2DIFCIXDusiI+o2p/z/4pvF6ibKP7q88J3frK6gp 8SmsIr3Z9GFY71TB5zqqKSh9JvD1ZNKjNnY8IW40rjQ0SU5yuDA3I0af8otDlSP1tOID 6xa1oMtPTXtr8rNWgty3IE3/XapNDY3On+Vfw9Up9wNpTkhdP4P0bcBHomCRG+0TKPLG wuqO5CswQ782TDciK/L3+xXK80lMk4UrO1GtPCSUqIe6g0gprmhGv3zKPsS5e7Iwzh5N hln7UvIofbdMS+teyUXjn+zxpwptn1787rym5VRfqinsA0yNMvsrKt2ofcHKsw1Ihkde NDRg== X-Gm-Message-State: AOJu0Yzc1ntYEv9cn2OsORVuHHhkLZRMaXuag1pG0SSO57JfHcenYBkm FE5kuahVrYHDVi4jXdgc1ndQXyHuVKljzINU0khlio+wGMGBoF1OOHRtKUThJO33L71km5yQLqq c72CHZelT1QSY8TQiEX7KM8A0sZMoJIg0 X-Gm-Gg: ASbGnctmxCWBvqlfkjQkIASIAmOqLawbIzsHV8Qms4/QNv45J55zu24ABxj9pP/i+c8 4Ko34bFjFmqqy6+OqCQ3D97NB/+ivsNvMKrWN5A== X-Google-Smtp-Source: AGHT+IHQPFpkqAMzZwKGwqgyYVQnAGCH/Drm+8aLm+RKkUjgFUjTJVEyJZtGh3NI8uCQNREEvl6Gg7zzjMJLiA8J5EU= X-Received: by 2002:a05:6902:2290:b0:e38:b5bb:d0fb with SMTP id 3f1490d57ef6-e538c005ddbmr4829555276.0.1734987421416; Mon, 23 Dec 2024 12:57:01 -0800 (PST) In-Reply-To: <6769c4ea.170a0220.d60c5.1423SMTPIN_ADDED_BROKEN@mx.google.com> Received-SPF: pass client-ip=2607:f8b0:4864:20::b29; envelope-from=marcoxa@gmail.com; helo=mail-yb1-xb29.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.help:148935 Archived-At: Hi, after having looked into XEmacs elcc, i'd say that it may work. Alas, that would mean to distribute and maintain a different tool. On Mon, Dec 23, 2024 at 9:15=E2=80=AFPM Bj=C3=B6rn Bidar wrote: Marco Antoniotti writes: > > > On Fri, Dec 20, 2024 at 6:02=E2=80=AFPM wrote: > > > >> > >> Message: 2 > >> Date: Fri, 20 Dec 2024 10:41:08 -0500 > >> From: Stefan Monnier > >> To: Bj=C3=B6rn Bidar > >> Cc: Stefan Monnier via Users list for the GNU Emacs text editor > >> > >> Subject: Re: Retrieving the "include" directory for Emacs Modules > >> Message-ID: > >> Content-Type: text/plain > >> > >> >> That's OK: the sole purpose of the change is to let ELPA packages > call > >> >> `gcc` with such a `-I`! > >> > Which is wrong for Unix-like systems except on macOS. > >> > >> In which sense would it be wrong? > >> I can see an argument that such a `-I` would tend to be redundant on > >> systems where Emacs was "installed properly", but even on those system= s > >> I fail to see what would be "wrong" about it. > >> > > > > I obviously agree. I would also contend that "Emacs installed properly= " > > should mean "installed according to the standards of the platform". > > > The proposal was add the module header to datadir not "installed > according to the standards of the platform". > Nope. The proposal is to expose the Emacs installation 'include' directory in such a way that it is possible to ask a batch emacs where it is so that you can then use these values in your favorite build system. > > > Now, on Windows this means (usually) "C:/Program > Files/Emacs/emacs-MM.mm/", > > with subdirs bin, include, lib. libexec and share. > > This is not so far-off UN*X; it is "standard" (as per Microsoft) and ye= t > it > > is not what UN*X people, and, it appears, some Emacs people, would > consider > > "proper". > > That's off-topic. > It surely does not seem so, given the previous discussion. > > > On Mac OS, https://emacsformacosx.com/ does a very good job of providin= g > > batteries-included Emacs. Its installation is, per Apple's ukazes, in > > /Applicatiions/Emacs.app/Contents/Resources. Note that this is a > > "simplified" Apple installation, but surely it is "proper" under Mac OS= . > > > > Let me weigh in on another topic. I teach and I have students come in > > (second year CS) with all sorts of editors installed, Sublime, VSCode, > Vim, > > Eclipse, Notepad, whatever; no one uses Emacs. > > > > First thing I do is to tell them to "install Emacs". > > > > Do you (Bj=C3=B6rn) think that, apart from the very hard core > > > "I-already-know-Rust-and-C-sucks-because-I-recompiled-the-Linux-kernel-wh= en-I-was-9-yo-on-my-Rasperry-pi" > > three or four guys (they are obviously male) the majority is going to > > "compile and install Emacs"? They go to https://emacsformacosx.com/ > and to > > the https://www.gnu.org/software/emacs/download.html sites and download > the > > installers. Or they use homebrew, snap or apt. > > > Such language is out of place here or anywhere else.. Especially > language which assumes gender stereotypes. > Sorry. I tend to observe and use humor. If you have other data points with proper statistics (number of women who think that C sucks because they like Rust), I will update the jokes. > > Bottom line, if you want our beloved editor to be used, lighten up. > (Yes, > > I am patronizing; sorry; I am a boomer: TOWANDA :) ). > > > >> It's debatable if packages should compile their native modules > >> > themselves > >> > >> IME it's what most users expect when they install (via `package.el`) > >> packages that come with a module, and it's also what most of the > >> developers of those packages want to offer to their users. > >> I have no intention to impose such an approach as the only supported w= ay > >> to install a module, but I don't see what's debatable about providing > >> good support for packages to be able to compile their own modules. > >> > > > > Exactly. Two thumbs up! TRT is to make the system as "open" as possibl= e, > > by playing ball with the platforms out there (at least Windows and Mac > > OS). People will find all sorts of ways to use the C compiler that the= y > > have at hand; and no, these days the C compiler is not necessarily gcc, > and > > you should not assume it is. > > Where GCC assumed somewhere besides writing GCC when CC was meant? > These days it has shifted from assuming CC is GCC that CC is Clang in > those projects that do mainly use Clang such as Chromium. > Emacs requires libgccjit for native compilation in this context is could > be very much assumed that CC is GCC. > I just tested my emacs module compiling with the MSVS toolchain. Works like a charm, just like the clang setup on Mac OS; but I must hard code the Emacs 'include' directory, which I just happen to know where it is. > > > That is why you need to expose the "Emacs configuration"; which means, > at a > > minimum, the 'include' directory for the header file(s) to build dynami= c > > Emacs modules. Having a bunch of 'emacs-*' elisp variables/constants > that > > can be queried would be very helpful (hint: data-directory could be > aliased > > to emacs-data-directory). I know this should move to the development > list. > > At least for the compiler configuration should not be needed as CC is > used on Unixi systems, on Windows that's an entirely different thing. > There's no need to define a variable for the include directory if the > include folder the header is in is installed into to the prefix directory > of the Emacs > installation i.e. /usr on most Unixes, in the NextStep build Emacs.app > and on Windows > That's exactly why we need to expose the location of the 'include', plus I believe the maintainer of https://emacsformacos.com/ has a different opinion. The whole point is that Emacs must be usable everywhere and that its use must be made as easy as possible, for the case at hand, module writers. Your argument is just "we must stick to unixi setups"; the counterargument is that exposing constants that tell a user how Emacs is installed on a given platform is not that big of a deal and gives leverage and freedom to emacs module writers, and probably to package writers as well. > > In any case issues like could be resolved with something similar to > XEmacs's elcc. > Maybe. Maybe not. Happy Holidays --=20 Marco Antoniotti Somewhere over the Rainbow