From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Sam Halliday Newsgroups: gmane.emacs.help Subject: Re: 64 bit official Windows builds Date: Sat, 9 Jan 2016 05:04:49 -0800 (PST) Message-ID: <6b5d747c-7abb-44fc-8f9a-3d629fb892a8@googlegroups.com> References: <2577057e-98d3-41ce-ade2-1496648b09c3@googlegroups.com> <837fk3m141.fsf@gnu.org> <87bn9evefh.fsf@wanadoo.es> <83r3ialic7.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1452344724 14816 80.91.229.3 (9 Jan 2016 13:05:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 9 Jan 2016 13:05:24 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Sat Jan 09 14:05:23 2016 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aHtCr-0005IF-PA for geh-help-gnu-emacs@m.gmane.org; Sat, 09 Jan 2016 14:05:21 +0100 Original-Received: from localhost ([::1]:40602 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aHtCr-0000l8-5M for geh-help-gnu-emacs@m.gmane.org; Sat, 09 Jan 2016 08:05:21 -0500 X-Received: by 10.182.236.4 with SMTP id uq4mr106137658obc.3.1452344690287; Sat, 09 Jan 2016 05:04:50 -0800 (PST) X-Received: by 10.50.57.84 with SMTP id g20mr110615igq.3.1452344690268; Sat, 09 Jan 2016 05:04:50 -0800 (PST) Original-Path: usenet.stanford.edu!o2no1409767iga.0!news-out.google.com!kr2ni44igb.0!nntp.google.com!o2no1409764iga.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Original-Newsgroups: gnu.emacs.help In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=86.21.102.205; posting-account=kRukCAoAAAANs-vsVh9dFwo5kp5pwnPz Original-NNTP-Posting-Host: 86.21.102.205 User-Agent: G2/1.0 Injection-Date: Sat, 09 Jan 2016 13:04:50 +0000 Original-Xref: usenet.stanford.edu gnu.emacs.help:216385 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.14 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.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:108675 Archived-At: Arash, It sounds like you know how to do this a lot better than I do. Is there any chance you could package this up so that everybody can get you= r 64 bit builds of Emacs for Windows from the FSF site? If the sources are = listed already, maybe you could just create a tarball containing all the so= urces of the compiler and required libraries?=20 It would be really good from an automation point of view if you could write= a little recipe (maybe an appveyor script?) that could be triggered when n= ew versions of emacs (or the compiler) are released. Best regards, Sam On Thursday, 7 January 2016 22:48:10 UTC, Arash Esbati wrote: > Eli Zaretskii writes: >=20 > >> From: =D3scar Fuentes > >> Date: Fri, 25 Dec 2015 14:35:46 +0100 > >>=20 > >> IIRC the problematic part is to create and distribute a source tarball > >> with all the libraries included on the binary package (graphic > >> libraries, SSL, etc). This was discussed on the past and can't recall > >> the outcome. > > > > It's up to the person who volunteers for the job. It's quite okay to > > upload only the Emacs binary that was compiled with support for the > > optional libraries, and expect the end users to download and itsall > > the DLLs separately. It is also okay to upload the DLLs as part of > > the binary distro, but then the corresponding sources should be on the > > same site. >=20 > I think that providing bare Emacs binaries without the corresponding > dll's is not really user friendly. I build Emacs on my Win 64bit > machine with Msys2/MinGW-w64 and it would be pain if I had to collect all > dll's myself somehow. OTOH, collecting and providing all the sources > along with the dll's is also not fun. Can there be a compromise? For > Msys2/MinGW-w64, all PKGBUILD files contain references the sources, e.g.: >=20 > https://github.com/Alexpux/MINGW-packages/blob/master/mingw-w64-libid= n/PKGBUILD >=20 > So one could say: Consult the PKGBUILD files for the sources > (incl. dependencies) for >=20 > - mingw-w64-libtiff > - mingw-w64-giflib > - mingw-w64-libpng > - mingw-w64-libjpeg-turbo > - mingw-w64-librsvg > - mingw-w64-libxml2 > - mingw-w64-gnutls > - mingw-w64-xpm-nox >=20 > Best, Arash