all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Stephen J. Turnbull" <stephen@xemacs.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: aurelien.aptel+emacs@gmail.com, dmantipov@yandex.ru,
	emacs-devel@gnu.org, sdl.web@gmail.com, monnier@iro.umontreal.ca
Subject: Re: Why not zlib-compress-region?
Date: Sun, 29 Jun 2014 01:30:51 +0900	[thread overview]
Message-ID: <87fvipvvwk.fsf@uwakimon.sk.tsukuba.ac.jp> (raw)
In-Reply-To: <83a98x6up5.fsf@gnu.org>

Eli Zaretskii writes:

 > I know about the package managers, I just wanted to make a point that
 > AFAIU end-user Posix systems might well lack a compiler.  AFAIR, on
 > non-free Posix systems, installing a compiler actually costs money.

Not on Mac OS X.  And how many important non-free POSIX systems aren't
supported by GCC (not to mention The-Compiler-Suite-That-Shall-Not-Be-
Mentioned-On-GNU-Channels)?

The real problem for those is more likely whether there is an
enterprise requirement for vetting all installed software.

 > So having an FFI implementation that requires a compiler might be a
 > disadvantage on Posix systems as well.

Anything's possible.  I don't think it's worth worrying about it.
XEmacs/SXEmacs have *never* received complaints about availability of
compilers for our version of "Stefan-style FFI".  It's always "ooh,
yuck, no GUI installer??!!  I can't do that!" or "why can't you
distribute binaries in the prebuilt packages?", not a "I have to
install a compiler" problem.

FFI implementations that *don't* require compilers have their
problems, too, since Lisp types sometimes map to different C types for
different libraries, which requires a lot of fiddly low-level
knowledge on the part of the Lisp programmers that (if they stick to
pure Lisp) they just don't need at all.  FFI == crashable Lisp.

 > > usually without going through DLL hell
 > 
 > (This is unrelated.)  I don't believe in package managers as a
 > means to avoid the "DLL hell".  Dependencies are written by people,
 > which are prone to errors, and having several libFOO.so versions on
 > the same system, even if their names don't conflict, is not fun.

I have a bunch of them (three versions of GTK, two of libpng for
example).  I don't notice it at all, the PMS installs the right
dependencies for everything.  (Not to mention simultaneous installs of
32- and 64-bit versions of many libraries.)  OTOH, I only have one
instance of each version level (modulo the 32-bit issue), because the
distros provide extremely good coverage and generally do a good job of
sorting incompatibilities (occasionally in the opposite way from my
preference, but them's the breaks).  So the real point is not the
PMS's dependency database, but rather than fact that each distro has a
(more or less) canonical compiler suite, and you just install that and
it pulls everything else in.

 > We are talking about the compiler and Binutils.  Building those,
 > especially the former, is not for the faint at heart, not even on a
 > Posix host.

Nonsense.  I do it about once a month, sometimes twice a week
(automatically via Gentoo's Portage PMS, which always builds from
source).  Unlike, say, Boost or KDE's nepomuk (which are always
holding up the upgrade), I can't remember well the last time a GCC (or
TCSTSNBMOGC, see above) build failed on me (except for out of space
errors), and binutils failure is even more rare.

It might be harder for non-free POSIX systems, and then it might not.
Many have open-source repositories with PMSes of some sort.

 > > I've given up more times than I can count (temporarily of course,
 > > when I've got a wekk of evenings free I get back to it) on putting
 > > together Windows dev environments, though.
 > 
 > It's not that hard, actually, especially if there's no need to run the
 > configure scripts (as I'd imagine will happen when Emacs supports some
 > kind of FFI).

No, it probably isn't, but since I do it less than once a year, and
once done, I use it once then forget it, it induces fear and
loathing. :-)





  reply	other threads:[~2014-06-28 16:30 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-26  9:20 Why not zlib-compress-region? Leo Liu
2014-06-26 12:07 ` Dmitry Antipov
2014-06-26 13:27   ` Stefan Monnier
2014-06-26 14:03     ` Leo Liu
2014-06-26 16:43       ` Stefan Monnier
2014-06-27 12:50         ` Aurélien Aptel
2014-06-27 13:28           ` Stefan Monnier
2014-06-27 15:32             ` Dmitry Antipov
2014-06-27 22:07               ` Stefan Monnier
2014-06-28  6:50                 ` Eli Zaretskii
2014-06-28 12:51                   ` Stephen J. Turnbull
2014-06-28 13:16                     ` Eli Zaretskii
2014-06-28 16:30                       ` Stephen J. Turnbull [this message]
2014-06-28 17:00                         ` Eli Zaretskii
2014-06-28 17:41                           ` Eli Zaretskii
2014-06-29  3:58                           ` Stephen J. Turnbull
2014-06-29 21:03                           ` Stefan Monnier
2014-06-28 18:06                         ` Paul Eggert
2014-06-28 14:07                   ` Richard Stallman
2014-06-27 19:48         ` Ted Zlatanov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87fvipvvwk.fsf@uwakimon.sk.tsukuba.ac.jp \
    --to=stephen@xemacs.org \
    --cc=aurelien.aptel+emacs@gmail.com \
    --cc=dmantipov@yandex.ru \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    --cc=sdl.web@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.