From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?utf-8?Q?Bj=C3=B6rn?= Bidar Newsgroups: gmane.emacs.help Subject: Re: Retrieving the "include" directory for Emacs Modules Date: Fri, 03 Jan 2025 23:06:54 +0200 Message-ID: <32381.3624026783$1735938469@news.gmane.org> References: <67771d72.170a0220.681ba.7fadSMTPIN_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="22485"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: help-gnu-emacs@gnu.org To: Marco Antoniotti Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Fri Jan 03 22:07:41 2025 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 1tTotR-0005hI-4R for geh-help-gnu-emacs@m.gmane-mx.org; Fri, 03 Jan 2025 22:07:41 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tTot0-000860-Tk; Fri, 03 Jan 2025 16:07:16 -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 1tTosr-00085Z-6R for help-gnu-emacs@gnu.org; Fri, 03 Jan 2025 16:07:06 -0500 Original-Received: from thaodan.de ([2a03:4000:4f:f15::1]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tTosn-00007O-A7 for help-gnu-emacs@gnu.org; Fri, 03 Jan 2025 16:07:04 -0500 Original-Received: from odin (dsl-trebng12-50dc7b-49.dhcp.inet.fi [80.220.123.49]) by thaodan.de (Postfix) with ESMTPSA id 89BAAD00049; Fri, 3 Jan 2025 23:06:55 +0200 (EET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=thaodan.de; s=mail; t=1735938415; bh=yU7D4EEwSwxYy5jYnNREa8reNrMKjl2ZXFDfYNUmfaM=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=p1WFqMTrUqAbvUsUFmOYBDzUAf91lCJCc34oGJrIjJrXjblBI7YYae5BtvLxQesew D5j7v0womaG3TPhZgiqW4Y9Spl34H4q0OEVXB1jEdHJ2yuR7DlWuE/C17lZoCekjDI mEzMIGFQLK1xLekiqTvyAIQWp64hmVUI4gy3D6fKGW/u+r30W06KhIuMyJu4NIFWcf ChAcYoPf4vhUvcWrzjmb15emfczLNJziOJZZM6RjFY1PdwhXKXPmagfXSs6s2msH7e mo3BZZUf67w/bvgl3XvQch1WHEkgyds/mLilRbua71eB2dLooTn8WdqpToNFEqJ+0Q YdbJobSHafxeL9NPKXFDYM/Dn9ITveka1BP724UylY0SuWZzCkC+xDd8hgYima8gtZ 8n17lGvJTOsnr3Nt6L2ZsFb/cmcX1hMmMzqioSjGa8sHnKbAVNtADYINpSf7NPkR2t DZ7/ROp5ikpVY1shJ1Fy/NEc1CSX0iAgOMcZ7Ob1MwBLnhnEXPc9zeWq96UAXYOpGe MtyhiOPPo9wrskIEEGN8GT52vWKFoEsv6CINbNuKwq3Jamjxe9HCDEopFnhmEtYBtb /Vuj8KLl2n1jQBuGtKOOiKk2BCSc4Zi2wtJ3Sxqt4mEz4ZcTFAFBTDAj6sI2FKdjrs Ajk0r5p7e+JnOI1sKt3VUTcU= In-Reply-To: (Marco Antoniotti's message of "Fri, 3 Jan 2025 11:52:56 +0200") Autocrypt: addr=bjorn.bidar@thaodan.de; prefer-encrypt=nopreference; keydata= mDMEZNfpPhYJKwYBBAHaRw8BAQdACBEmr+0xwIIHZfIDlZmm7sa+lHHSb0g9FZrN6qE6ru60JUJq w7ZybiBCaWRhciA8Ympvcm4uYmlkYXJAdGhhb2Rhbi5kZT6IlgQTFgoAPgIbAwULCQgHAgIiAgYV CgkICwIEFgIDAQIeBwIXgBYhBFHxdut1RzAepymoq1wbdKFlHF9oBQJk1/YmAhkBAAoJEFwbdKFl HF9oB9cBAJoIIGQKXm4cpap+Flxc/EGnYl0123lcEyzuduqvlDT0AQC3OlFKm/OiqJ8IMTrzJRZ8 phFssTkSrrFXnM2jm5PYDoiTBBMWCgA7FiEEUfF263VHMB6nKairXBt0oWUcX2gFAmTX6T4CGwMF CwkIBwICIgIGFQoJCAsCBBYCAwECHgcCF4AACgkQXBt0oWUcX2hbCQEAtru7kvM8hi8zo6z9ux2h K+B5xViKuo7Z8K3IXuK5ugwA+wUfKzomzdBPhfxDsqLcEziGRxoyx0Q3ld9aermBUccHtBxCasO2 cm4gQmlkYXIgPG1lQHRoYW9kYW4uZGU+iJMEExYKADsCGwMFCwkIBwICIgIGFQoJCAsCBBYCAwEC HgcCF4AWIQRR8XbrdUcwHqcpqKtcG3ShZRxfaAUCZNf2FQAKCRBcG3ShZRxfaCzSAP4hZ7cSp0YN XYpcjHdsySh2MuBhhoPeLGXs+2kSiqBiOwD/TP8AgPEg/R+SI9GI9on7fBJJ0mp2IT8kZ2rhDOjg gA6IkwQTFgoAOxYhBFHxdut1RzAepymoq1wbdKFlH Received-SPF: pass client-ip=2a03:4000:4f:f15::1; envelope-from=bjorn.bidar@thaodan.de; helo=thaodan.de X-Spam_score_int: -14 X-Spam_score: -1.5 X-Spam_bar: - X-Spam_report: (-1.5 / 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, INVALID_MSGID=0.568, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action 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:149132 Archived-At: Marco Antoniotti writes: > On Fri, Jan 3, 2025 at 1:12=E2=80=AFAM Bj=C3=B6rn Bidar wrote: > >> Marco Antoniotti writes: >> >> > Hello and Happy New (Hacking) Year. >> > >> > apologies if I insist on this issue. >> > >> > On Sun, Dec 29, 2024 at 6:53=E2=80=AFPM wrote: >> > >> >> Message: 5 >> >> Date: Sun, 29 Dec 2024 03:03:53 +0200 >> >> From: Bj=C3=B6rn Bidar >> >> To: Stefan Monnier via Users list for the GNU Emacs text editor >> >> >> >> Cc: Stefan Monnier >> >> Subject: Re: Retrieving the "include" directory for Emacs Modules >> >> Message-ID: <8734i7i9l2.fsf@> >> >> Content-Type: text/plain >> >> >> >> Stefan Monnier via Users list for the GNU Emacs text editor >> >> writes: >> >> >> >> >> Those under /usr/lib are looked in by the relevant compilers (they >> are >> >> >> include directories private to those compilers, hard-coded into th= em >> >> >> when they are built). Those under /usr/share are private to the >> >> >> relevant packages, and are either examples or test suites (thus AF= AIU >> >> >> unrelated to the issue at hand here). Those under /usr/src are wh= at >> I >> >> >> mentioned: private headers needed to build a package. >> >> > >> >> > Indeed, they each have their own reason to exist. And this is in >> Debian, >> >> > i.e. a distribution which is very careful to install things in the = one >> >> > central place where they belong. >> >> >> >> I'm on openSUSE which is entirely unrelated same policy. In fact all >> >> Unixes have such a policy (macOS doesn't count in this context). >> >> >> > >> > ... and why exactly MacOSX (and Windows) "don't count in this context"? >> > And what is the "context"? >> >> I wrote macOS (the is no longer in the name) does not count in the >> sentence as Unix as the NextStep/GNUStep build of Emacs uses an app >> bundle which does not install into a prefix directory normally. >> >> > It installs "normally" as far as Mac OS (X or not) is concerned. Do you have Emacs.app or not? The normal way does not use Emacs.app. >> >> >> >> > Other relevant cases will look very different: >> >> > Emacs.app, AppImages, Snap packages, etc... >> >> >> >> Who are proprietary platforms such as Snap relevant to Emacs? For the= se >> >> where a sandbox is involved such as Snap or Flatpak it is not possible >> >> to interact with external resources without breaking the security of = the >> >> sandbox. >> >> >> > >> >> But anyway this is going off-topic. >> >> >> >> >> > How exaclty does having >> > >> > include-directory >> > >> > (and the other variables) available, break the sandbox? Or anything >> else? >> >> If Emacs is installed from Flatpak loading libraries outside of that >> sandbox break the security of it. Building modules inherently requires >> to call external binaries to link against external dependencies. >> > > Oh come on! Emacs is not exactly the "safest" of environments. Your > argument here boils down to "do not build Emacs Modules". My point is if you use flatpak you should pull your dependencies from Flatpak or you break the main purpose for using the Flatpak sandbox completely, at that point you can also install Emacs without Flatpak and have the same results with less issues. >> The issue here is accommodating the wider world. >> >> It is but accommodating the wider world ultimately only mattered for >> free open source platforms not on the non-free platforms supported by >> Emacs. >> I don't say that is what should happen here but the workarounds required >> for some platforms should not affect others. >> > > And how exposing 'include-directory' would affect you? Or VS Code (which, > I remind you, is what the vast majority of incoming students uses)? Or > FOSS platforms? > What does this have to do with VS Code? What is exposing Include-directory? If I understand correctly there should be include folder in the Windows build and inside Emacs.app folder. Adding the include directory relative to the prefix of the Emacs installation might be a ok workaround for these platforms. For the others where the compiler searches for the headers in the default path where it was installed by the package manager it would explicitly add the default include path to the list of folders to search which might not be the users intention, i.e. it could have side effects. I does not make sense to apply platform specific workarounds to all platfor= ms. >> > Personal historical note. I first used Emacs on a Zentih z8000. The >> first >> > GNU Emacs I used was on a Sun 3/60. I also used it on AIX and, if mem= ory >> > does not fail me, on a microVAX with VMS (this I may be wrong). >> > >> > These were (are) all proprietary platforms. "Unixy" but proprietary. = As >> > MacOSX. >> > >> > Do you want people to use Emacs? Let them have access to it without >> > imposing needless constraints. >> > >> >> The issue is something which was known before the module system was >> added to Emacs, that requiring to compile native code for interfacing >> with other libraries complicates things. Which is why XEmacs had helper >> programs or function to automate much of this process. >> >> Native modules have their place but it was criticized that comparing to >> native >> modules FFI would have been simpler as no native code would have had to >> be compiled just to interface with external libraries. >> > > ... great. Now, let me ask you: why are we inflicted (I feel > "inflicted" =F0=9F=98=91 ) Python (a FOSS language) instead of writing lo= vely > parentheses? Python? Context?