all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* windows installer
@ 2017-10-26 23:11 Phillip Lord
  2017-10-28 21:47 ` Richard Stallman
  2017-11-06  8:11 ` Jostein Kjønigsen
  0 siblings, 2 replies; 75+ messages in thread
From: Phillip Lord @ 2017-10-26 23:11 UTC (permalink / raw)
  To: emacs-devel


I've had a quick play and created an "installer" version of Emacs for
windows. Cheesy and ugly at the moment, but it works. It uses the NSIS
toolkit which is nicely packaged for msys2.

NSIS is free software, albeit the non GPL compatible CPL
(http://nsis.sourceforge.net/License). I don't believe this is a problem
as it would only be a packager. I'd welcome more informed opinion about
whether this is appropriate for Emacs.

Probably too late to put this onto Emacs-26 now I fear, but it could be
ready in time for Emacs-27. If any one is interested, I can uploaded it
to the pre-test website (as the Emacs source is already there).

As with the new zips I've created, this does raise questions about
release of updates to the binaries. This installer will contain (lots
of) other dependency files. My current plan is to freeze the
dependencies during pre-test. But this means, that these dependencies
will get old during the Emacs release cycle.

Anyway, thought's welcome.

Phil



^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: windows installer
  2017-10-26 23:11 windows installer Phillip Lord
@ 2017-10-28 21:47 ` Richard Stallman
  2017-11-06  8:11 ` Jostein Kjønigsen
  1 sibling, 0 replies; 75+ messages in thread
From: Richard Stallman @ 2017-10-28 21:47 UTC (permalink / raw)
  To: Phillip Lord; +Cc: emacs-devel

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > NSIS is free software, albeit the non GPL compatible CPL
  > (http://nsis.sourceforge.net/License). I don't believe this is a problem
  > as it would only be a packager. I'd welcome more informed opinion about
  > whether this is appropriate for Emacs.

I agree, it would not be a problem, since used only as a packager.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.




^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: windows installer
  2017-10-26 23:11 windows installer Phillip Lord
  2017-10-28 21:47 ` Richard Stallman
@ 2017-11-06  8:11 ` Jostein Kjønigsen
       [not found]   ` <87h8u6bae3.fsf@russet.org.uk>
  1 sibling, 1 reply; 75+ messages in thread
From: Jostein Kjønigsen @ 2017-11-06  8:11 UTC (permalink / raw)
  To: Phillip Lord; +Cc: emacs-devel

[-- Attachment #1: Type: text/plain, Size: 1883 bytes --]

As a (part time) Windows-user I'd very much appreciate this.

Like I've mentioned earlier on this mailing-list, I have some custom
scripts I use to manually assemble a new release when it's available,
but even then it's so much of a hastle that I can't always be bothered.
Having an installer which makes this a next-next-next process would
be a great
But I'm already on the train. Where this would clearly be most
benefitial is for new Windows/Emacs-users if they could get going in
the usual "next next next" Windows-fashion which they're already
accustomed to.
Feel free to publish some test-installers for the community to try out.
--
Vennlig hilsen
Jostein Kjønigsen

jostein@kjonigsen.net 🍵 jostein@gmail.com
https://jostein.kjonigsen.net


On Fri, Oct 27, 2017, at 12:11 AM, Phillip Lord wrote:
> 
> I've had a quick play and created an "installer" version of Emacs for> windows. Cheesy and ugly at the moment, but it works. It uses the NSIS> toolkit which is nicely packaged for msys2.
> 
> NSIS is free software, albeit the non GPL compatible CPL
> (http://nsis.sourceforge.net/License). I don't believe this is
> a problem> as it would only be a packager. I'd welcome more informed
> opinion about> whether this is appropriate for Emacs.
> 
> Probably too late to put this onto Emacs-26 now I fear, but it
> could be> ready in time for Emacs-27. If any one is interested, I can
> uploaded it> to the pre-test website (as the Emacs source is already there).
> 
> As with the new zips I've created, this does raise questions about
> release of updates to the binaries. This installer will contain (lots> of) other dependency files. My current plan is to freeze the
> dependencies during pre-test. But this means, that these dependencies> will get old during the Emacs release cycle.
> 
> Anyway, thought's welcome.
> 
> Phil
> 


[-- Attachment #2: Type: text/html, Size: 3009 bytes --]

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: windows installer
       [not found]     ` <WM!524810e63610127669556b68fb62cde560daf19be50fc52d4d63dd232af7bdb0490810e03b84a6559c9b2017d8462cc3!@mailhub-mx4.ncl.ac.uk>
@ 2017-11-08  7:31       ` Jostein Kjønigsen
  2017-11-10 17:01         ` Phillip Lord
  0 siblings, 1 reply; 75+ messages in thread
From: Jostein Kjønigsen @ 2017-11-08  7:31 UTC (permalink / raw)
  To: Phillip Lord; +Cc: emacs-devel

[-- Attachment #1: Type: text/plain, Size: 5917 bytes --]

Hey Phil.

I've done some testing on this installer now, and so far it seems most
things works as it should.
My impression is that on overall, this will make life much easier for
Windows-users, and maybe finally bring the installation-experience on
par with Linux-users who've for a long time just been able to "apt
install emacs", "dnf install emacs" or whatever.
I've tested on Linux with Wine and I've also tested on Windows 10, and
didn't encounter any critical issues or errors either place. It mostly
just worked.
This is no doubt a major-improvement.

If I were to provide some feedback or comments, I would like to point
out a few things.
*1. Not commonly downloaded (yet)*

For the time being, the installer is reported as "not commonly
downloaded", and gives a big red warning in MS EDGE. I'm guessing you'll
get the same in Chrome, and also possibly Firefox:
 

I've seen this before when developing and delivering other Windows-
software, and this should only appear in a transitional phase.
This will make the initial roll-out a little more painful, but it should
basically resolve itself over time.
I'm just mentioning this, so that if you get other comments on the same
subject, I don't think you need to be overly worried about it.
*2. Installer is not signed**
*

These days trying to distribute a unsigned installer on Windows is
getting increasingly cumbersome. Especially for the end-users trying
to run it.
Upon launching the installer, I'm getting this warnin:

 
To run this, you have to know that you can click "More info" and proceed
from there:
 

This I think can become a major hindrance for some new users, and
unfortunately this problem will not solve itself.
The solution is signing the installer. Signing an installer (and any EXE-
file really) is fairly trivial and there are tools for this in the
Windows SDK[1]. (And make sure to use the time-stamp options too!)
To do this of course, you will have to be in possession of a X509 code-
signing  certificate. If GNU already has one of these, it should be
easy to convert into whatever format Windows expects it to be in, and
put into use.
If not... This will cost money. How much, I do not know. Symantic has
Authenticode-certificates starting at $500[2]. While StartCom is no
longer a trusted CA, I know they used to offer a significantly cheaper
option. That gives me hope that there might be options cheaper than $500
available.
If this is deemed important enough to resolve, I think the first course
of action will have to be finding an affordable option for buying and
renewing code-signing certificates.
Managing the security of this certificate is also important concern, but
one we can dig deeper into at a later point.
Also setting up code-signing in a CI-environment (and especially for a
FOSS-project) can be a bit of a pain. Is the Windows-installer built in
a CI-environment? Should it be? If so, this may also something we will
need to solve too, but again, that's definitely something for later.
*3. Installer defaults**
*

Once launched the installer seems to work as intended. I do however
question some of the defaults provided.
Install default directory has IMO at least 2 issues:

 * *The default is to install to a folder on the desktop. This is highly
   unconventional.*

I suggest we instead use the user's profile folder. From an initial
probe, this can be found in at least the following environment-variables
on my Windows 10 test-machine: USERPROFILE (or by concatenating
HOMEDRIVE and HOMEPATH ).

 * *The default install-directory includes the Emacs-version.*

This means that if I create any mappings to this installed Emacs-
version, add it to the path, and I later want to upgrade Emacs to a
newer version... Will that be installed in a different place? Will
I have to re-register Emacs all over the registry and in all open-
with dialogs?

Not including the version-number will give us much less issues down the
line, especially for upgrades.
 * It should be noted that the Start-menu folder created for Emacs also
   contains the version number.

For the same reasons given above, I advice that we also remove the version-
number from this folder too. Again, it will make upgrades and similar
scenarios much more hygienic, with less "old stuff" we have to clean up,
in order to avoid stale links, or double program-registrations for the
same piece of software.
Apart from that, I'm all positive about this initiative and the
improvements it provides. This is just so much better.
--
Regards
Jostein Kjønigsen

jostein@kjonigsen.net 🍵 jostein@gmail.com
https://jostein.kjonigsen.net


On Tue, Nov 7, 2017, at 12:23 PM, Phillip Lord wrote:
> 
> The first snapshot is up on alpha.gnu.org!
> 
> Feedback welcome. And, I think you are right, this will be a
> big win for> Emacs users new to the party; I've seen people looking at the zip, and> not knowning what to do.
> 
> Phil
> 
> Jostein Kjønigsen <jostein@secure.kjonigsen.net> writes:
> 
>> As a (part time) Windows-user I'd very much appreciate this.
>> 
>> Like I've mentioned earlier on this mailing-list, I have some custom>> scripts I use to manually assemble a new release when it's available,>> but even then it's so much of a hastle that I can't always be
>> bothered.>> Having an installer which makes this a next-next-next process would
>> be a great
>> But I'm already on the train. Where this would clearly be most
>> benefitial is for new Windows/Emacs-users if they could get going in>> the usual "next next next" Windows-fashion which they're already
>> accustomed to.
>> Feel free to publish some test-installers for the community to
>> try out.> 


Links:

  1. https://docs.microsoft.com/en-us/windows-hardware/drivers/devtest/signtool
  2. https://www.websecurity.symantec.com/code-signing

[-- Attachment #2.1: Type: text/html, Size: 8996 bytes --]

[-- Attachment #2.2: image.png --]
[-- Type: image/png, Size: 6231 bytes --]

[-- Attachment #2.3: image.png --]
[-- Type: image/png, Size: 10006 bytes --]

[-- Attachment #2.4: image.png --]
[-- Type: image/png, Size: 12330 bytes --]

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: windows installer
  2017-11-08  7:31       ` Jostein Kjønigsen
@ 2017-11-10 17:01         ` Phillip Lord
  2017-11-10 18:52           ` Eli Zaretskii
       [not found]           ` <<83ineiotjr.fsf@gnu.org>
  0 siblings, 2 replies; 75+ messages in thread
From: Phillip Lord @ 2017-11-10 17:01 UTC (permalink / raw)
  To: Jostein Kjønigsen; +Cc: jostein, emacs-devel

Jostein Kjønigsen <jostein@secure.kjonigsen.net> writes:
> This is no doubt a major-improvement.

Thank you!


> If I were to provide some feedback or comments, I would like to point
> out a few things.
>
> 1. Not commonly downloaded (yet)
>
> For the time being, the installer is reported as "not commonly
> downloaded", and gives a big red warning in MS EDGE. I'm guessing
> you'll get the same in Chrome, and also possibly Firefox:
>
> I've seen this before when developing and delivering other
> Windows-software, and this should only appear in a transitional phase.
>
> This will make the initial roll-out a little more painful, but it
>should basically resolve itself over time.
>
> I'm just mentioning this, so that if you get other comments on the
> same subject, I don't think you need to be overly worried about it.

Okay. For the snapshots, I will probably start adding a date to the file
name which will exacerbate this, but as you say it should go away when
Emacs-27 comes out.





> 2. Installer is not signed
>
> These days trying to distribute a unsigned installer on Windows is
> getting increasingly cumbersome. Especially for the end-users trying
> to run it.


Yeah, couldn't agree more. This has to be fixed.



> The solution is signing the installer. Signing an installer (and any
> EXE-file really) is fairly trivial and there are tools for this in the
> Windows SDK. (And make sure to use the time-stamp options too!)
>
> To do this of course, you will have to be in possession of a X509
> code-signing certificate. If GNU already has one of these, it should
> be easy to convert into whatever format Windows expects it to be in,
> and put into use.

A single GNU one would be the thing, I think.

> If this is deemed important enough to resolve, I think the first
> course of action will have to be finding an affordable option for
> buying and renewing code-signing certificates.
>
> Managing the security of this certificate is also important concern,
> but one we can dig deeper into at a later point.

One solution here would be to sign the exe's when I upload them; this
means that the signature would happen inside gnu.org. AFAICT, it's
possible to do the signature with mono based tools -- so gnu.org would
not need a windows box to achieve this. I guess they'd need to re-GPG
sign it also, as signtool signature would break the GPG one.

> Also setting up code-signing in a CI-environment (and especially for a
> FOSS-project) can be a bit of a pain. Is the Windows-installer built
> in a CI-environment? Should it be? If so, this may also something we
> will need to solve too, but again, that's definitely something for
> later.

Signing on upload would solve this also. But, no, the windows-installer,
like the rest of the windows binaries on a cheap media box in my living
room.



> 3. Installer defaults
>
> Once launched the installer seems to work as intended. I do however question some of the defaults provided.
>
> Install default directory has IMO at least 2 issues:
>
> * The default is to install to a folder on the desktop. This is highly unconventional.

Yeah, known issue "Currently, it installs to Desktop which is not right,
but was easy.".

It's quick and easy to see what is going on there.

>  I suggest we instead use the user's profile folder. From an initial
>  probe, this can be found in at least the following
>  environment-variables on my Windows 10 test-machine: USERPROFILE (or
>  by concatenating HOMEDRIVE and HOMEPATH ).

I'll fix this.


>
> * The default install-directory includes the Emacs-version.
>
>  This means that if I create any mappings to this installed
>  Emacs-version, add it to the path, and I later want to upgrade Emacs
>  to a newer version... Will that be installed in a different place?
>  Will I have to re-register Emacs all over the registry and in all
>  open-with dialogs?

No idea.

I'm presuming most people will not add it to the path, but launch it
from the shortcut that the installation adds.



>  Not including the version-number will give us much less issues down
>  the line, especially for upgrades.

I think it will make it hard for the installer to notice downgrades,
though.

>
> * It should be noted that the Start-menu folder created for Emacs also
> contains the version number.
>
>  For the same reasons given above, I advice that we also remove the
>  version-number from this folder too. Again, it will make upgrades and
>  similar scenarios much more hygienic, with less "old stuff" we have
>  to clean up, in order to avoid stale links, or double
>  program-registrations for the same piece of software.

Would you be able to test the program-registrations for me? You should
be able to do this just by changing the directory name.

For the start menu, what about adding both "Emacs" and "Emacs-27"?


> Apart from that, I'm all positive about this initiative and the
> improvements it provides. This is just so much better.

Me too. I'm tired of seeing blank looks on the faces of people shown the
zip.

Phil



^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: windows installer
  2017-11-10 17:01         ` Phillip Lord
@ 2017-11-10 18:52           ` Eli Zaretskii
  2017-11-10 20:46             ` Stefan Monnier
                               ` (2 more replies)
       [not found]           ` <<83ineiotjr.fsf@gnu.org>
  1 sibling, 3 replies; 75+ messages in thread
From: Eli Zaretskii @ 2017-11-10 18:52 UTC (permalink / raw)
  To: Phillip Lord; +Cc: jostein, jostein, emacs-devel

> From: phillip.lord@russet.org.uk (Phillip Lord)
> Date: Fri, 10 Nov 2017 17:01:39 +0000
> Cc: jostein@kjonigsen.net, emacs-devel@gnu.org
> 
> >  I suggest we instead use the user's profile folder. From an initial
> >  probe, this can be found in at least the following
> >  environment-variables on my Windows 10 test-machine: USERPROFILE (or
> >  by concatenating HOMEDRIVE and HOMEPATH ).
> 
> I'll fix this.

Just to make this more complex: the Windows platform conventions frown
upon installing stuff in that directory; you are supposed to create a
subdirectory and install there.

And programs should not end up there, they should be under
%ProgramFiles% instead.  The user's directory is for files, not for
programs.

> I'm presuming most people will not add it to the path, but launch it
> from the shortcut that the installation adds.

They _will_ want to add it to PATH if they want to install packages
from the likes of ELPA, which frequently come with Makefiles that
invoke Emacs to compile the Lisp files.



^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: windows installer
  2017-11-10 18:52           ` Eli Zaretskii
@ 2017-11-10 20:46             ` Stefan Monnier
  2017-11-10 21:22               ` John Mastro
                                 ` (2 more replies)
  2017-11-10 21:33             ` Fabrice Popineau
  2017-11-10 23:27             ` Phillip Lord
  2 siblings, 3 replies; 75+ messages in thread
From: Stefan Monnier @ 2017-11-10 20:46 UTC (permalink / raw)
  To: emacs-devel

> They _will_ want to add it to PATH if they want to install packages
> from the likes of ELPA, which frequently come with Makefiles that
> invoke Emacs to compile the Lisp files.

For lack of familiarity with the Windows world, I don't know if typical
Windows users will want to add it to PATH (as a GNU/Linux user, of
course I'd do that), but I think the "frequently" above is incorrect.

The way Elisp files are compiled by package.el is to do it in the
running Emacs rather than by executing a separate Emacs session, AFAIK.

And even if you configure it to use something like async.el, doesn't
(expand-file-name invocation-name invocation-directory) let async.el find
an Emacs executable even when it's not in PATH?


        Stefan




^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: windows installer
  2017-11-10 20:46             ` Stefan Monnier
@ 2017-11-10 21:22               ` John Mastro
  2017-11-10 21:35               ` Fabrice Popineau
  2017-11-11  7:33               ` Eli Zaretskii
  2 siblings, 0 replies; 75+ messages in thread
From: John Mastro @ 2017-11-10 21:22 UTC (permalink / raw)
  To: emacs-devel; +Cc: Stefan Monnier

Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> And even if you configure it to use something like async.el, doesn't
> (expand-file-name invocation-name invocation-directory) let async.el find
> an Emacs executable even when it's not in PATH?

Yep, that's exactly what async.el does.

        John



^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: windows installer
  2017-11-10 18:52           ` Eli Zaretskii
  2017-11-10 20:46             ` Stefan Monnier
@ 2017-11-10 21:33             ` Fabrice Popineau
  2017-11-11  7:35               ` Eli Zaretskii
  2017-11-10 23:27             ` Phillip Lord
  2 siblings, 1 reply; 75+ messages in thread
From: Fabrice Popineau @ 2017-11-10 21:33 UTC (permalink / raw)
  To: Eli Zaretskii
  Cc: Jostein Kjønigsen, Emacs developers, Jostein Kjønigsen,
	Phillip Lord

[-- Attachment #1: Type: text/plain, Size: 1068 bytes --]

2017-11-10 19:52 GMT+01:00 Eli Zaretskii <eliz@gnu.org>:

> > From: phillip.lord@russet.org.uk (Phillip Lord)
> > Date: Fri, 10 Nov 2017 17:01:39 +0000
> > Cc: jostein@kjonigsen.net, emacs-devel@gnu.org
> >
> > >  I suggest we instead use the user's profile folder. From an initial
> > >  probe, this can be found in at least the following
> > >  environment-variables on my Windows 10 test-machine: USERPROFILE (or
> > >  by concatenating HOMEDRIVE and HOMEPATH ).
> >
> > I'll fix this.
>
> Just to make this more complex: the Windows platform conventions frown
> upon installing stuff in that directory; you are supposed to create a
> subdirectory and install there.
>
> And programs should not end up there, they should be under
> %ProgramFiles% instead.  The user's directory is for files, not for
> programs.
>

That are the recommendations, yes. But I have never installed stuff like
Emacs or TeX (or others)
in %ProgramFiles%.
And neither Cygwin or MSYS2 install in this directory.
You are still free to install stuff in c:\Gnu is you chose to do so.

Fabrice

[-- Attachment #2: Type: text/html, Size: 1702 bytes --]

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: windows installer
  2017-11-10 20:46             ` Stefan Monnier
  2017-11-10 21:22               ` John Mastro
@ 2017-11-10 21:35               ` Fabrice Popineau
  2017-11-11  7:33               ` Eli Zaretskii
  2 siblings, 0 replies; 75+ messages in thread
From: Fabrice Popineau @ 2017-11-10 21:35 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: Emacs developers

[-- Attachment #1: Type: text/plain, Size: 689 bytes --]

2017-11-10 21:46 GMT+01:00 Stefan Monnier <monnier@iro.umontreal.ca>:

> > They _will_ want to add it to PATH if they want to install packages
> > from the likes of ELPA, which frequently come with Makefiles that
> > invoke Emacs to compile the Lisp files.
>
> For lack of familiarity with the Windows world, I don't know if typical
> Windows users will want to add it to PATH (as a GNU/Linux user, of
> course I'd do that), but I think the "frequently" above is incorrect.
>

Makefiles ? But the average Windows user does not have a make.exe program
on his machine
and does not even know what it is used for.

(Admittedly, an Emacs user is probably not an average Windows user).

Fabrice

[-- Attachment #2: Type: text/html, Size: 1141 bytes --]

^ permalink raw reply	[flat|nested] 75+ messages in thread

* RE: windows installer
       [not found]           ` <<83ineiotjr.fsf@gnu.org>
@ 2017-11-10 21:43             ` Drew Adams
  2017-11-10 23:35               ` Phillip Lord
  2017-11-11  7:40               ` Eli Zaretskii
  0 siblings, 2 replies; 75+ messages in thread
From: Drew Adams @ 2017-11-10 21:43 UTC (permalink / raw)
  To: Eli Zaretskii, Phillip Lord; +Cc: jostein, jostein, emacs-devel

> > >  I suggest we instead use the user's profile folder. From an initial
> > >  probe, this can be found in at least the following
> > >  environment-variables on my Windows 10 test-machine: USERPROFILE (or
> > >  by concatenating HOMEDRIVE and HOMEPATH ).
> >
> > I'll fix this.
> 
> Just to make this more complex: the Windows platform conventions frown
> upon installing stuff in that directory; you are supposed to create a
> subdirectory and install there.
> 
> And programs should not end up there, they should be under
> %ProgramFiles% instead.  The user's directory is for files, not for
> programs.
> 
> > I'm presuming most people will not add it to the path, but launch it
> > from the shortcut that the installation adds.
> 
> They _will_ want to add it to PATH if they want to install packages
> from the likes of ELPA, which frequently come with Makefiles that
> invoke Emacs to compile the Lisp files.

I haven't been following this thread.  But I was hoping that
one thing that would come out of it is push-button building
of Emacs for Windows.  I was hoping too that the result would
be (could be, at least) what we get now: a build complete with
binary executables and Lisp source code - but without any
"installation" into Program Files etc being necessary (i.e.,
hard-coded).

I, for one, am not interested in "installing" any Emacs build
(Program Files etc.).  I use multiple builds from different
releases.  I don't even want anything added, by default, to
PATH.

But an easy way to build Emacs for Windows - essentially
push-button, specifying only an output directory and optionally
other things that might be relevant - would be welcome.



^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: windows installer
  2017-11-10 18:52           ` Eli Zaretskii
  2017-11-10 20:46             ` Stefan Monnier
  2017-11-10 21:33             ` Fabrice Popineau
@ 2017-11-10 23:27             ` Phillip Lord
  2017-11-11  0:25               ` Fabrice Popineau
  2017-11-11  7:48               ` Eli Zaretskii
  2 siblings, 2 replies; 75+ messages in thread
From: Phillip Lord @ 2017-11-10 23:27 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: jostein, jostein, emacs-devel

Eli Zaretskii <eliz@gnu.org> writes:

>> From: phillip.lord@russet.org.uk (Phillip Lord)
>> Date: Fri, 10 Nov 2017 17:01:39 +0000
>> Cc: jostein@kjonigsen.net, emacs-devel@gnu.org
>> 
>> >  I suggest we instead use the user's profile folder. From an initial
>> >  probe, this can be found in at least the following
>> >  environment-variables on my Windows 10 test-machine: USERPROFILE (or
>> >  by concatenating HOMEDRIVE and HOMEPATH ).
>> 
>> I'll fix this.
>
> Just to make this more complex: the Windows platform conventions frown
> upon installing stuff in that directory; you are supposed to create a
> subdirectory and install there.
>
> And programs should not end up there, they should be under
> %ProgramFiles% instead.  The user's directory is for files, not for
> programs.


The disadvantage with ProgramFiles is that it requires elevation, which
user profile does not, although user profiles gets mixed up with
roaming. Although, elevation is pretty normal for installation. But I
didn't want to it straight away in case I made the uninstaller
accidentally delete my windows installation.

I'm also investigating making Emacs a portable app (as in
PortableApps.com), assuming everyone is happy with this. This might be
the better route for single user (and portable) installs.



>> I'm presuming most people will not add it to the path, but launch it
>> from the shortcut that the installation adds.
>
> They _will_ want to add it to PATH if they want to install packages
> from the likes of ELPA, which frequently come with Makefiles that
> invoke Emacs to compile the Lisp files.

Really?

Phil



^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: windows installer
  2017-11-10 21:43             ` Drew Adams
@ 2017-11-10 23:35               ` Phillip Lord
  2017-11-11  7:49                 ` Eli Zaretskii
  2017-11-11  7:40               ` Eli Zaretskii
  1 sibling, 1 reply; 75+ messages in thread
From: Phillip Lord @ 2017-11-10 23:35 UTC (permalink / raw)
  To: Drew Adams; +Cc: jostein, Eli Zaretskii, jostein, emacs-devel

Drew Adams <drew.adams@oracle.com> writes:
>> They _will_ want to add it to PATH if they want to install packages
>> from the likes of ELPA, which frequently come with Makefiles that
>> invoke Emacs to compile the Lisp files.
>
> I haven't been following this thread.  But I was hoping that
> one thing that would come out of it is push-button building
> of Emacs for Windows.  I was hoping too that the result would
> be (could be, at least) what we get now: a build complete with
> binary executables and Lisp source code - but without any
> "installation" into Program Files etc being necessary (i.e.,
> hard-coded).

My scripts build all the distribution scripts with a single command (not
a push-button, unless this includes the "enter" key). But they do assume
that you have msys and the rest installed. At heart, though, they just
run three commands (autogen.sh;configure;make install).

> I, for one, am not interested in "installing" any Emacs build
> (Program Files etc.).  I use multiple builds from different
> releases.  I don't even want anything added, by default, to
> PATH.

I am debating with my installer whether to allow multiple versions or do
the more normal windows things of one version. I suspect the latter is
more sensible because, well, it's the normal windows thing.

> But an easy way to build Emacs for Windows - essentially
> push-button, specifying only an output directory and optionally
> other things that might be relevant - would be welcome.

Other than what we have, this isn't really on my radar. Building emacs
from source is now as easy as I need it to be.

Phil



^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: windows installer
  2017-11-10 23:27             ` Phillip Lord
@ 2017-11-11  0:25               ` Fabrice Popineau
  2017-11-11 11:25                 ` Phillip Lord
  2017-11-11  7:48               ` Eli Zaretskii
  1 sibling, 1 reply; 75+ messages in thread
From: Fabrice Popineau @ 2017-11-11  0:25 UTC (permalink / raw)
  To: Phillip Lord
  Cc: Jostein Kjønigsen, Eli Zaretskii, Jostein Kjønigsen,
	Emacs developers

[-- Attachment #1: Type: text/plain, Size: 1652 bytes --]

2017-11-11 0:27 GMT+01:00 Phillip Lord <phillip.lord@russet.org.uk>:

> Eli Zaretskii <eliz@gnu.org> writes:
>
> >> From: phillip.lord@russet.org.uk (Phillip Lord)
> >> Date: Fri, 10 Nov 2017 17:01:39 +0000
> >> Cc: jostein@kjonigsen.net, emacs-devel@gnu.org
> >>
> >> >  I suggest we instead use the user's profile folder. From an initial
> >> >  probe, this can be found in at least the following
> >> >  environment-variables on my Windows 10 test-machine: USERPROFILE (or
> >> >  by concatenating HOMEDRIVE and HOMEPATH ).
> >>
> >> I'll fix this.
> >
> > Just to make this more complex: the Windows platform conventions frown
> > upon installing stuff in that directory; you are supposed to create a
> > subdirectory and install there.
> >
> > And programs should not end up there, they should be under
> > %ProgramFiles% instead.  The user's directory is for files, not for
> > programs.
>
>
> The disadvantage with ProgramFiles is that it requires elevation, which
> user profile does not, although user profiles gets mixed up with
> roaming. Although, elevation is pretty normal for installation. But I
> didn't want to it straight away in case I made the uninstaller
> accidentally delete my windows installation.
>
>
User profiles are subject to roaming. When you are on a Windows network,
it means your emacs directory is copied everytime you log in.
Definitely not a good idea.



> I'm also investigating making Emacs a portable app (as in
> PortableApps.com), assuming everyone is happy with this. This might be
> the better route for single user (and portable) installs.
>
>
But Emacs is already portable. What do I miss here ?

Fabrice

[-- Attachment #2: Type: text/html, Size: 2627 bytes --]

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: windows installer
  2017-11-10 20:46             ` Stefan Monnier
  2017-11-10 21:22               ` John Mastro
  2017-11-10 21:35               ` Fabrice Popineau
@ 2017-11-11  7:33               ` Eli Zaretskii
  2017-11-11 11:34                 ` Phillip Lord
                                   ` (2 more replies)
  2 siblings, 3 replies; 75+ messages in thread
From: Eli Zaretskii @ 2017-11-11  7:33 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: emacs-devel

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Fri, 10 Nov 2017 15:46:09 -0500
> 
> > They _will_ want to add it to PATH if they want to install packages
> > from the likes of ELPA, which frequently come with Makefiles that
> > invoke Emacs to compile the Lisp files.
> 
> For lack of familiarity with the Windows world, I don't know if typical
> Windows users will want to add it to PATH (as a GNU/Linux user, of
> course I'd do that), but I think the "frequently" above is incorrect.
> 
> The way Elisp files are compiled by package.el is to do it in the
> running Emacs rather than by executing a separate Emacs session, AFAIK.
> 
> And even if you configure it to use something like async.el, doesn't
> (expand-file-name invocation-name invocation-directory) let async.el find
> an Emacs executable even when it's not in PATH?

Maybe I'm missing something.  29 packages (out of 166) in ELPA have a
Makefile.  Taking just one random Makefile, company/Makefile, I see
this:

  EMACS=emacs
  [...]

  compile:
	  ${EMACS} -Q --batch -L . -f batch-byte-compile company.el company-*.el

If this Makefile is invoked with "make compile", it clearly expects
Emacs to be found along PATH.  And even if Make is invoked from Emacs,
the directory where the Emacs binary was found is not added to PATH.
So how can this work without Emacs's binary being on PATH?  And what
am I missing here?



^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: windows installer
  2017-11-10 21:33             ` Fabrice Popineau
@ 2017-11-11  7:35               ` Eli Zaretskii
  0 siblings, 0 replies; 75+ messages in thread
From: Eli Zaretskii @ 2017-11-11  7:35 UTC (permalink / raw)
  To: Fabrice Popineau; +Cc: jostein, emacs-devel, jostein, phillip.lord

> From: Fabrice Popineau <fabrice.popineau@gmail.com>
> Date: Fri, 10 Nov 2017 22:33:43 +0100
> Cc: Phillip Lord <phillip.lord@russet.org.uk>, 
> 	Jostein Kjønigsen <jostein@kjonigsen.net>, 
> 	Jostein Kjønigsen <jostein@secure.kjonigsen.net>, 
> 	Emacs developers <emacs-devel@gnu.org>
> 
>  And programs should not end up there, they should be under
>  %ProgramFiles% instead.  The user's directory is for files, not for
>  programs.
> 
> That are the recommendations, yes. But I have never installed stuff like Emacs or TeX (or others)
> in %ProgramFiles%.

Neither did I.  But did you ever install programs under
%USERPROFILE%\%USERNAME%?  I don't think so.  And my comment was to
the suggestion to install in the latter place.

> You are still free to install stuff in c:\Gnu is you chose to do so.

Of course.  I never said anything to the contrary.



^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: windows installer
  2017-11-10 21:43             ` Drew Adams
  2017-11-10 23:35               ` Phillip Lord
@ 2017-11-11  7:40               ` Eli Zaretskii
  2017-11-11  9:42                 ` Yuri Khan
  2017-11-11 16:39                 ` Drew Adams
  1 sibling, 2 replies; 75+ messages in thread
From: Eli Zaretskii @ 2017-11-11  7:40 UTC (permalink / raw)
  To: Drew Adams; +Cc: jostein, emacs-devel, jostein, phillip.lord

> Date: Fri, 10 Nov 2017 13:43:08 -0800 (PST)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: jostein@secure.kjonigsen.net, jostein@kjonigsen.net, emacs-devel@gnu.org
> 
> I, for one, am not interested in "installing" any Emacs build
> (Program Files etc.).  I use multiple builds from different
> releases.  I don't even want anything added, by default, to
> PATH.

Then you should be fine with just unzipping a zip file, because by
default the Windows explorer does that into a separate directory.

But this installer is not for people like you or me who know what they
are doing and have special needs and requirements.  It is primarily
for the naïve (a.k.a. "newbie") who just want to be able to invoke the
installer and get Emacs installed "correctly", meaning that Emacs is
available to any other program running on the system.  And that means
being installed where other programs are installed (which gives them
additional protection by system-wide processes and features), and
being on PATH.



^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: windows installer
  2017-11-10 23:27             ` Phillip Lord
  2017-11-11  0:25               ` Fabrice Popineau
@ 2017-11-11  7:48               ` Eli Zaretskii
  2017-11-11 11:24                 ` Phillip Lord
  1 sibling, 1 reply; 75+ messages in thread
From: Eli Zaretskii @ 2017-11-11  7:48 UTC (permalink / raw)
  To: Phillip Lord; +Cc: jostein, jostein, emacs-devel

> From: phillip.lord@russet.org.uk (Phillip Lord)
> Cc: jostein@secure.kjonigsen.net,  jostein@kjonigsen.net,  emacs-devel@gnu.org
> Date: Fri, 10 Nov 2017 23:27:49 +0000
> 
> >> >  environment-variables on my Windows 10 test-machine: USERPROFILE (or
> >> >  by concatenating HOMEDRIVE and HOMEPATH ).
> >> 
> >> I'll fix this.
> >
> > Just to make this more complex: the Windows platform conventions frown
> > upon installing stuff in that directory; you are supposed to create a
> > subdirectory and install there.
> >
> > And programs should not end up there, they should be under
> > %ProgramFiles% instead.  The user's directory is for files, not for
> > programs.
> 
> The disadvantage with ProgramFiles is that it requires elevation, which
> user profile does not, although user profiles gets mixed up with
> roaming. Although, elevation is pretty normal for installation. But I
> didn't want to it straight away in case I made the uninstaller
> accidentally delete my windows installation.

I don't think I understand the last sentence.

For the rest, installing into the user's profile because doing TRT is
harder is not a sufficient reason in my book.  If you want to avoid
elevation (which I don't think you should, given that this is "normal"
Windows behavior nowadays), then install into a directory that is
neither user profile nor Program Files (and maybe not even drive C:,
if there is another drive).  But going to the user profile is highly
unusual, to say the least.

> > They _will_ want to add it to PATH if they want to install packages
> > from the likes of ELPA, which frequently come with Makefiles that
> > invoke Emacs to compile the Lisp files.
> 
> Really?

AFAIU, yes.

And even if ELPA packages have alternatives which don't invoke Make,
there will be other situations where building a package with Emacs
support will want to invoke Emacs.  One such example is GNU ID-utils.

IOW, Emacs is not just a GUI application used interactively, it is
also a program that supports batch-mode invocation, and that mode is
at times used by other programs.  Keeping the Emacs binary off the
users' system PATH is therefore less than ideal, because the users
will then bump into subtle problems whereby Emacs seems "unavailable".



^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: windows installer
  2017-11-10 23:35               ` Phillip Lord
@ 2017-11-11  7:49                 ` Eli Zaretskii
  0 siblings, 0 replies; 75+ messages in thread
From: Eli Zaretskii @ 2017-11-11  7:49 UTC (permalink / raw)
  To: Phillip Lord; +Cc: jostein, jostein, drew.adams, emacs-devel

> From: phillip.lord@russet.org.uk (Phillip Lord)
> Cc: Eli Zaretskii <eliz@gnu.org>,  jostein@kjonigsen.net,  jostein@secure.kjonigsen.net,  emacs-devel@gnu.org
> Date: Fri, 10 Nov 2017 23:35:35 +0000
> 
> I am debating with my installer whether to allow multiple versions or do
> the more normal windows things of one version. I suspect the latter is
> more sensible because, well, it's the normal windows thing.

I agree.  For those who want multiple versions, providing an opt-in
option of installing into a user-specified directory should suffice.



^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: windows installer
  2017-11-11  7:40               ` Eli Zaretskii
@ 2017-11-11  9:42                 ` Yuri Khan
  2017-11-11 10:37                   ` Eli Zaretskii
  2017-11-11 16:39                 ` Drew Adams
  1 sibling, 1 reply; 75+ messages in thread
From: Yuri Khan @ 2017-11-11  9:42 UTC (permalink / raw)
  To: Eli Zaretskii
  Cc: jostein, Phillip Lord, Jostein Kjønigsen, Drew Adams,
	Emacs developers

On Sat, Nov 11, 2017 at 2:40 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> It is primarily
> for the naïve (a.k.a. "newbie") who just want to be able to invoke the
> installer and get Emacs installed "correctly", meaning that Emacs is
> available to any other program running on the system.  And that means
> being installed where other programs are installed (which gives them
> additional protection by system-wide processes and features), and
> being on PATH.

Being on the PATH is not a necessary condition. In the case of a
single user-facing binary, it is more efficient to register it on the
App Paths registry key.

https://msdn.microsoft.com/en-us/library/windows/desktop/ee872121(v=vs.85).aspx



^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: windows installer
  2017-11-11  9:42                 ` Yuri Khan
@ 2017-11-11 10:37                   ` Eli Zaretskii
  0 siblings, 0 replies; 75+ messages in thread
From: Eli Zaretskii @ 2017-11-11 10:37 UTC (permalink / raw)
  To: Yuri Khan; +Cc: jostein, phillip.lord, jostein, drew.adams, emacs-devel

> From: Yuri Khan <yuri.v.khan@gmail.com>
> Date: Sat, 11 Nov 2017 16:42:41 +0700
> Cc: Drew Adams <drew.adams@oracle.com>, Jostein Kjønigsen <jostein@kjonigsen.net>, 
> 	Emacs developers <emacs-devel@gnu.org>, jostein@secure.kjonigsen.net, 
> 	Phillip Lord <phillip.lord@russet.org.uk>
> 
> Being on the PATH is not a necessary condition. In the case of a
> single user-facing binary, it is more efficient to register it on the
> App Paths registry key.
> 
> https://msdn.microsoft.com/en-us/library/windows/desktop/ee872121(v=vs.85).aspx

This has its own problems: it requires changing the Registry if you
want to modify the setting.  Also, will it work from the shell prompt?
I'm not sure.  More generally, the above documentation talks about
ShellExecuteEx, but that's not the only way programs are executed on
Windows.

Personally, I find all those fancy methods to be unnecessary
complications at best, and a source of subtle problems at worst.  PATH
is there, and if needed, can be customized per user as well.  If
nothing else, it makes the dialog easier between Windows users and
Emacs developers who are only familiar with Posix hosts.  So why would
we want to advise users to use those Windows-specific features?  I see
no compelling reasons.



^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: windows installer
  2017-11-11  7:48               ` Eli Zaretskii
@ 2017-11-11 11:24                 ` Phillip Lord
  2017-11-11 12:01                   ` Eli Zaretskii
  0 siblings, 1 reply; 75+ messages in thread
From: Phillip Lord @ 2017-11-11 11:24 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: jostein, jostein, emacs-devel

Eli Zaretskii <eliz@gnu.org> writes:

>> From: phillip.lord@russet.org.uk (Phillip Lord)
>> Cc: jostein@secure.kjonigsen.net,  jostein@kjonigsen.net,  emacs-devel@gnu.org
>> Date: Fri, 10 Nov 2017 23:27:49 +0000
>> 
>> >> >  environment-variables on my Windows 10 test-machine: USERPROFILE (or
>> >> >  by concatenating HOMEDRIVE and HOMEPATH ).
>> >> 
>> >> I'll fix this.
>> >
>> > Just to make this more complex: the Windows platform conventions frown
>> > upon installing stuff in that directory; you are supposed to create a
>> > subdirectory and install there.
>> >
>> > And programs should not end up there, they should be under
>> > %ProgramFiles% instead.  The user's directory is for files, not for
>> > programs.
>> 
>> The disadvantage with ProgramFiles is that it requires elevation, which
>> user profile does not, although user profiles gets mixed up with
>> roaming. Although, elevation is pretty normal for installation. But I
>> didn't want to it straight away in case I made the uninstaller
>> accidentally delete my windows installation.
>
> I don't think I understand the last sentence.

"didn't want to do it", sorry.

The installer includes an uninstaller which recursively deletes the
directory tree. If I get it wrong, AFAICT, it will delete anything I
tell it to. Being elevated seems a bad thing during development.


> For the rest, installing into the user's profile because doing TRT is
> harder is not a sufficient reason in my book.  If you want to avoid
> elevation (which I don't think you should, given that this is "normal"
> Windows behavior nowadays), then install into a directory that is
> neither user profile nor Program Files (and maybe not even drive C:,
> if there is another drive).  But going to the user profile is highly
> unusual, to say the least.
>
>> > They _will_ want to add it to PATH if they want to install packages
>> > from the likes of ELPA, which frequently come with Makefiles that
>> > invoke Emacs to compile the Lisp files.
>> 
>> Really?
>
> AFAIU, yes.


I checked; the makefiles in ELPA are for the developers pleasure, not
users. The make file doesn't get pulled down, nor is it run client
side. MELPA is the same -- there is no build step from git source to end
package -- it's all just lisp.


> And even if ELPA packages have alternatives which don't invoke Make,
> there will be other situations where building a package with Emacs
> support will want to invoke Emacs.  One such example is GNU ID-utils.
>
> IOW, Emacs is not just a GUI application used interactively, it is
> also a program that supports batch-mode invocation, and that mode is
> at times used by other programs.  Keeping the Emacs binary off the
> users' system PATH is therefore less than ideal, because the users
> will then bump into subtle problems whereby Emacs seems "unavailable".

I suspect that these sort of users will install with the zip file or
equivalent.

Phil



^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: windows installer
  2017-11-11  0:25               ` Fabrice Popineau
@ 2017-11-11 11:25                 ` Phillip Lord
  2017-11-12  0:30                   ` Fabrice Popineau
  0 siblings, 1 reply; 75+ messages in thread
From: Phillip Lord @ 2017-11-11 11:25 UTC (permalink / raw)
  To: Fabrice Popineau
  Cc: Jostein Kjønigsen, Eli Zaretskii, Jostein Kjønigsen,
	Emacs developers

Fabrice Popineau <fabrice.popineau@gmail.com> writes:
>> I'm also investigating making Emacs a portable app (as in
>> PortableApps.com), assuming everyone is happy with this. This might be
>> the better route for single user (and portable) installs.
>>
>>
> But Emacs is already portable. What do I miss here ?

On windows, curiously, but not linux.

You miss the cute installer and downloader. PortableApps is a nice way
to manage portable programmes on what ever device you use. I use it to
maintain a little environment on a shared drive, but have to do Emacs
separately.

Phil



^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: windows installer
  2017-11-11  7:33               ` Eli Zaretskii
@ 2017-11-11 11:34                 ` Phillip Lord
  2017-11-11 14:57                 ` Stefan Monnier
  2017-11-12 11:21                 ` Jostein Kjønigsen
  2 siblings, 0 replies; 75+ messages in thread
From: Phillip Lord @ 2017-11-11 11:34 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: Stefan Monnier, emacs-devel

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Stefan Monnier <monnier@iro.umontreal.ca>
>> Date: Fri, 10 Nov 2017 15:46:09 -0500
>> 
>> > They _will_ want to add it to PATH if they want to install packages
>> > from the likes of ELPA, which frequently come with Makefiles that
>> > invoke Emacs to compile the Lisp files.
>> 
>> For lack of familiarity with the Windows world, I don't know if typical
>> Windows users will want to add it to PATH (as a GNU/Linux user, of
>> course I'd do that), but I think the "frequently" above is incorrect.
>> 
>> The way Elisp files are compiled by package.el is to do it in the
>> running Emacs rather than by executing a separate Emacs session, AFAIK.
>> 
>> And even if you configure it to use something like async.el, doesn't
>> (expand-file-name invocation-name invocation-directory) let async.el find
>> an Emacs executable even when it's not in PATH?
>
> Maybe I'm missing something.  29 packages (out of 166) in ELPA have a
> Makefile.  Taking just one random Makefile, company/Makefile, I see
> this:
>
>   EMACS=emacs
>   [...]
>
>   compile:
> 	  ${EMACS} -Q --batch -L . -f batch-byte-compile company.el company-*.el
>
> If this Makefile is invoked with "make compile", it clearly expects
> Emacs to be found along PATH.  And even if Make is invoked from Emacs,
> the directory where the Emacs binary was found is not added to PATH.
> So how can this work without Emacs's binary being on PATH?  And what
> am I missing here?

This is just not a function of ELPA, it's a function of the ELPA source.

Phil



^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: windows installer
  2017-11-11 11:24                 ` Phillip Lord
@ 2017-11-11 12:01                   ` Eli Zaretskii
  0 siblings, 0 replies; 75+ messages in thread
From: Eli Zaretskii @ 2017-11-11 12:01 UTC (permalink / raw)
  To: Phillip Lord; +Cc: jostein, jostein, emacs-devel

> From: phillip.lord@russet.org.uk (Phillip Lord)
> Date: Sat, 11 Nov 2017 11:24:09 +0000
> Cc: jostein@kjonigsen.net, jostein@secure.kjonigsen.net, emacs-devel@gnu.org
> 
> > IOW, Emacs is not just a GUI application used interactively, it is
> > also a program that supports batch-mode invocation, and that mode is
> > at times used by other programs.  Keeping the Emacs binary off the
> > users' system PATH is therefore less than ideal, because the users
> > will then bump into subtle problems whereby Emacs seems "unavailable".
> 
> I suspect that these sort of users will install with the zip file or
> equivalent.

If that's our solution, then this should be prominently mentioned in
the README file.  (As one of "these sort of users", I use installers
in many cases, and would not expect myself to be considered "special".
But since you are doing the work, it's your call.  I obviously have no
problems with unzipping a zip archive as the method of installing a
package.)

Anyway, in general, I see no reason why we couldn't cater to both
groups, since updating PATH is not hard, and many/most installers
offer that, at least as an option.



^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: windows installer
  2017-11-11  7:33               ` Eli Zaretskii
  2017-11-11 11:34                 ` Phillip Lord
@ 2017-11-11 14:57                 ` Stefan Monnier
  2017-11-12 11:21                 ` Jostein Kjønigsen
  2 siblings, 0 replies; 75+ messages in thread
From: Stefan Monnier @ 2017-11-11 14:57 UTC (permalink / raw)
  To: emacs-devel

> Maybe I'm missing something.  29 packages (out of 166) in ELPA have a
> Makefile.

Those Makefiles are not used by ELPA.
Typically they're either used only by the maintainer, or they're there
for when the package is distributed via some other means than ELPA.


        Stefan




^ permalink raw reply	[flat|nested] 75+ messages in thread

* RE: windows installer
  2017-11-11  7:40               ` Eli Zaretskii
  2017-11-11  9:42                 ` Yuri Khan
@ 2017-11-11 16:39                 ` Drew Adams
       [not found]                   ` <87a7zpbxza.fsf@russet.org.uk>
  1 sibling, 1 reply; 75+ messages in thread
From: Drew Adams @ 2017-11-11 16:39 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: jostein, phillip.lord, jostein, emacs-devel

> > I, for one, am not interested in "installing" any Emacs build
> > (Program Files etc.).  I use multiple builds from different
> > releases.  I don't even want anything added, by default, to
> > PATH.
> 
> Then you should be fine with just unzipping a zip file, because by
> default the Windows explorer does that into a separate directory.

Yes, I am fine with the delivered binaries.  I thought that
was clear, but thanks for making it explicit.

Such binaries used to be delivered more often.  If there
were a simple "push-button" command to create them locally,
which didn't require anything else, I might well take
advantage of that too.

> But this installer is not for people like you or me who know what they
> are doing and have special needs and requirements.

OK.  (But I do not know what I am doing wrt building Emacs
on Windows - I don't do that.)

My only "special needs and requirements" is the
ability to put the equivalent of what the delivered
Windows zip for a binary provides in any folder.

> It is primarily for the naïve (a.k.a. "newbie") who just want to be
> able to invoke the installer and get Emacs installed "correctly",
> meaning that Emacs is available to any other program running on the
> system.  And that means being installed where other programs are
> installed (which gives them additional protection by system-wide
> processes and features), and being on PATH.

That's fine.  But is it not the case that this "installer"
also _builds_ Emacs for Windows?  If not then apologies
for misunderstanding.  But if yes, couldn't that part
of what it provides be easily decoupled from the rest
of the "installing"?

If so, wouldn't that be a good thing?  Folks who don't
want to hassle with obtaining and installing whatever
tooling is necessary to build Emacs could build it
easily and so might follow Emacs development more
closely, potentially providing more timely feedback.

Just a thought.  As it is now, I wait until there is
a pretest or release before seeing what has changed
and reporting problems or offering suggestions.

I'm not saying that Emacs needs to do this.  I'm
asking whether (1) the build part is already being
done, as part of this "Windows intaller" and (2) if
so, whether it wouldn't make sense to offer the
build-only (not "install") part as an option.  IOW,
be able to produce the equivalent of the Windows
binaries that are uploaded for, say, a pretest.



^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: windows installer
  2017-11-11 11:25                 ` Phillip Lord
@ 2017-11-12  0:30                   ` Fabrice Popineau
  2017-11-12  4:30                     ` Eli Zaretskii
       [not found]                     ` <87fu9hbytq.fsf@russet.org.uk>
  0 siblings, 2 replies; 75+ messages in thread
From: Fabrice Popineau @ 2017-11-12  0:30 UTC (permalink / raw)
  To: Phillip Lord
  Cc: Jostein Kjønigsen, Eli Zaretskii, Jostein Kjønigsen,
	Emacs developers

[-- Attachment #1: Type: text/plain, Size: 1050 bytes --]

2017-11-11 12:25 GMT+01:00 Phillip Lord <phillip.lord@russet.org.uk>:

> Fabrice Popineau <fabrice.popineau@gmail.com> writes:
> >> I'm also investigating making Emacs a portable app (as in
> >> PortableApps.com), assuming everyone is happy with this. This might be
> >> the better route for single user (and portable) installs.
> >>
> >>
> > But Emacs is already portable. What do I miss here ?
>
> On windows, curiously, but not linux.
>
> You miss the cute installer and downloader. PortableApps is a nice way
> to manage portable programmes on what ever device you use. I use it to
> maintain a little environment on a shared drive, but have to do Emacs
> separately.
>
>
Hmm ... besides copying the whole Emacs directory on an usb stick, what
else do I
need to do in order to use emacs from this  stick on another computer ?

And BTW, for Emacs to be a good Windows citizen, the .emacs.d directory
should probably not be located
in %HOMEPATH%\%HOMEDIR% but more likely in %APPDATA%\Emacs . I am not sure
it is a good path (!) to take.

 Fabrice

[-- Attachment #2: Type: text/html, Size: 1619 bytes --]

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: windows installer
  2017-11-12  0:30                   ` Fabrice Popineau
@ 2017-11-12  4:30                     ` Eli Zaretskii
       [not found]                     ` <87fu9hbytq.fsf@russet.org.uk>
  1 sibling, 0 replies; 75+ messages in thread
From: Eli Zaretskii @ 2017-11-12  4:30 UTC (permalink / raw)
  To: Fabrice Popineau; +Cc: jostein, emacs-devel, jostein, phillip.lord

> From: Fabrice Popineau <fabrice.popineau@gmail.com>
> Date: Sun, 12 Nov 2017 01:30:22 +0100
> Cc: Eli Zaretskii <eliz@gnu.org>, Jostein Kjønigsen <jostein@kjonigsen.net>, 
> 	Jostein Kjønigsen <jostein@secure.kjonigsen.net>, 
> 	Emacs developers <emacs-devel@gnu.org>
> 
> Hmm ... besides copying the whole Emacs directory on an usb stick, what else do I 
> need to do in order to use emacs from this  stick on another computer ?

You need to set up the directories where Emacs searches for its files,
like libexec and share/emacs/VERSION.  A USB drive could get a
different mount point (a.k.a. "drive letter") on each machine, which
gets in the way.

> And BTW, for Emacs to be a good Windows citizen, the .emacs.d directory should probably not be located 
> in %HOMEPATH%\%HOMEDIR% but more likely in %APPDATA%\Emacs . I am not sure
> it is a good path (!) to take.

We use %APPDATA%, and I think it's too late to change that, even if
using a subdirectory would be slightly better.

(The discussion was where to install Emacs itself, not where to create
the user init directory -- the installer doesn't change that.)



^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: windows installer
@ 2017-11-12  8:56 Angelo Graziosi
  2017-11-12  9:03 ` Fabrice Popineau
  2017-11-12 11:28 ` Eli Zaretskii
  0 siblings, 2 replies; 75+ messages in thread
From: Angelo Graziosi @ 2017-11-12  8:56 UTC (permalink / raw)
  To: emacs-devel

Fabrice Popineau wrote:
>
> Hmm ... besides copying the whole Emacs directory on an usb stick, what else do I 
> need to do in order to use emacs from this  stick on another computer ?

..an app to be really portable cannot write the host machine, so .emacs.d should go on the device where the portable app is installed. Obviously it cannot write the registry, what PortableApps do...

maybe starting Emacs with this bat is sufficient:

cat E:/Emacs_portable/bin/runemacs_portable.bat
set HOME=%~dp0..\HOME
"%~dp0runemacs.exe" %*


Angelo



^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: windows installer
  2017-11-12  8:56 Angelo Graziosi
@ 2017-11-12  9:03 ` Fabrice Popineau
  2017-11-12 11:30   ` Eli Zaretskii
  2017-11-12 14:14   ` Angelo Graziosi
  2017-11-12 11:28 ` Eli Zaretskii
  1 sibling, 2 replies; 75+ messages in thread
From: Fabrice Popineau @ 2017-11-12  9:03 UTC (permalink / raw)
  To: Angelo Graziosi; +Cc: Emacs developers

[-- Attachment #1: Type: text/plain, Size: 855 bytes --]

2017-11-12 9:56 GMT+01:00 Angelo Graziosi <angelo.g0@libero.it>:

> Fabrice Popineau wrote:
> >
> > Hmm ... besides copying the whole Emacs directory on an usb stick, what
> else do I
> > need to do in order to use emacs from this  stick on another computer ?
>
> ..an app to be really portable cannot write the host machine, so .emacs.d
> should go on the device where the portable app is installed.


And the more Windows compliant the app will be, the less portable it will
become.


> Obviously it cannot write the registry, what PortableApps do...
>

When does Emacs write the registry ?


>
> maybe starting Emacs with this bat is sufficient:
>
> cat E:/Emacs_portable/bin/runemacs_portable.bat
> set HOME=%~dp0..\HOME
> "%~dp0runemacs.exe" %*
>
> Setting HOME is all that is needed.
I even change PATH and all my environment from init.el.

Fabrice

[-- Attachment #2: Type: text/html, Size: 1648 bytes --]

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: windows installer
  2017-11-11  7:33               ` Eli Zaretskii
  2017-11-11 11:34                 ` Phillip Lord
  2017-11-11 14:57                 ` Stefan Monnier
@ 2017-11-12 11:21                 ` Jostein Kjønigsen
  2 siblings, 0 replies; 75+ messages in thread
From: Jostein Kjønigsen @ 2017-11-12 11:21 UTC (permalink / raw)
  To: emacs-devel, Eli Zaretskii

[-- Attachment #1: Type: text/plain, Size: 1750 bytes --]

On Sat, Nov 11, 2017, at 08:33 AM, Eli Zaretskii wrote:
>> From: Stefan Monnier <monnier@iro.umontreal.ca>
>> Date: Fri, 10 Nov 2017 15:46:09 -0500
>> 
>> For lack of familiarity with the Windows world, I don't know if
>> typical>> Windows users will want to add it to PATH (as a GNU/Linux user, of
>> course I'd do that), but I think the "frequently" above is incorrect.> Maybe I'm missing something.  29 packages (out of 166) in ELPA have a> Makefile.  Taking just one random Makefile, company/Makefile, I see
> this:
> 
>   EMACS=emacs
>   [...]
> 
>   compile:
>   ${EMACS} -Q --batch -L . -f batch-byte-compile company.el company-
>   *.el> 
> If this Makefile is invoked with "make compile", it clearly expects
> Emacs to be found along PATH.  And even if Make is invoked from Emacs,> the directory where the Emacs binary was found is not added to PATH.
> So how can this work without Emacs's binary being on PATH?  And what
> am I missing here?
> 

Not meaning to come off as any final authority here, but speaking as
someone deeply familiar with the Windows-platform (decades user-
experience, 10+ MS developer certifications, lalala)... With the clause
that I'm not som much a C/C++ kind of guy...
The most obvious problem these packages will encounter is that make (GNU
make, or any other variant) is typically not installed on regular end-
user Windows machines. It's not part of the regular Windows developer
toolchain, which typically relies on MSBuild instead.
Expecting "make" to be available is something I would consider a portability-
problem *with the package*, and I honestly don't think this is the Emacs-
installer's job to put in place.
--
Regards
Jostein Kjønigsen
jostein@kjonigsen.net


[-- Attachment #2: Type: text/html, Size: 2504 bytes --]

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: windows installer
  2017-11-12  8:56 Angelo Graziosi
  2017-11-12  9:03 ` Fabrice Popineau
@ 2017-11-12 11:28 ` Eli Zaretskii
  2017-11-12 14:27   ` Angelo Graziosi
  1 sibling, 1 reply; 75+ messages in thread
From: Eli Zaretskii @ 2017-11-12 11:28 UTC (permalink / raw)
  To: Angelo Graziosi; +Cc: emacs-devel

> Date: Sun, 12 Nov 2017 09:56:27 +0100 (CET)
> From: Angelo Graziosi <angelo.g0@libero.it>
> 
> cat E:/Emacs_portable/bin/runemacs_portable.bat
> set HOME=%~dp0..\HOME
> "%~dp0runemacs.exe" %*

That will do The Wrong Thing if the machine already has a home
directory for the user.

I think a better solution is to set emacs_dir.  See its documentation
in the user manual.



^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: windows installer
  2017-11-12  9:03 ` Fabrice Popineau
@ 2017-11-12 11:30   ` Eli Zaretskii
  2017-11-12 12:39     ` Fabrice Popineau
  2017-11-12 14:14   ` Angelo Graziosi
  1 sibling, 1 reply; 75+ messages in thread
From: Eli Zaretskii @ 2017-11-12 11:30 UTC (permalink / raw)
  To: Fabrice Popineau; +Cc: angelo.g0, emacs-devel

> From: Fabrice Popineau <fabrice.popineau@centralesupelec.fr>
> Date: Sun, 12 Nov 2017 10:03:45 +0100
> Cc: Emacs developers <emacs-devel@gnu.org>
> 
>  ..an app to be really portable cannot write the host machine, so .emacs.d should go on the device where
>  the portable app is installed. 
> 
> And the more Windows compliant the app will be, the less portable it will become.

I think you are talking about a different sense of "portable" than the
one used in this thread.  "Portable" here means it can be carried on
an external storage device, and will work when connected to a random
machine.



^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: windows installer
  2017-11-12 11:30   ` Eli Zaretskii
@ 2017-11-12 12:39     ` Fabrice Popineau
       [not found]       ` <8760adbxw6.fsf@russet.org.uk>
  0 siblings, 1 reply; 75+ messages in thread
From: Fabrice Popineau @ 2017-11-12 12:39 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: Angelo Graziosi, Emacs developers

[-- Attachment #1: Type: text/plain, Size: 999 bytes --]

2017-11-12 12:30 GMT+01:00 Eli Zaretskii <eliz@gnu.org>:

> > From: Fabrice Popineau <fabrice.popineau@centralesupelec.fr>
> > Date: Sun, 12 Nov 2017 10:03:45 +0100
> > Cc: Emacs developers <emacs-devel@gnu.org>
> >
> >  ..an app to be really portable cannot write the host machine, so
> .emacs.d should go on the device where
> >  the portable app is installed.
> >
> > And the more Windows compliant the app will be, the less portable it
> will become.
>
> I think you are talking about a different sense of "portable" than the
> one used in this thread.  "Portable" here means it can be carried on
> an external storage device, and will work when connected to a random
> machine.
>

No I use it with the same meaning as you do.
My point is that making Emacs compliant with the Windows apps guidelines
requires to store stuff is specific places, to register things into
registry, etc.
Whereas at the moment, none of this is required, hence you can move your
Emacs directory at will.


-- 
Fabrice

[-- Attachment #2: Type: text/html, Size: 1741 bytes --]

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: windows installer
  2017-11-12  9:03 ` Fabrice Popineau
  2017-11-12 11:30   ` Eli Zaretskii
@ 2017-11-12 14:14   ` Angelo Graziosi
  1 sibling, 0 replies; 75+ messages in thread
From: Angelo Graziosi @ 2017-11-12 14:14 UTC (permalink / raw)
  To: Fabrice Popineau; +Cc: Emacs developers


> Il 12 novembre 2017 alle 10.03 Fabrice Popineau <fabrice.popineau@centralesupelec.fr> ha scritto:
> 
> When does Emacs write the registry ?

Using addpm [*]?

In any case, for apps that do, PortableApps has a mechanism that does not write the machine registry but saves the "registry" in .reg files on portable device. Fortunately, this does not seem to regard heavily Emacs..

---
[*] https://www.gnu.org/software/emacs/manual/html_mono/emacs.html#MS_002dWindows-Registry



^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: windows installer
  2017-11-12 11:28 ` Eli Zaretskii
@ 2017-11-12 14:27   ` Angelo Graziosi
  2017-11-12 15:04     ` Eli Zaretskii
  0 siblings, 1 reply; 75+ messages in thread
From: Angelo Graziosi @ 2017-11-12 14:27 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: emacs-devel


> Il 12 novembre 2017 alle 12.28 Eli Zaretskii ha scritto:
> 
> 
> > Date: Sun, 12 Nov 2017 09:56:27 +0100 (CET)
> > From: Angelo Graziosi 
> > 
> > cat E:/Emacs_portable/bin/runemacs_portable.bat
> > set HOME=%~dp0..\HOME
> > "%~dp0runemacs.exe" %*
> 
> That will do The Wrong Thing if the machine already has a home
> directory for the user.

Hmm.. it redefines HOME only for Emacs so that .emacs.d, .gnupg etc. go there and not in %APPDATA%

> 
> I think a better solution is to set emacs_dir.  See its documentation
> in the user manual.

I have seen it (https://www.gnu.org/software/emacs/manual/html_mono/emacs.html#Misc-Variables) but I didn't understand much. Really defining

emacs_dir=%~dp0..\

in the .bat make .emacs.d go on the portable device?

May you give a concrete example? Thanks.

 Angelo



^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: windows installer
  2017-11-12 14:27   ` Angelo Graziosi
@ 2017-11-12 15:04     ` Eli Zaretskii
  2017-11-12 17:32       ` Angelo Graziosi
  0 siblings, 1 reply; 75+ messages in thread
From: Eli Zaretskii @ 2017-11-12 15:04 UTC (permalink / raw)
  To: Angelo Graziosi; +Cc: emacs-devel

> Date: Sun, 12 Nov 2017 15:27:45 +0100 (CET)
> From: Angelo Graziosi <angelo.g0@libero.it>
> Cc: emacs-devel@gnu.org
> 
> 
> > > cat E:/Emacs_portable/bin/runemacs_portable.bat
> > > set HOME=%~dp0..\HOME
> > > "%~dp0runemacs.exe" %*
> > 
> > That will do The Wrong Thing if the machine already has a home
> > directory for the user.
> 
> Hmm.. it redefines HOME only for Emacs so that .emacs.d, .gnupg etc. go there and not in %APPDATA%

No, you redefine HOME for every application that Emacs will invoke as
well.

> > I think a better solution is to set emacs_dir.  See its documentation
> > in the user manual.
> 
> I have seen it (https://www.gnu.org/software/emacs/manual/html_mono/emacs.html#Misc-Variables) but I didn't understand much. Really defining
> 
> emacs_dir=%~dp0..\
> 
> in the .bat make .emacs.d go on the portable device?

I don't think you need to do that, as Emacs does that automatically.
In any case, this is separate from the HOME issue.  If Emacs already
finds all of its files on the USB, then emacs_dir setting is not
needed.  Unless you have INFOPATH set on that machine, or one of the
other environment variables, like EMACSLOADPATH, that override
emacs_dir.

As for HOME, I think you should set it only if it is not already set,
and you should use setlocal, not set.



^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: windows installer
  2017-11-12 15:04     ` Eli Zaretskii
@ 2017-11-12 17:32       ` Angelo Graziosi
  2017-11-12 18:42         ` Eli Zaretskii
  0 siblings, 1 reply; 75+ messages in thread
From: Angelo Graziosi @ 2017-11-12 17:32 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: emacs-devel


> Il 12 novembre 2017 alle 16.04 Eli Zaretskii <eliz@gnu.org> ha scritto:
> 
> No, you redefine HOME for every application that Emacs will invoke as
> well.
>
> I don't think you need to do that, as Emacs does that automatically.
> In any case, this is separate from the HOME issue.  If Emacs already
> finds all of its files on the USB, then emacs_dir setting is not
> needed.  Unless you have INFOPATH set on that machine, or one of the
> other environment variables, like EMACSLOADPATH, that override
> emacs_dir.
> 
> As for HOME, I think you should set it only if it is not already set,
> and you should use setlocal, not set.

Hmm.. thanks for clarification.. Meanwhile I found this discussion:

  https://stackoverflow.com/questions/350345/how-can-i-have-a-portable-emacs

and this answer seems interesting:

  create a directory in the root of your usb drive called 'home'.
  create site-start.el in the site-lisp folder and then copy this and you are all set to go.

  (defvar %~dp0 (substring data-directory 0 3)) (defvar usb-home-dir (concat %~dp0 "home/"))
  (setenv "HOME" usb-home-dir)

What do you think? It looks better (maybe not the last!) of the other using a .bat file..



^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: windows installer
  2017-11-12 17:32       ` Angelo Graziosi
@ 2017-11-12 18:42         ` Eli Zaretskii
  0 siblings, 0 replies; 75+ messages in thread
From: Eli Zaretskii @ 2017-11-12 18:42 UTC (permalink / raw)
  To: Angelo Graziosi; +Cc: emacs-devel

> Date: Sun, 12 Nov 2017 18:32:34 +0100 (CET)
> From: Angelo Graziosi <angelo.g0@libero.it>
> Cc: emacs-devel@gnu.org
> 
>   https://stackoverflow.com/questions/350345/how-can-i-have-a-portable-emacs
> 
> and this answer seems interesting:
> 
>   create a directory in the root of your usb drive called 'home'.
>   create site-start.el in the site-lisp folder and then copy this and you are all set to go.
> 
>   (defvar %~dp0 (substring data-directory 0 3)) (defvar usb-home-dir (concat %~dp0 "home/"))
>   (setenv "HOME" usb-home-dir)
> 
> What do you think? It looks better (maybe not the last!) of the other using a .bat file..

If you want the programs run by Emacs to inherit this value of HOME,
then yes, it looks good.



^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: windows installer
       [not found]                     ` <87fu9hbytq.fsf@russet.org.uk>
@ 2017-11-13 22:25                       ` Phillip Lord
  2017-11-14 13:08                         ` Fabrice Popineau
  0 siblings, 1 reply; 75+ messages in thread
From: Phillip Lord @ 2017-11-13 22:25 UTC (permalink / raw)
  To: Fabrice Popineau
  Cc: Jostein Kjønigsen, Eli Zaretskii, Jostein Kjønigsen,
	Emacs developers

Fabrice Popineau <fabrice.popineau@gmail.com> writes:

> 2017-11-11 12:25 GMT+01:00 Phillip Lord <phillip.lord@russet.org.uk>:
>
>> Fabrice Popineau <fabrice.popineau@gmail.com> writes:
>> >> I'm also investigating making Emacs a portable app (as in
>> >> PortableApps.com), assuming everyone is happy with this. This might be
>> >> the better route for single user (and portable) installs.
>> >>
>> >>
>> > But Emacs is already portable. What do I miss here ?
>>
>> On windows, curiously, but not linux.
>>
>> You miss the cute installer and downloader. PortableApps is a nice way
>> to manage portable programmes on what ever device you use. I use it to
>> maintain a little environment on a shared drive, but have to do Emacs
>> separately.
>>
>>
> Hmm ... besides copying the whole Emacs directory on an usb stick,
> what else do I need to do in order to use emacs from this stick on
> another computer ?

Well, a cute installer and downloader. And updater and
launcher. PortableApps is just nice and easy.

Anyway this is for the future. Installer first.

Phil



^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: windows installer
       [not found]                   ` <87a7zpbxza.fsf@russet.org.uk>
@ 2017-11-13 22:44                     ` Phillip Lord
  2017-11-14 14:54                       ` Drew Adams
  0 siblings, 1 reply; 75+ messages in thread
From: Phillip Lord @ 2017-11-13 22:44 UTC (permalink / raw)
  To: Drew Adams; +Cc: jostein, Eli Zaretskii, jostein, emacs-devel



Drew Adams <drew.adams@oracle.com> writes:
> Such binaries used to be delivered more often.  If there
> were a simple "push-button" command to create them locally,
> which didn't require anything else, I might well take
> advantage of that too.

It's not going to get any simpler than "./configure;make install"
complete with all the environment that this entails.


>>> But this installer is not for people like you or me who know what they
>> are doing and have special needs and requirements.
>
> OK.  (But I do not know what I am doing wrt building Emacs
> on Windows - I don't do that.)
>
> My only "special needs and requirements" is the
> ability to put the equivalent of what the delivered
> Windows zip for a binary provides in any folder.
>
>> It is primarily for the naïve (a.k.a. "newbie") who just want to be
>> able to invoke the installer and get Emacs installed "correctly",
>> meaning that Emacs is available to any other program running on the
>> system.  And that means being installed where other programs are
>> installed (which gives them additional protection by system-wide
>> processes and features), and being on PATH.
>
> That's fine.  But is it not the case that this "installer"
> also _builds_ Emacs for Windows?  If not then apologies
> for misunderstanding.

No. The builder builds the installer. It's a self-extracting zip file on
steroids.


> If so, wouldn't that be a good thing?  Folks who don't
> want to hassle with obtaining and installing whatever
> tooling is necessary to build Emacs could build it
> easily and so might follow Emacs development more
> closely, potentially providing more timely feedback.
>
> Just a thought.  As it is now, I wait until there is
> a pretest or release before seeing what has changed
> and reporting problems or offering suggestions.

I think we are good here. I put support for snapshot building in, and
I've automated as much of the stuff around that as I can. So, I should
be able to do it more frequently; probably monthly, as I haven't managed
to automate things from start to finish.

So, not quite what you want in that you will need to install msys to do
the build, but at least it will be easier for someone else to do it for
you, if you don't wish to do this.

Phil



^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: windows installer
       [not found]       ` <8760adbxw6.fsf@russet.org.uk>
@ 2017-11-13 22:46         ` Phillip Lord
  2017-11-14 14:36           ` Angelo Graziosi
  0 siblings, 1 reply; 75+ messages in thread
From: Phillip Lord @ 2017-11-13 22:46 UTC (permalink / raw)
  To: Fabrice Popineau; +Cc: Eli Zaretskii, Angelo Graziosi, Emacs developers

Fabrice Popineau <fabrice.popineau@gmail.com> writes:

> 2017-11-12 12:30 GMT+01:00 Eli Zaretskii <eliz@gnu.org>:
>> I think you are talking about a different sense of "portable" than the
>> one used in this thread.  "Portable" here means it can be carried on
>> an external storage device, and will work when connected to a random
>> machine.
>>
>
> No I use it with the same meaning as you do.
> My point is that making Emacs compliant with the Windows apps guidelines
> requires to store stuff is specific places, to register things into
> registry, etc.
> Whereas at the moment, none of this is required, hence you can move your
> Emacs directory at will.

This is why I would like to provide two easy installs. The windows
installer that's already there (if imperfectly so) and a PortableApps
version, that will be, well, portable.

Phil



^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: windows installer
  2017-11-13 22:25                       ` Phillip Lord
@ 2017-11-14 13:08                         ` Fabrice Popineau
  2017-11-16 16:15                           ` Phillip Lord
  0 siblings, 1 reply; 75+ messages in thread
From: Fabrice Popineau @ 2017-11-14 13:08 UTC (permalink / raw)
  To: Phillip Lord
  Cc: Jostein Kjønigsen, Eli Zaretskii, Jostein Kjønigsen,
	Emacs developers

[-- Attachment #1: Type: text/plain, Size: 600 bytes --]

2017-11-13 23:25 GMT+01:00 Phillip Lord <phillip.lord@russet.org.uk>:

> Fabrice Popineau <fabrice.popineau@gmail.com> writes:
>
> > Hmm ... besides copying the whole Emacs directory on an usb stick,
> > what else do I need to do in order to use emacs from this stick on
> > another computer ?
>
> Well, a cute installer and downloader. And updater and
> launcher. PortableApps is just nice and easy.
>
>
What for ? Sincerely, I don't see what it brings. The best portable program
is the one
you can install with unzip. And it is already the case for Emacs.
But if people want bells and whistles ...

[-- Attachment #2: Type: text/html, Size: 1067 bytes --]

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: windows installer
  2017-11-13 22:46         ` Phillip Lord
@ 2017-11-14 14:36           ` Angelo Graziosi
  2017-11-14 16:31             ` Fabrice Popineau
  0 siblings, 1 reply; 75+ messages in thread
From: Angelo Graziosi @ 2017-11-14 14:36 UTC (permalink / raw)
  To: Phillip Lord, Fabrice Popineau; +Cc: Eli Zaretskii, Emacs developers


> Fabrice Popineau ha scritto:
> 
> 
> The best portable program is the one you can install with unzip. And it is already the case for Emacs.
> 

No. After you have unzipped and started Emacs, where do you think it will write the .emacs.d folder?

You are using "portable" with a meaning a bit different from the one which is discussed here... It should not write the host machine.

  Angelo



^ permalink raw reply	[flat|nested] 75+ messages in thread

* RE: windows installer
  2017-11-13 22:44                     ` Phillip Lord
@ 2017-11-14 14:54                       ` Drew Adams
  2017-11-16 16:15                         ` Phillip Lord
  0 siblings, 1 reply; 75+ messages in thread
From: Drew Adams @ 2017-11-14 14:54 UTC (permalink / raw)
  To: phillip.lord; +Cc: jostein, Eli Zaretskii, jostein, emacs-devel

> > Such binaries used to be delivered more often.  If there
> > were a simple "push-button" command to create them locally,
> > which didn't require anything else, I might well take
> > advantage of that too.
> 
> It's not going to get any simpler than "./configure;make install"
> complete with all the environment that this entails.

Does that work on out-of-the-box MS Windows?  I doubt it.

Emacs users on Windows are not necessarily developers
of/on Windows.  A "builder" that contained everything
it needed, and kept it contained, tossing afterward
whatever is not needed to run the built Emacs, would
be what I'm talking about.

Other binaries (e.g. Msys stuff) are less the problem
that a C compiler, `make', etc.  Push-button building
without depending on a separate development environment.
I.e., the builder would bring its own build tools, and
clean them out when done building.

> > But is it not the case that this "installer"
> > also _builds_ Emacs for Windows?  If not then apologies
> > for misunderstanding.
> 
> No. The builder builds the installer. It's a self-extracting
> zip file on steroids.

IIUC, none of those steroids help me, IIUC.  I don't care
to "install" this or that Emacs build.  I just want to get
builds or be able to push-button-create them.  I don't want
something messing with my Windows registry, menus, HOME,
PATH, or anything else.  Get the build job done without
depending on anything else pre-existing, and leave no
footprints behind.

(I understand now that that is not what you are trying to
do here.  I'm just trying to make clear what I was looking
for.)
 
> > If so, wouldn't that be a good thing?  Folks who don't
> > want to hassle with obtaining and installing whatever
> > tooling is necessary to build Emacs could build it
> > easily and so might follow Emacs development more
> > closely, potentially providing more timely feedback.
> >
> > Just a thought.  As it is now, I wait until there is
> > a pretest or release before seeing what has changed
> > and reporting problems or offering suggestions.
> 
> I think we are good here. I put support for snapshot building in, and
> I've automated as much of the stuff around that as I can. So, I should
> be able to do it more frequently; probably monthly, as I haven't managed
> to automate things from start to finish.

Great.  It will be good to return to periodically uploaded builds.  
 
> So, not quite what you want in that you will need to install msys to do
> the build, but at least it will be easier for someone else to do it for
> you, if you don't wish to do this.

Thanks for working on this.



^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: windows installer
  2017-11-14 14:36           ` Angelo Graziosi
@ 2017-11-14 16:31             ` Fabrice Popineau
  2017-11-14 20:12               ` Angelo Graziosi
  0 siblings, 1 reply; 75+ messages in thread
From: Fabrice Popineau @ 2017-11-14 16:31 UTC (permalink / raw)
  To: Angelo Graziosi; +Cc: Eli Zaretskii, Emacs developers, Phillip Lord

[-- Attachment #1: Type: text/plain, Size: 861 bytes --]

2017-11-14 15:36 GMT+01:00 Angelo Graziosi <angelo.g0@libero.it>:

>
> > Fabrice Popineau ha scritto:
> >
> >
> > The best portable program is the one you can install with unzip. And it
> is already the case for Emacs.
> >
>
> No. After you have unzipped and started Emacs, where do you think it will
> write the .emacs.d folder?
>

And why do you care about .emacs.d that much ?
You can setup emacs using the site-lisp directory if you don't want to
write to your host in ~/.emacs.d.


> You are using "portable" with a meaning a bit different from the one which
> is discussed here... It should not write the host machine.
>
>
I don't think so.  I have already been there in the past and for longer you
seem to imagine.
My point is that you can configure everything from within emacs without
requiring an external installer
to fiddle with your host.

Fabrice

[-- Attachment #2: Type: text/html, Size: 1518 bytes --]

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: windows installer
  2017-11-14 16:31             ` Fabrice Popineau
@ 2017-11-14 20:12               ` Angelo Graziosi
  2017-11-20  8:46                 ` Jostein Kjønigsen
  0 siblings, 1 reply; 75+ messages in thread
From: Angelo Graziosi @ 2017-11-14 20:12 UTC (permalink / raw)
  To: Fabrice Popineau; +Cc: Eli Zaretskii, Phillip Lord, Emacs developers


> Il 14 novembre 2017 alle 17.31 Fabrice Popineau <fabrice.popineau@gmail.com> ha scritto:
> 
> 
> 2017-11-14 15:36 GMT+01:00 Angelo Graziosi <angelo.g0@libero.it>:
> 
> >
> > > Fabrice Popineau ha scritto:
> > >
> > >
> > > The best portable program is the one you can install with unzip. And it
> > is already the case for Emacs.
> > >
> >
> > No. After you have unzipped and started Emacs, where do you think it will
> > write the .emacs.d folder?
> >
> 
> And why do you care about .emacs.d that much ?
> You can setup emacs using the site-lisp directory if you don't want to
> write to your host in ~/.emacs.d.
> 
> 
> > You are using "portable" with a meaning a bit different from the one which
> > is discussed here... It should not write the host machine.
> >
> >
> I don't think so.  I have already been there in the past and for longer you
> seem to imagine.
> My point is that you can configure everything from within emacs without
> requiring an external installer
> to fiddle with your host.

..but not all [potential] users want to do that...



^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: windows installer
  2017-11-14 14:54                       ` Drew Adams
@ 2017-11-16 16:15                         ` Phillip Lord
  2017-11-16 16:23                           ` Eli Zaretskii
  0 siblings, 1 reply; 75+ messages in thread
From: Phillip Lord @ 2017-11-16 16:15 UTC (permalink / raw)
  To: Drew Adams; +Cc: jostein, Eli Zaretskii, jostein, emacs-devel

Drew Adams <drew.adams@oracle.com> writes:

>> > Such binaries used to be delivered more often.  If there
>> > were a simple "push-button" command to create them locally,
>> > which didn't require anything else, I might well take
>> > advantage of that too.
>> 
>> It's not going to get any simpler than "./configure;make install"
>> complete with all the environment that this entails.
>
> Does that work on out-of-the-box MS Windows?  I doubt it.
>
> Emacs users on Windows are not necessarily developers
> of/on Windows.  A "builder" that contained everything
> it needed, and kept it contained, tossing afterward
> whatever is not needed to run the built Emacs, would
> be what I'm talking about.

Yeah, that's not going to happen. Essentially, the build proceedure at
the moment is this:

Install msys
Run pacman to install dependencies
git clone emacs
./configure;make

The last step takes an hour.

Alternatively, installer a snapshot via an installer. I'm struggling to
see a substantial user community who would want something in between the
two.


> Other binaries (e.g. Msys stuff) are less the problem
> that a C compiler, `make', etc.  Push-button building
> without depending on a separate development environment.
> I.e., the builder would bring its own build tools, and
> clean them out when done building.
>
>> > But is it not the case that this "installer"
>> > also _builds_ Emacs for Windows?  If not then apologies
>> > for misunderstanding.
>> 
>> No. The builder builds the installer. It's a self-extracting
>> zip file on steroids.
>
> IIUC, none of those steroids help me, IIUC.  I don't care
> to "install" this or that Emacs build.  I just want to get
> builds or be able to push-button-create them.  I don't want
> something messing with my Windows registry, menus, HOME,
> PATH, or anything else.  Get the build job done without
> depending on anything else pre-existing, and leave no
> footprints behind.


The "leave no footprints" behind means "start-from-scratch". Currently,
building the Emacs zip (including extracting the dependencies) takes
about 3 hours and requires half a gig of downloads.


>> I think we are good here. I put support for snapshot building in, and
>> I've automated as much of the stuff around that as I can. So, I
>> should be able to do it more frequently; probably monthly, as I
>> haven't managed to automate things from start to finish.
>
> Great.  It will be good to return to periodically uploaded builds.  

Up sometime soon!

Phil



^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: windows installer
  2017-11-14 13:08                         ` Fabrice Popineau
@ 2017-11-16 16:15                           ` Phillip Lord
  0 siblings, 0 replies; 75+ messages in thread
From: Phillip Lord @ 2017-11-16 16:15 UTC (permalink / raw)
  To: Fabrice Popineau
  Cc: Jostein Kjønigsen, Eli Zaretskii, Jostein Kjønigsen,
	Emacs developers

Fabrice Popineau <fabrice.popineau@gmail.com> writes:

> 2017-11-13 23:25 GMT+01:00 Phillip Lord <phillip.lord@russet.org.uk>:
>
>> Fabrice Popineau <fabrice.popineau@gmail.com> writes:
>>
>> > Hmm ... besides copying the whole Emacs directory on an usb stick,
>> > what else do I need to do in order to use emacs from this stick on
>> > another computer ?
>>
>> Well, a cute installer and downloader. And updater and
>> launcher. PortableApps is just nice and easy.
>>
>>
> What for ? Sincerely, I don't see what it brings. The best portable
> program is the one you can install with unzip. And it is already the
> case for Emacs.  But if people want bells and whistles ...

Yes, they do.

Phil



^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: windows installer
  2017-11-16 16:15                         ` Phillip Lord
@ 2017-11-16 16:23                           ` Eli Zaretskii
  2017-11-16 16:31                             ` Fabrice Popineau
  0 siblings, 1 reply; 75+ messages in thread
From: Eli Zaretskii @ 2017-11-16 16:23 UTC (permalink / raw)
  To: Phillip Lord; +Cc: jostein, jostein, drew.adams, emacs-devel

> From: phillip.lord@russet.org.uk (Phillip Lord)
> Date: Thu, 16 Nov 2017 16:15:03 +0000
> Cc: jostein@secure.kjonigsen.net, Eli Zaretskii <eliz@gnu.org>,
> 	jostein@kjonigsen.net, emacs-devel@gnu.org
> 
> Install msys
> Run pacman to install dependencies
> git clone emacs
> ./configure;make
> 
> The last step takes an hour.

Try "make -j8" instead, and it will end much faster.



^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: windows installer
  2017-11-16 16:23                           ` Eli Zaretskii
@ 2017-11-16 16:31                             ` Fabrice Popineau
  2017-11-16 16:57                               ` Eli Zaretskii
  0 siblings, 1 reply; 75+ messages in thread
From: Fabrice Popineau @ 2017-11-16 16:31 UTC (permalink / raw)
  To: Eli Zaretskii
  Cc: Jostein Kjønigsen, Emacs developers, Jostein Kjønigsen,
	Drew Adams, Phillip Lord

[-- Attachment #1: Type: text/plain, Size: 728 bytes --]

2017-11-16 17:23 GMT+01:00 Eli Zaretskii <eliz@gnu.org>:

> > From: phillip.lord@russet.org.uk (Phillip Lord)
> > Date: Thu, 16 Nov 2017 16:15:03 +0000
> > Cc: jostein@secure.kjonigsen.net, Eli Zaretskii <eliz@gnu.org>,
> >       jostein@kjonigsen.net, emacs-devel@gnu.org
> >
> > Install msys
> > Run pacman to install dependencies
> > git clone emacs
> > ./configure;make
> >
> > The last step takes an hour.
>
> Try "make -j8" instead, and it will end much faster.
>

Well, the slow part is still configure, because of the numerous instances
of shell that are launched.
I also suggest to exclude your MSYS2/MinGW64 directories from being scanned
by any antivirus
or antimalware. It speeds up thing a little bit.

-- 
Fabrice

[-- Attachment #2: Type: text/html, Size: 1547 bytes --]

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: windows installer
  2017-11-16 16:31                             ` Fabrice Popineau
@ 2017-11-16 16:57                               ` Eli Zaretskii
  2017-11-16 17:35                                 ` Fabrice Popineau
  0 siblings, 1 reply; 75+ messages in thread
From: Eli Zaretskii @ 2017-11-16 16:57 UTC (permalink / raw)
  To: Fabrice Popineau; +Cc: jostein, emacs-devel, jostein, drew.adams, phillip.lord

> From: Fabrice Popineau <fabrice.popineau@centralesupelec.fr>
> Date: Thu, 16 Nov 2017 17:31:40 +0100
> Cc: Phillip Lord <phillip.lord@russet.org.uk>, 
> 	Jostein Kjønigsen <jostein@kjonigsen.net>, 
> 	Jostein Kjønigsen <jostein@secure.kjonigsen.net>, 
> 	Drew Adams <drew.adams@oracle.com>, Emacs developers <emacs-devel@gnu.org>
> 
>  > The last step takes an hour.
> 
>  Try "make -j8" instead, and it will end much faster.
> 
> Well, the slow part is still configure, because of the numerous instances of shell that are launched.

Not here, it isn't.  The slow part is byte compilation of the files
with bootstrap-emacs, until it is rebuilt with byte-compiled compiler.



^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: windows installer
  2017-11-16 16:57                               ` Eli Zaretskii
@ 2017-11-16 17:35                                 ` Fabrice Popineau
  2017-11-16 17:39                                   ` Eli Zaretskii
                                                     ` (2 more replies)
  0 siblings, 3 replies; 75+ messages in thread
From: Fabrice Popineau @ 2017-11-16 17:35 UTC (permalink / raw)
  To: Eli Zaretskii
  Cc: Jostein Kjønigsen, Emacs developers, Jostein Kjønigsen,
	Drew Adams, Phillip Lord

[-- Attachment #1: Type: text/plain, Size: 1013 bytes --]

2017-11-16 17:57 GMT+01:00 Eli Zaretskii <eliz@gnu.org>:

> > From: Fabrice Popineau <fabrice.popineau@centralesupelec.fr>
> > Date: Thu, 16 Nov 2017 17:31:40 +0100
> > Cc: Phillip Lord <phillip.lord@russet.org.uk>,
> >       Jostein Kjønigsen <jostein@kjonigsen.net>,
> >       Jostein Kjønigsen <jostein@secure.kjonigsen.net>,
> >       Drew Adams <drew.adams@oracle.com>, Emacs developers <
> emacs-devel@gnu.org>
> >
> >  > The last step takes an hour.
> >
> >  Try "make -j8" instead, and it will end much faster.
> >
> > Well, the slow part is still configure, because of the numerous
> instances of shell that are launched.
>
> Not here, it isn't.  The slow part is byte compilation of the files
> with bootstrap-emacs, until it is rebuilt with byte-compiled compiler.
>

Phillip said :

./configure ; make

Since when does it bootstrap emacs and recompile elc files ?

And on my machine, ./configure is about 10 times slower than compiling
emacs itself (the make -j8 part).

[-- Attachment #2: Type: text/html, Size: 1977 bytes --]

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: windows installer
  2017-11-16 17:35                                 ` Fabrice Popineau
@ 2017-11-16 17:39                                   ` Eli Zaretskii
  2017-11-16 18:10                                     ` Fabrice Popineau
  2017-11-16 17:42                                   ` Noam Postavsky
  2017-11-22 22:39                                   ` Phillip Lord
  2 siblings, 1 reply; 75+ messages in thread
From: Eli Zaretskii @ 2017-11-16 17:39 UTC (permalink / raw)
  To: Fabrice Popineau; +Cc: jostein, emacs-devel, jostein, drew.adams, phillip.lord

> From: Fabrice Popineau <fabrice.popineau@gmail.com>
> Date: Thu, 16 Nov 2017 18:35:19 +0100
> Cc: Phillip Lord <phillip.lord@russet.org.uk>, 
> 	Jostein Kjønigsen <jostein@kjonigsen.net>, 
> 	Jostein Kjønigsen <jostein@secure.kjonigsen.net>, 
> 	Drew Adams <drew.adams@oracle.com>, Emacs developers <emacs-devel@gnu.org>
> 
>  >  > The last step takes an hour.
>  >
>  >  Try "make -j8" instead, and it will end much faster.
>  >
>  > Well, the slow part is still configure, because of the numerous instances of shell that are launched.
> 
>  Not here, it isn't.  The slow part is byte compilation of the files
>  with bootstrap-emacs, until it is rebuilt with byte-compiled compiler.
> 
> Phillip said :
> 
> ./configure ; make
> 
> Since when does it bootstrap emacs and recompile elc files ?

No, he said

  git clone emacs
  ./configure; make

And that does bootstrap.

> And on my machine, ./configure is about 10 times slower than compiling emacs itself (the make -j8 part).

Does configure on your machine take anywhere near an hour?  I doubt
that.




^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: windows installer
  2017-11-16 17:35                                 ` Fabrice Popineau
  2017-11-16 17:39                                   ` Eli Zaretskii
@ 2017-11-16 17:42                                   ` Noam Postavsky
  2017-11-16 17:45                                     ` Fabrice Popineau
  2017-11-22 22:39                                   ` Phillip Lord
  2 siblings, 1 reply; 75+ messages in thread
From: Noam Postavsky @ 2017-11-16 17:42 UTC (permalink / raw)
  To: Fabrice Popineau
  Cc: Emacs developers, Jostein Kjønigsen, Eli Zaretskii,
	Jostein Kjønigsen, Drew Adams, Phillip Lord

On Thu, Nov 16, 2017 at 12:35 PM, Fabrice Popineau
<fabrice.popineau@gmail.com> wrote:

> Phillip said :
>
> ./configure ; make
>
> Since when does it bootstrap emacs and recompile elc files ?

When compiling from a fresh git checkout.

> And on my machine, ./configure is about 10 times slower than compiling emacs
> itself (the make -j8 part).

PS use the --cache-file option to configure to speed this up.



^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: windows installer
  2017-11-16 17:42                                   ` Noam Postavsky
@ 2017-11-16 17:45                                     ` Fabrice Popineau
  0 siblings, 0 replies; 75+ messages in thread
From: Fabrice Popineau @ 2017-11-16 17:45 UTC (permalink / raw)
  To: Noam Postavsky
  Cc: Emacs developers, Jostein Kjønigsen, Eli Zaretskii,
	Jostein Kjønigsen, Drew Adams, Phillip Lord

[-- Attachment #1: Type: text/plain, Size: 609 bytes --]

2017-11-16 18:42 GMT+01:00 Noam Postavsky <npostavs@users.sourceforge.net>:

> On Thu, Nov 16, 2017 at 12:35 PM, Fabrice Popineau
> <fabrice.popineau@gmail.com> wrote:
>
> > Phillip said :
> >
> > ./configure ; make
> >
> > Since when does it bootstrap emacs and recompile elc files ?
>
> When compiling from a fresh git checkout.
>

Ok. Did not do it for quite a time.


>
> > And on my machine, ./configure is about 10 times slower than compiling
> emacs
> > itself (the make -j8 part).
>
> PS use the --cache-file option to configure to speed this up.
>

Thanks. That's really the painful part on Windows.

[-- Attachment #2: Type: text/html, Size: 1302 bytes --]

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: windows installer
  2017-11-16 17:39                                   ` Eli Zaretskii
@ 2017-11-16 18:10                                     ` Fabrice Popineau
  2017-11-16 20:45                                       ` Richard Copley
  0 siblings, 1 reply; 75+ messages in thread
From: Fabrice Popineau @ 2017-11-16 18:10 UTC (permalink / raw)
  To: Eli Zaretskii
  Cc: Jostein Kjønigsen, Emacs developers, Jostein Kjønigsen,
	Drew Adams, Phillip Lord

[-- Attachment #1: Type: text/plain, Size: 1306 bytes --]

2017-11-16 18:39 GMT+01:00 Eli Zaretskii <eliz@gnu.org>:

> > From: Fabrice Popineau <fabrice.popineau@gmail.com>
> > Date: Thu, 16 Nov 2017 18:35:19 +0100
> > Cc: Phillip Lord <phillip.lord@russet.org.uk>,
> >       Jostein Kjønigsen <jostein@kjonigsen.net>,
> >       Jostein Kjønigsen <jostein@secure.kjonigsen.net>,
> >       Drew Adams <drew.adams@oracle.com>, Emacs developers <
> emacs-devel@gnu.org>
> >
> >  >  > The last step takes an hour.
> >  >
> >  >  Try "make -j8" instead, and it will end much faster.
> >  >
> >  > Well, the slow part is still configure, because of the numerous
> instances of shell that are launched.
> >
> >  Not here, it isn't.  The slow part is byte compilation of the files
> >  with bootstrap-emacs, until it is rebuilt with byte-compiled compiler.
> >
> > Phillip said :
> >
> > ./configure ; make
> >
> > Since when does it bootstrap emacs and recompile elc files ?
>
> No, he said
>
>   git clone emacs
>   ./configure; make
>
> And that does bootstrap.
>
> > And on my machine, ./configure is about 10 times slower than compiling
> emacs itself (the make -j8 part).
>
> Does configure on your machine take anywhere near an hour?  I doubt
> that.
>
>
'make -j8 bootstrap' takes 20mn.
The ./configure part takes 3-4mn.

[-- Attachment #2: Type: text/html, Size: 2213 bytes --]

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: windows installer
  2017-11-16 18:10                                     ` Fabrice Popineau
@ 2017-11-16 20:45                                       ` Richard Copley
  2017-11-17  7:14                                         ` Eli Zaretskii
  2017-11-17  7:25                                         ` Fabrice Popineau
  0 siblings, 2 replies; 75+ messages in thread
From: Richard Copley @ 2017-11-16 20:45 UTC (permalink / raw)
  To: Fabrice Popineau
  Cc: Emacs developers, Jostein Kjønigsen, Eli Zaretskii,
	Jostein Kjønigsen, Drew Adams, Phillip Lord

On 16 November 2017 at 18:10, Fabrice Popineau
<fabrice.popineau@gmail.com> wrote:
>
> 2017-11-16 18:39 GMT+01:00 Eli Zaretskii <eliz@gnu.org>:
>>
>> > From: Fabrice Popineau <fabrice.popineau@gmail.com>
>> > And on my machine, ./configure is about 10 times slower than compiling
>> > emacs itself (the make -j8 part).
>>
>> Does configure on your machine take anywhere near an hour?  I doubt
>> that.
>>
>
> 'make -j8 bootstrap' takes 20mn.
> The ./configure part takes 3-4mn.

That is "10 times faster", not "10 times slower".

More and faster CPU cores and RAM, and fast low-latency secondary
storage will help a bit. Just now, autogen / configure / make
took 8.4s / 41.7s / 3min 31.0s respectively in MSYS2 on Windows,
and about 2s / 16s / 2m 46s in an Ubuntu VM.

Experiment with larger values for -j (the builds above were at -j24
on an 8-thread machine) as there's plenty of stuff to be going on with
that doesn't need a CPU core.

Windows is ridiculously slow to start a new process. That seems to
account for a big proportion of the time it takes to run the configure
script. Disable the App Compat engine (from orbit, it's the only
way to be sure).



^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: windows installer
  2017-11-16 20:45                                       ` Richard Copley
@ 2017-11-17  7:14                                         ` Eli Zaretskii
  2017-11-17  7:22                                           ` Fabrice Popineau
  2017-11-17  7:25                                         ` Fabrice Popineau
  1 sibling, 1 reply; 75+ messages in thread
From: Eli Zaretskii @ 2017-11-17  7:14 UTC (permalink / raw)
  To: Richard Copley
  Cc: fabrice.popineau, emacs-devel, jostein, jostein, drew.adams,
	phillip.lord

> From: Richard Copley <rcopley@gmail.com>
> Date: Thu, 16 Nov 2017 20:45:36 +0000
> Cc: Eli Zaretskii <eliz@gnu.org>, Jostein Kjønigsen <jostein@secure.kjonigsen.net>, 
> 	Emacs developers <emacs-devel@gnu.org>, Jostein Kjønigsen <jostein@kjonigsen.net>, 
> 	Drew Adams <drew.adams@oracle.com>, Phillip Lord <phillip.lord@russet.org.uk>
> 
> Windows is ridiculously slow to start a new process.

You mean Cygwin and MSYS, not Windows itself, right?  Because 99.99%
of process starting during the build is MSYS Bash starting GCC, Grep,
Find, and other programs.



^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: windows installer
  2017-11-17  7:14                                         ` Eli Zaretskii
@ 2017-11-17  7:22                                           ` Fabrice Popineau
  2017-11-17  7:35                                             ` Eli Zaretskii
  0 siblings, 1 reply; 75+ messages in thread
From: Fabrice Popineau @ 2017-11-17  7:22 UTC (permalink / raw)
  To: Eli Zaretskii
  Cc: Emacs developers, Richard Copley, Jostein Kjønigsen,
	Jostein Kjønigsen, Drew Adams, Phillip Lord

[-- Attachment #1: Type: text/plain, Size: 1035 bytes --]

2017-11-17 8:14 GMT+01:00 Eli Zaretskii <eliz@gnu.org>:

> > From: Richard Copley <rcopley@gmail.com>
> > Date: Thu, 16 Nov 2017 20:45:36 +0000
> > Cc: Eli Zaretskii <eliz@gnu.org>, Jostein Kjønigsen <
> jostein@secure.kjonigsen.net>,
> >       Emacs developers <emacs-devel@gnu.org>, Jostein Kjønigsen <
> jostein@kjonigsen.net>,
> >       Drew Adams <drew.adams@oracle.com>, Phillip Lord <
> phillip.lord@russet.org.uk>
> >
> > Windows is ridiculously slow to start a new process.
>
> You mean Cygwin and MSYS, not Windows itself, right?  Because 99.99%
> of process starting during the build is MSYS Bash starting GCC, Grep,
> Find, and other programs.
>

Actually, it is the CreateProcess() call which is overkill for most of its
usages.
From what I have read, the problem comes from attaching default console,
checking permissions and stuff like that, which fork() does in a very
different way.
Windows has been designed for dlls and inter-dlls calls, not for processes
communicating
the way Unix did.

[-- Attachment #2: Type: text/html, Size: 1812 bytes --]

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: windows installer
  2017-11-16 20:45                                       ` Richard Copley
  2017-11-17  7:14                                         ` Eli Zaretskii
@ 2017-11-17  7:25                                         ` Fabrice Popineau
  1 sibling, 0 replies; 75+ messages in thread
From: Fabrice Popineau @ 2017-11-17  7:25 UTC (permalink / raw)
  To: Richard Copley
  Cc: Emacs developers, Jostein Kjønigsen, Eli Zaretskii,
	Jostein Kjønigsen, Drew Adams, Phillip Lord

[-- Attachment #1: Type: text/plain, Size: 829 bytes --]

2017-11-16 21:45 GMT+01:00 Richard Copley <rcopley@gmail.com>:

> On 16 November 2017 at 18:10, Fabrice Popineau
> <fabrice.popineau@gmail.com> wrote:
> >
> > 2017-11-16 18:39 GMT+01:00 Eli Zaretskii <eliz@gnu.org>:
> >>
> >> > From: Fabrice Popineau <fabrice.popineau@gmail.com>
> >> > And on my machine, ./configure is about 10 times slower than compiling
> >> > emacs itself (the make -j8 part).
> >>
> >> Does configure on your machine take anywhere near an hour?  I doubt
> >> that.
> >>
> >
> > 'make -j8 bootstrap' takes 20mn.
> > The ./configure part takes 3-4mn.
>
> That is "10 times faster", not "10 times slower".
>
> No, the figure above is for 'bootstrap'. Most of the time is spent
compiling
.elc files.

Running conifgure take 3-4mn on my machine, but compiling emacs.exe
rather takes 30s once configure is done.

[-- Attachment #2: Type: text/html, Size: 1545 bytes --]

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: windows installer
  2017-11-17  7:22                                           ` Fabrice Popineau
@ 2017-11-17  7:35                                             ` Eli Zaretskii
  0 siblings, 0 replies; 75+ messages in thread
From: Eli Zaretskii @ 2017-11-17  7:35 UTC (permalink / raw)
  To: Fabrice Popineau
  Cc: emacs-devel, rcopley, jostein, jostein, drew.adams, phillip.lord

> From: Fabrice Popineau <fabrice.popineau@gmail.com>
> Date: Fri, 17 Nov 2017 08:22:52 +0100
> Cc: Richard Copley <rcopley@gmail.com>, Jostein Kjønigsen <jostein@secure.kjonigsen.net>, 
> 	Emacs developers <emacs-devel@gnu.org>, Jostein Kjønigsen <jostein@kjonigsen.net>, 
> 	Drew Adams <drew.adams@oracle.com>, Phillip Lord <phillip.lord@russet.org.uk>
> 
>  > Windows is ridiculously slow to start a new process.
> 
>  You mean Cygwin and MSYS, not Windows itself, right?  Because 99.99%
>  of process starting during the build is MSYS Bash starting GCC, Grep,
>  Find, and other programs.
> 
> Actually, it is the CreateProcess() call which is overkill for most of its usages.
> From what I have read, the problem comes from attaching default console, 
> checking permissions and stuff like that, which fork() does in a very different way.
> Windows has been designed for dlls and inter-dlls calls, not for processes communicating
> the way Unix did.

AFAIK, Cygwin (and therefore MSYS) makes this much more expensive due
to fork emulation.



^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: windows installer
  2017-11-14 20:12               ` Angelo Graziosi
@ 2017-11-20  8:46                 ` Jostein Kjønigsen
  2017-11-20 18:07                   ` Eli Zaretskii
  2017-11-22 23:01                   ` Phillip Lord
  0 siblings, 2 replies; 75+ messages in thread
From: Jostein Kjønigsen @ 2017-11-20  8:46 UTC (permalink / raw)
  To: emacs-devel, Phillip Lord

[-- Attachment #1: Type: text/plain, Size: 2862 bytes --]

Let's pause and take a look at the high level overview of what we
have here:
 * A working "normal" Windows installer, which has issues which still
   needs to be resolved. There may even be some GNU-level initiatives
   which must be committed to and finalized (code-signing
   certificates, etc).

 * Discussion about a "portable" installer, and what people want that to
   be and do. The portable installer will also need all these fixes
   which the regular installer needs before it can be useful.
Right now I can see there's quite a lot of bike-shedding about just what
a portable installer **is**, and what it should **do**. My impression
was that there's a *standard definition, *established *conventions* and
that this really *not *being a matter open for debate? But I may be
wrong and  as such I guess *some** *discussion is good.
Right now though there's so much discussion about the portable installer
to the point that I can't find any other discussion about the main
installer at all.
And considering how the portable installer most likely is going to be
used by a minority of Windows-users, and that it directly depends on the
work on the main Windows-installer to be deliverable at all... To me
that seems very much like the wrong way to go about things.
So could we all please focus on getting the main, normal Windows-
installer landed before detouring into how we want the portable
installer to differ and how to best achieve that?
(And once again: Stellar work Phillip! Really appreciated!)

--
Vennlig hilsen
Jostein Kjønigsen

jostein@kjonigsen.net 🍵 jostein@gmail.com
https://jostein.kjonigsen.net


On Tue, Nov 14, 2017, at 09:12 PM, Angelo Graziosi wrote:
> 
>> Il 14 novembre 2017 alle 17.31 Fabrice Popineau
>> <fabrice.popineau@gmail.com> ha scritto:>> 
>> 
>> 2017-11-14 15:36 GMT+01:00 Angelo Graziosi <angelo.g0@libero.it>:
>> 
>>> 
>>>> Fabrice Popineau ha scritto:
>>>> 
>>>> 
>>>> The best portable program is the one you can install with unzip.
>>>> And it>>> is already the case for Emacs.
>>>> 
>>> 
>>> No. After you have unzipped and started Emacs, where do you think
>>> it will>>> write the .emacs.d folder?
>>> 
>> 
>> And why do you care about .emacs.d that much ?
>> You can setup emacs using the site-lisp directory if you don't
>> want to>> write to your host in ~/.emacs.d.
>> 
>> 
>>> You are using "portable" with a meaning a bit different from the
>>> one which>>> is discussed here... It should not write the host machine.
>>> 
>>> 
>> I don't think so.  I have already been there in the past and for
>> longer you>> seem to imagine.
>> My point is that you can configure everything from within emacs
>> without>> requiring an external installer
>> to fiddle with your host.
> 
> ..but not all [potential] users want to do that...
> 


[-- Attachment #2: Type: text/html, Size: 4377 bytes --]

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: windows installer
  2017-11-20  8:46                 ` Jostein Kjønigsen
@ 2017-11-20 18:07                   ` Eli Zaretskii
  2017-11-22 23:01                   ` Phillip Lord
  1 sibling, 0 replies; 75+ messages in thread
From: Eli Zaretskii @ 2017-11-20 18:07 UTC (permalink / raw)
  To: jostein; +Cc: phillip.lord, emacs-devel

> From: Jostein Kjønigsen <jostein@secure.kjonigsen.net>
> Date: Mon, 20 Nov 2017 09:46:47 +0100
> 
> So could we all please focus on getting the main, normal Windows-installer landed before detouring into how
> we want the portable installer to differ and how to best achieve that?

You seem to think that this discussion somehow delays the installer,
but I don't think this is true.



^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: windows installer
  2017-11-16 17:35                                 ` Fabrice Popineau
  2017-11-16 17:39                                   ` Eli Zaretskii
  2017-11-16 17:42                                   ` Noam Postavsky
@ 2017-11-22 22:39                                   ` Phillip Lord
  2 siblings, 0 replies; 75+ messages in thread
From: Phillip Lord @ 2017-11-22 22:39 UTC (permalink / raw)
  To: Fabrice Popineau
  Cc: Jostein Kjønigsen, Eli Zaretskii, Jostein Kjønigsen,
	Drew Adams, Emacs developers

Fabrice Popineau <fabrice.popineau@gmail.com> writes:

> 2017-11-16 17:57 GMT+01:00 Eli Zaretskii <eliz@gnu.org>:
>
>> >
>> >  Try "make -j8" instead, and it will end much faster.
>> >
>> > Well, the slow part is still configure, because of the numerous
>> instances of shell that are launched.
>>
>> Not here, it isn't.  The slow part is byte compilation of the files
>> with bootstrap-emacs, until it is rebuilt with byte-compiled compiler.
>>
>
> Phillip said :
>
> ./configure ; make
>
> Since when does it bootstrap emacs and recompile elc files ?
>
> And on my machine, ./configure is about 10 times slower than compiling
> emacs itself (the make -j8 part).

I was talking about "make" from a clean tree (which is how I build for
distribution). But, yes, with -j8 and a incomplete tree clearly, it's
much faster.

Phil



^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: windows installer
  2017-11-20  8:46                 ` Jostein Kjønigsen
  2017-11-20 18:07                   ` Eli Zaretskii
@ 2017-11-22 23:01                   ` Phillip Lord
  2017-11-23  3:43                     ` Eli Zaretskii
  1 sibling, 1 reply; 75+ messages in thread
From: Phillip Lord @ 2017-11-22 23:01 UTC (permalink / raw)
  To: Jostein Kjønigsen; +Cc: jostein, emacs-devel


Jostein Kjønigsen <jostein@secure.kjonigsen.net> writes:
> Right now I can see there's quite a lot of bike-shedding about just what
> a portable installer **is**, and what it should **do**. My impression
> was that there's a *standard definition, *established *conventions* and
> that this really *not *being a matter open for debate? But I may be
> wrong and  as such I guess *some** *discussion is good.
> Right now though there's so much discussion about the portable installer
> to the point that I can't find any other discussion about the main
> installer at all.

The "portable" installer is a very clear thing I have in my mind; I
would like to add it to the PortableApp.com system which is cute and
because it I use it to provide myself with some tools on a shared "h"
drive. Currently, I do Emacs and the JDK by hand. Would be nice to
reduce this by one.

Its also NSIS based (as it the "main" installer). It shouldn't be to
much work.

> So could we all please focus on getting the main, normal Windows-
> installer landed before detouring into how we want the portable
> installer to differ and how to best achieve that?
> (And once again: Stellar work Phillip! Really appreciated!)

"we all" in the sense of me?

Anyway, the latest "snapshot" of the installer is now on the pretest
site. Changes since last time:

 - Rebranded
 - Some changes to the file names including dated snapshots (only for
   snapshots, of course)
 - "Program Files" default install (which means a root install).

and what ever random changes have hit master since the last time.

https://alpha.gnu.org/gnu/emacs/pretest/windows/emacs-27/

I've also got the build working on a cloud based machine as opposed to
the machine I use for watching TV on. This should make snapshots easier
for me to build (although, incidentally, following previous discussions,
two full builds of Emacs, and generation of two zips and the installer
takes about 8 hours).

Does Emacs still store the build machine anywhere in the binaries that
it produces? Currently, the windows build machine is on my own private
network, but if I shift it to the cloud, it's going to be with public
IP; it makes no sense to advertise this.

Phil



^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: windows installer
  2017-11-22 23:01                   ` Phillip Lord
@ 2017-11-23  3:43                     ` Eli Zaretskii
  2017-11-23 18:06                       ` Phillip Lord
  0 siblings, 1 reply; 75+ messages in thread
From: Eli Zaretskii @ 2017-11-23  3:43 UTC (permalink / raw)
  To: Phillip Lord; +Cc: jostein, jostein, emacs-devel

> From: phillip.lord@russet.org.uk (Phillip Lord)
> Date: Wed, 22 Nov 2017 23:01:21 +0000
> Cc: jostein@kjonigsen.net, emacs-devel@gnu.org
> 
> Does Emacs still store the build machine anywhere in the binaries that
> it produces?

See emacs-build-system.

> Currently, the windows build machine is on my own private network,
> but if I shift it to the cloud, it's going to be with public IP; it
> makes no sense to advertise this.

If you remove that, how will we know from the bug report that the
binary they used is the one we distribute from the GNU site?  It's an
important piece of information when looking into a bug.



^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: windows installer
  2017-11-23  3:43                     ` Eli Zaretskii
@ 2017-11-23 18:06                       ` Phillip Lord
  2017-11-23 20:09                         ` Eli Zaretskii
  0 siblings, 1 reply; 75+ messages in thread
From: Phillip Lord @ 2017-11-23 18:06 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: jostein, jostein, emacs-devel

Eli Zaretskii <eliz@gnu.org> writes:

>> From: phillip.lord@russet.org.uk (Phillip Lord)
>> Date: Wed, 22 Nov 2017 23:01:21 +0000
>> Cc: jostein@kjonigsen.net, emacs-devel@gnu.org
>> 
>> Does Emacs still store the build machine anywhere in the binaries that
>> it produces?
>
> See emacs-build-system.
>
>> Currently, the windows build machine is on my own private network,
>> but if I shift it to the cloud, it's going to be with public IP; it
>> makes no sense to advertise this.
>
> If you remove that, how will we know from the bug report that the
> binary they used is the one we distribute from the GNU site?  It's an
> important piece of information when looking into a bug.

For this, you just need a name which is reasonably likely to be
unique. In fact, for the Emacs-25 series binaries emacs-build-system is
set to simply to a proper name which is not resolvable or otherwise
identifiable.

If I use a cloud service, it will be a different and incomprehensible
string. I don't know if the system name allows identification of the
public IP or not; if it does, it's unfortunate.


Phil





^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: windows installer
  2017-11-23 18:06                       ` Phillip Lord
@ 2017-11-23 20:09                         ` Eli Zaretskii
  2017-11-24 19:13                           ` Phillip Lord
  0 siblings, 1 reply; 75+ messages in thread
From: Eli Zaretskii @ 2017-11-23 20:09 UTC (permalink / raw)
  To: Phillip Lord; +Cc: jostein, jostein, emacs-devel

> From: phillip.lord@russet.org.uk (Phillip Lord)
> Cc: jostein@secure.kjonigsen.net,  jostein@kjonigsen.net,  emacs-devel@gnu.org
> Date: Thu, 23 Nov 2017 18:06:22 +0000
> 
> > If you remove that, how will we know from the bug report that the
> > binary they used is the one we distribute from the GNU site?  It's an
> > important piece of information when looking into a bug.
> 
> For this, you just need a name which is reasonably likely to be
> unique.

Yes, we need a name that is not nil.



^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: windows installer
  2017-11-23 20:09                         ` Eli Zaretskii
@ 2017-11-24 19:13                           ` Phillip Lord
  2017-11-24 19:56                             ` Eli Zaretskii
  0 siblings, 1 reply; 75+ messages in thread
From: Phillip Lord @ 2017-11-24 19:13 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: jostein, jostein, emacs-devel

Eli Zaretskii <eliz@gnu.org> writes:

>> From: phillip.lord@russet.org.uk (Phillip Lord)
>> Cc: jostein@secure.kjonigsen.net,  jostein@kjonigsen.net,  emacs-devel@gnu.org
>> Date: Thu, 23 Nov 2017 18:06:22 +0000
>> 
>> > If you remove that, how will we know from the bug report that the
>> > binary they used is the one we distribute from the GNU site?  It's an
>> > important piece of information when looking into a bug.
>> 
>> For this, you just need a name which is reasonably likely to be
>> unique.
>
> Yes, we need a name that is not nil.


So something like this:

(defconst emacs-build-system
          (if (file-exists-p "~/.emacs-build-system-name")
              (with-temp-buffer
                (insert-file-contents "~/.emacs-build-system-name")
                (buffer-string))
             (system-name)))
              

would be okay? The defconst is set at byte-compilation time right?
That's why

(defconst emacs-build-system (system-name)
  "Name of the system on which Emacs was built, or nil if not available.")

Returns the build-system rather than the current?

Phil



^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: windows installer
  2017-11-24 19:13                           ` Phillip Lord
@ 2017-11-24 19:56                             ` Eli Zaretskii
  2017-11-25 11:08                               ` Phillip Lord
  0 siblings, 1 reply; 75+ messages in thread
From: Eli Zaretskii @ 2017-11-24 19:56 UTC (permalink / raw)
  To: Phillip Lord; +Cc: jostein, jostein, emacs-devel

> From: phillip.lord@russet.org.uk (Phillip Lord)
> Cc: jostein@secure.kjonigsen.net,  jostein@kjonigsen.net,  emacs-devel@gnu.org
> Date: Fri, 24 Nov 2017 19:13:31 +0000
> 
> > Yes, we need a name that is not nil.
> 
> So something like this:
> 
> (defconst emacs-build-system
>           (if (file-exists-p "~/.emacs-build-system-name")
>               (with-temp-buffer
>                 (insert-file-contents "~/.emacs-build-system-name")
>                 (buffer-string))
>              (system-name)))

Where do you want to put this?  Are you going to patch the sources
from which you produce the binaries?

> The defconst is set at byte-compilation time right?
> That's why
> 
> (defconst emacs-build-system (system-name)
>   "Name of the system on which Emacs was built, or nil if not available.")
> 
> Returns the build-system rather than the current?

No, it's set at loadup time, when version.elc is loaded into temacs.



^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: windows installer
  2017-11-24 19:56                             ` Eli Zaretskii
@ 2017-11-25 11:08                               ` Phillip Lord
  2017-11-25 12:56                                 ` Eli Zaretskii
  0 siblings, 1 reply; 75+ messages in thread
From: Phillip Lord @ 2017-11-25 11:08 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: jostein, jostein, emacs-devel

Eli Zaretskii <eliz@gnu.org> writes:

>> From: phillip.lord@russet.org.uk (Phillip Lord) Cc:
>> jostein@secure.kjonigsen.net, jostein@kjonigsen.net,
>> emacs-devel@gnu.org Date: Fri, 24 Nov 2017 19:13:31 +0000
>> 
>> > Yes, we need a name that is not nil.
>> 
>> So something like this:
>> 
>> (defconst emacs-build-system
>>           (if (file-exists-p "~/.emacs-build-system-name")
>>               (with-temp-buffer
>>                 (insert-file-contents "~/.emacs-build-system-name")
>>                 (buffer-string))
>>              (system-name)))
>
> Where do you want to put this?  Are you going to patch the sources
> from which you produce the binaries?

master


>> The defconst is set at byte-compilation time right?
>> That's why
>> 
>> (defconst emacs-build-system (system-name)
>>   "Name of the system on which Emacs was built, or nil if not available.")
>> 
>> Returns the build-system rather than the current?
>
> No, it's set at loadup time, when version.elc is loaded into temacs.

Oh, yes, of course.

Phil



^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: windows installer
  2017-11-25 11:08                               ` Phillip Lord
@ 2017-11-25 12:56                                 ` Eli Zaretskii
  2017-11-27 17:56                                   ` Phillip Lord
  0 siblings, 1 reply; 75+ messages in thread
From: Eli Zaretskii @ 2017-11-25 12:56 UTC (permalink / raw)
  To: Phillip Lord; +Cc: jostein, jostein, emacs-devel

> From: phillip.lord@russet.org.uk (Phillip Lord)
> Cc: jostein@secure.kjonigsen.net,  jostein@kjonigsen.net,  emacs-devel@gnu.org
> Date: Sat, 25 Nov 2017 11:08:12 +0000
> 
> >> (defconst emacs-build-system
> >>           (if (file-exists-p "~/.emacs-build-system-name")
> >>               (with-temp-buffer
> >>                 (insert-file-contents "~/.emacs-build-system-name")
> >>                 (buffer-string))
> >>              (system-name)))
> >
> > Where do you want to put this?  Are you going to patch the sources
> > from which you produce the binaries?
> 
> master

Then I think a much better way would be to access some environment
variable instead of a file.  (Assuming there's no way for you to
arrange for that system to return some string of your liking as the
system name -- if that's possible, it would be preferable, because
having in our code something that caters to building installable
binaries on MS-Windows is not something I'd do happily.)



^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: windows installer
  2017-11-25 12:56                                 ` Eli Zaretskii
@ 2017-11-27 17:56                                   ` Phillip Lord
  0 siblings, 0 replies; 75+ messages in thread
From: Phillip Lord @ 2017-11-27 17:56 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: jostein, jostein, emacs-devel

Eli Zaretskii <eliz@gnu.org> writes:

>> From: phillip.lord@russet.org.uk (Phillip Lord)
>> Cc: jostein@secure.kjonigsen.net,  jostein@kjonigsen.net,  emacs-devel@gnu.org
>> Date: Sat, 25 Nov 2017 11:08:12 +0000
>> 
>> >> (defconst emacs-build-system
>> >>           (if (file-exists-p "~/.emacs-build-system-name")
>> >>               (with-temp-buffer
>> >>                 (insert-file-contents "~/.emacs-build-system-name")
>> >>                 (buffer-string))
>> >>              (system-name)))
>> >
>> > Where do you want to put this?  Are you going to patch the sources
>> > from which you produce the binaries?
>> 
>> master
>
> Then I think a much better way would be to access some environment
> variable instead of a file.  (Assuming there's no way for you to
> arrange for that system to return some string of your liking as the
> system name -- if that's possible, it would be preferable, because
> having in our code something that caters to building installable
> binaries on MS-Windows is not something I'd do happily.)


Hmm, yes. Changing the system name seems to work and doesn't seem to
break anything. This seems like an easier solution. Sorry for noise.

Phil



^ permalink raw reply	[flat|nested] 75+ messages in thread

end of thread, other threads:[~2017-11-27 17:56 UTC | newest]

Thread overview: 75+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-10-26 23:11 windows installer Phillip Lord
2017-10-28 21:47 ` Richard Stallman
2017-11-06  8:11 ` Jostein Kjønigsen
     [not found]   ` <87h8u6bae3.fsf@russet.org.uk>
     [not found]     ` <WM!524810e63610127669556b68fb62cde560daf19be50fc52d4d63dd232af7bdb0490810e03b84a6559c9b2017d8462cc3!@mailhub-mx4.ncl.ac.uk>
2017-11-08  7:31       ` Jostein Kjønigsen
2017-11-10 17:01         ` Phillip Lord
2017-11-10 18:52           ` Eli Zaretskii
2017-11-10 20:46             ` Stefan Monnier
2017-11-10 21:22               ` John Mastro
2017-11-10 21:35               ` Fabrice Popineau
2017-11-11  7:33               ` Eli Zaretskii
2017-11-11 11:34                 ` Phillip Lord
2017-11-11 14:57                 ` Stefan Monnier
2017-11-12 11:21                 ` Jostein Kjønigsen
2017-11-10 21:33             ` Fabrice Popineau
2017-11-11  7:35               ` Eli Zaretskii
2017-11-10 23:27             ` Phillip Lord
2017-11-11  0:25               ` Fabrice Popineau
2017-11-11 11:25                 ` Phillip Lord
2017-11-12  0:30                   ` Fabrice Popineau
2017-11-12  4:30                     ` Eli Zaretskii
     [not found]                     ` <87fu9hbytq.fsf@russet.org.uk>
2017-11-13 22:25                       ` Phillip Lord
2017-11-14 13:08                         ` Fabrice Popineau
2017-11-16 16:15                           ` Phillip Lord
2017-11-11  7:48               ` Eli Zaretskii
2017-11-11 11:24                 ` Phillip Lord
2017-11-11 12:01                   ` Eli Zaretskii
     [not found]           ` <<83ineiotjr.fsf@gnu.org>
2017-11-10 21:43             ` Drew Adams
2017-11-10 23:35               ` Phillip Lord
2017-11-11  7:49                 ` Eli Zaretskii
2017-11-11  7:40               ` Eli Zaretskii
2017-11-11  9:42                 ` Yuri Khan
2017-11-11 10:37                   ` Eli Zaretskii
2017-11-11 16:39                 ` Drew Adams
     [not found]                   ` <87a7zpbxza.fsf@russet.org.uk>
2017-11-13 22:44                     ` Phillip Lord
2017-11-14 14:54                       ` Drew Adams
2017-11-16 16:15                         ` Phillip Lord
2017-11-16 16:23                           ` Eli Zaretskii
2017-11-16 16:31                             ` Fabrice Popineau
2017-11-16 16:57                               ` Eli Zaretskii
2017-11-16 17:35                                 ` Fabrice Popineau
2017-11-16 17:39                                   ` Eli Zaretskii
2017-11-16 18:10                                     ` Fabrice Popineau
2017-11-16 20:45                                       ` Richard Copley
2017-11-17  7:14                                         ` Eli Zaretskii
2017-11-17  7:22                                           ` Fabrice Popineau
2017-11-17  7:35                                             ` Eli Zaretskii
2017-11-17  7:25                                         ` Fabrice Popineau
2017-11-16 17:42                                   ` Noam Postavsky
2017-11-16 17:45                                     ` Fabrice Popineau
2017-11-22 22:39                                   ` Phillip Lord
  -- strict thread matches above, loose matches on Subject: below --
2017-11-12  8:56 Angelo Graziosi
2017-11-12  9:03 ` Fabrice Popineau
2017-11-12 11:30   ` Eli Zaretskii
2017-11-12 12:39     ` Fabrice Popineau
     [not found]       ` <8760adbxw6.fsf@russet.org.uk>
2017-11-13 22:46         ` Phillip Lord
2017-11-14 14:36           ` Angelo Graziosi
2017-11-14 16:31             ` Fabrice Popineau
2017-11-14 20:12               ` Angelo Graziosi
2017-11-20  8:46                 ` Jostein Kjønigsen
2017-11-20 18:07                   ` Eli Zaretskii
2017-11-22 23:01                   ` Phillip Lord
2017-11-23  3:43                     ` Eli Zaretskii
2017-11-23 18:06                       ` Phillip Lord
2017-11-23 20:09                         ` Eli Zaretskii
2017-11-24 19:13                           ` Phillip Lord
2017-11-24 19:56                             ` Eli Zaretskii
2017-11-25 11:08                               ` Phillip Lord
2017-11-25 12:56                                 ` Eli Zaretskii
2017-11-27 17:56                                   ` Phillip Lord
2017-11-12 14:14   ` Angelo Graziosi
2017-11-12 11:28 ` Eli Zaretskii
2017-11-12 14:27   ` Angelo Graziosi
2017-11-12 15:04     ` Eli Zaretskii
2017-11-12 17:32       ` Angelo Graziosi
2017-11-12 18:42         ` Eli Zaretskii

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.