windows installer

windows installer

[Phillip Lord]

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

Re: windows installer

[Richard Stallman]

[[[ 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.

Re: windows installer

[Jostein Kjønigsen]

[-- 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 --]

Re: windows installer

[Jostein Kjønigsen]

[-- 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 --]

Re: windows installer

[Phillip Lord]

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

Re: windows installer

[Eli Zaretskii]

> 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.

Re: windows installer

[Stefan Monnier]

> 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

Re: windows installer

[John Mastro]

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

Re: windows installer

[Fabrice Popineau]

[-- 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 --]

Re: windows installer

[Eli Zaretskii]

> 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?

Re: windows installer

[Phillip Lord]

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

Re: windows installer

[Stefan Monnier]

> 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

Re: windows installer

[Jostein Kjønigsen]

[-- 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 --]

Re: windows installer

[Fabrice Popineau]

[-- 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 --]

Re: windows installer

[Eli Zaretskii]

> 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.

Re: windows installer

[Phillip Lord]

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

Re: windows installer

[Fabrice Popineau]

[-- 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 --]

Re: windows installer

[Phillip Lord]

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

Re: windows installer

[Fabrice Popineau]

[-- 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 --]

Re: windows installer

[Eli Zaretskii]

> 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.)

Re: windows installer

[Phillip Lord]

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

Re: windows installer

[Fabrice Popineau]

[-- 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 --]

Re: windows installer

[Phillip Lord]

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

Re: windows installer

[Eli Zaretskii]

> 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".

Re: windows installer

[Phillip Lord]

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

Re: windows installer

[Eli Zaretskii]

> 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.

RE: windows installer

[Drew Adams]

> > >  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.

Re: windows installer

[Phillip Lord]

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

Re: windows installer

[Eli Zaretskii]

> 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.

Re: windows installer

[Eli Zaretskii]

> 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.

Re: windows installer

[Yuri Khan]

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

Re: windows installer

[Eli Zaretskii]

> 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.

RE: windows installer

[Drew Adams]

> > 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.

Re: windows installer

[Phillip Lord]

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

RE: windows installer

[Drew Adams]

> > 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.

Re: windows installer

[Phillip Lord]

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

Re: windows installer

[Eli Zaretskii]

> 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.

Re: windows installer

[Fabrice Popineau]

[-- 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 --]

Re: windows installer

[Eli Zaretskii]

> 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.

Re: windows installer

[Fabrice Popineau]

[-- 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 --]

Re: windows installer

[Eli Zaretskii]

> 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.

Re: windows installer

[Fabrice Popineau]

[-- 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 --]

Re: windows installer

[Richard Copley]

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).

Re: windows installer

[Eli Zaretskii]

> 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.

Re: windows installer

[Fabrice Popineau]

[-- 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 --]

Re: windows installer

[Eli Zaretskii]

> 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.

Re: windows installer

[Fabrice Popineau]

[-- 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 --]

Re: windows installer

[Noam Postavsky]

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.

Re: windows installer

[Fabrice Popineau]

[-- 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 --]

Re: windows installer

[Phillip Lord]

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

Re: windows installer

[Angelo Graziosi]

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

Re: windows installer

[Fabrice Popineau]

[-- 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 --]

Re: windows installer

[Eli Zaretskii]

> 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.

Re: windows installer

[Fabrice Popineau]

[-- 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 --]

Re: windows installer

[Phillip Lord]

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

Re: windows installer

[Angelo Graziosi]

> 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

Re: windows installer

[Fabrice Popineau]

[-- 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 --]

Re: windows installer

[Angelo Graziosi]

> 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...

Re: windows installer

[Jostein Kjønigsen]

[-- 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 --]

Re: windows installer

[Eli Zaretskii]

> 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.

Re: windows installer

[Phillip Lord]

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

Re: windows installer

[Eli Zaretskii]

> 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.

Re: windows installer

[Phillip Lord]

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

Re: windows installer

[Eli Zaretskii]

> 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.

Re: windows installer

[Phillip Lord]

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

Re: windows installer

[Eli Zaretskii]

> 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.

Re: windows installer

[Phillip Lord]

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

Re: windows installer

[Eli Zaretskii]

> 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.)

Re: windows installer

[Phillip Lord]

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

Re: windows installer

[Angelo Graziosi]

> 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

Re: windows installer

[Eli Zaretskii]

> 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.

Re: windows installer

[Angelo Graziosi]

> 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

Re: windows installer

[Eli Zaretskii]

> 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.

Re: windows installer

[Angelo Graziosi]

> 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..

Re: windows installer

[Eli Zaretskii]

> 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.