* Next pretest, and branching plans @ 2010-02-18 11:02 Chong Yidong 2010-02-18 15:29 ` Drew Adams 2010-02-18 23:57 ` Emacs Manuals Richard Stallman 0 siblings, 2 replies; 48+ messages in thread From: Chong Yidong @ 2010-02-18 11:02 UTC (permalink / raw To: emacs-devel I will roll the next pretest, 23.1.93, next week, Friday the 26th of February. Shortly afterwards, around Monday 1 March, we will make the release branch, which will be used for all subsequent 23.1.xx pretests, as well as the final 23.2 release. Once this branch is made, the feature freeze will be made "harder". Except for documentation improvements and special exceptions (which must first be discussed on emacs-devel, or with Stefan or myself), the only allowed bugfixes are for regressions with respect to Emacs 22. (At a still later date, we will only allow bugfixes for regressions with respect to Emacs 23.1.) Once the branch is made, Stefan or myself will announce on emacs-devel that the trunk is open for Emacs 24 development. At this point, we can merge the projects from the pending branch into the trunk, and so forth. We'll give more details about commit policy for the trunk, and our general goals for Emacs 24, later. (Opinions are welcome.) Once the branch is made, some bugfixes will need to be applied both to the trunk and to the branch. This is important, so anyone who has commit access should take note. ^ permalink raw reply [flat|nested] 48+ messages in thread
* RE: Next pretest, and branching plans 2010-02-18 11:02 Next pretest, and branching plans Chong Yidong @ 2010-02-18 15:29 ` Drew Adams 2010-02-20 12:25 ` Leo 2010-02-18 23:57 ` Emacs Manuals Richard Stallman 1 sibling, 1 reply; 48+ messages in thread From: Drew Adams @ 2010-02-18 15:29 UTC (permalink / raw To: 'Chong Yidong', emacs-devel > I will roll the next pretest, 23.1.93, next week, Friday the 26th of > February. Never got a Windows binary for the last one, 23.1.92. Spent a lot of time fiddling with stuff, trying to help test bugs and bug fixes (e.g. #5478) without the latest binary. Certainly couldn't file any new, pretest-related bugs. If pretest feedback from Windows users is at all useful or important to you, then you might consider this a loss. If not, just keep on rolling... ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: Next pretest, and branching plans 2010-02-18 15:29 ` Drew Adams @ 2010-02-20 12:25 ` Leo 2010-02-20 13:05 ` Sean Sieger 2010-02-20 16:52 ` Drew Adams 0 siblings, 2 replies; 48+ messages in thread From: Leo @ 2010-02-20 12:25 UTC (permalink / raw To: emacs-devel On 2010-02-18 15:29 +0000, Drew Adams wrote: >> I will roll the next pretest, 23.1.93, next week, Friday the 26th of >> February. > > Never got a Windows binary for the last one, 23.1.92. > > Spent a lot of time fiddling with stuff, trying to help test bugs and bug fixes > (e.g. #5478) without the latest binary. Certainly couldn't file any new, > pretest-related bugs. > > If pretest feedback from Windows users is at all useful or important to you, > then you might consider this a loss. If not, just keep on rolling... Is a policy to provide a binary for windows? There's no binary for GNU/Linux, OSX and many others. But when I was using Windows, I have found the following two sources that provide excellent binary for windows. http://code.google.com/p/emacs-for-windows/ http://www.ourcomments.org/Emacs/DL/EmacsW32/EmacsCVS/unptch/emacs-from-cvs-091015.zip Cheers, Leo ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: Next pretest, and branching plans 2010-02-20 12:25 ` Leo @ 2010-02-20 13:05 ` Sean Sieger 2010-02-20 17:02 ` Drew Adams 2010-02-28 12:36 ` Sean Sieger 2010-02-20 16:52 ` Drew Adams 1 sibling, 2 replies; 48+ messages in thread From: Sean Sieger @ 2010-02-20 13:05 UTC (permalink / raw To: emacs-devel http://code.google.com/p/emacs-for-windows/ I'll have try this one, thank you. http://www.ourcomments.org/Emacs/DL/EmacsW32/EmacsCVS/unptch/emacs-from-cvs-091015.zip Huh? Look at the date stamp. This used to be a good resource. ^ permalink raw reply [flat|nested] 48+ messages in thread
* RE: Next pretest, and branching plans 2010-02-20 13:05 ` Sean Sieger @ 2010-02-20 17:02 ` Drew Adams 2010-02-28 12:36 ` Sean Sieger 1 sibling, 0 replies; 48+ messages in thread From: Drew Adams @ 2010-02-20 17:02 UTC (permalink / raw To: 'Sean Sieger', emacs-devel > http://code.google.com/p/emacs-for-windows/ > > I'll have try this one, thank you. > > http://www.ourcomments.org/Emacs/DL/EmacsW32/EmacsCVS/unptch/e > macs-from-cvs-091015.zip > > Huh? Look at the date stamp. This used to be a good resource. Neither represents the 23.1.92 pretest, AFAIK. The former says: GNU Emacs 23.1.91.1 (i386-mingw-nt5.1.2600) of 2010-01-02 on PRETEST Yidong announced the 23.1.92 pretest on 2010/01/29. ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: Next pretest, and branching plans 2010-02-20 13:05 ` Sean Sieger 2010-02-20 17:02 ` Drew Adams @ 2010-02-28 12:36 ` Sean Sieger 2010-02-28 15:13 ` Lennart Borgman 1 sibling, 1 reply; 48+ messages in thread From: Sean Sieger @ 2010-02-28 12:36 UTC (permalink / raw To: emacs-devel Sean Sieger <sean.sieger@gmail.com> writes: http://www.ourcomments.org/Emacs/DL/EmacsW32/EmacsCVS/unptch/emacs-from-cvs-091015.zip Huh? Look at the date stamp. This used to be a good resource. I'm sorry for this comment, Lennart. It didn't come out right. ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: Next pretest, and branching plans 2010-02-28 12:36 ` Sean Sieger @ 2010-02-28 15:13 ` Lennart Borgman 0 siblings, 0 replies; 48+ messages in thread From: Lennart Borgman @ 2010-02-28 15:13 UTC (permalink / raw To: Sean Sieger; +Cc: emacs-devel On Sun, Feb 28, 2010 at 1:36 PM, Sean Sieger <sean.sieger@gmail.com> wrote: > Sean Sieger <sean.sieger@gmail.com> writes: > > http://www.ourcomments.org/Emacs/DL/EmacsW32/EmacsCVS/unptch/emacs-from-cvs-091015.zip > > Huh? Look at the date stamp. This used to be a good resource. > > I'm sorry for this comment, Lennart. It didn't come out right. No problem. I have just been caught in too much things to get the uploads working without problem again. It will work again in a while. ^ permalink raw reply [flat|nested] 48+ messages in thread
* RE: Next pretest, and branching plans 2010-02-20 12:25 ` Leo 2010-02-20 13:05 ` Sean Sieger @ 2010-02-20 16:52 ` Drew Adams 2010-02-20 17:35 ` Drew Adams 2010-02-20 17:51 ` Eli Zaretskii 1 sibling, 2 replies; 48+ messages in thread From: Drew Adams @ 2010-02-20 16:52 UTC (permalink / raw To: 'Leo', emacs-devel > > If pretest feedback from Windows users is at all useful or > > important to you, then you might consider this a loss. > > If not, just keep on rolling... > > Is a policy to provide a binary for windows? There's no binary for > GNU/Linux, OSX and many others. I cannot speak to what the "policy" is, or whether there even is a policy. I make no claim about policy. GNU Emacs does publish this, FWIW: http://alpha.gnu.org/gnu/emacs/pretest/windows/. The README there (from 2010/01/03) says, "This directory contains precompiled distributions for GNU Emacs on Windows". That is, GNU Emacs publishes a directory that has _only_ Windows binaries. No, the README does not claim that the directory includes a binary of the latest pretest. And it did not include a binary for the previous pretest (23.1.91) either, until we reminded about it a few times and Jason found time to create and post it (thank you). But prior to that, AFAIK, it generally _has_ included pretest binaries. I repeat: *IF* such feedback from Windows users is important to Emacs development, then you might consider that not posting a binary will reduce useful feedback. Speaking for myself only, that will be the case. As an example, I recently spent some time with Michael A. trying to debug and fix bug #5478, and we were forced to test using the previous Windows pretest because the latest was not available. With no pretest binaries at all, next time perhaps we will need to wait for a binary of the next release. Or the bug might find someone who wants to not only fix the bug but also build Emacs on Windows. Perhaps more importantly, there will be fewer (far fewer, IMO) new bug reports from Windows users for the latest code. Instead of a pretest, you will, in effect, just wait until after the release to get such bug reports. The purpose of the pretest will thus be defeated, except for those Windows pretesters who are willing to build Emacs. Speaking for myself again, I have submitted many bug reports for Emacs pretests, including for the last one (23.1.91). I submitted none for 23.1.92, since there was no binary. IF you think that bug reports during pretest can be helpful in general, then this is a loss. > But when I was using Windows, I have found the following two sources > that provide excellent binary for windows. > http://code.google.com/p/emacs-for-windows/ > http://www.ourcomments.org/Emacs/DL/EmacsW32/EmacsCVS/unptch/e > macs-from-cvs-091015.zip Yes, and there are other sites that also have, or have had, old Windows binaries. And people appreciate this. But that is all beside the point. Those you cite are from 2010/02/02 and 2009/10/15, respectively. Neither represents the latest pretest. That's the point: the pretest. If you, Lennart or anyone else builds a pretest binary and posts it, that will be helpful and appreciated. ^ permalink raw reply [flat|nested] 48+ messages in thread
* RE: Next pretest, and branching plans 2010-02-20 16:52 ` Drew Adams @ 2010-02-20 17:35 ` Drew Adams 2010-02-20 19:45 ` Eli Zaretskii 2010-02-20 17:51 ` Eli Zaretskii 1 sibling, 1 reply; 48+ messages in thread From: Drew Adams @ 2010-02-20 17:35 UTC (permalink / raw To: emacs-devel Related to this is the fact that bug #5299, a regression, is still outstanding. It prevents Windows users from using `M-x report-emacs-bug' to file bugs. Do you really want bug reports from Windows users? ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: Next pretest, and branching plans 2010-02-20 17:35 ` Drew Adams @ 2010-02-20 19:45 ` Eli Zaretskii 2010-02-20 20:39 ` Drew Adams 2010-02-21 0:11 ` Lennart Borgman 0 siblings, 2 replies; 48+ messages in thread From: Eli Zaretskii @ 2010-02-20 19:45 UTC (permalink / raw To: Drew Adams; +Cc: emacs-devel > From: "Drew Adams" <drew.adams@oracle.com> > Date: Sat, 20 Feb 2010 09:35:24 -0800 > > Related to this is the fact that bug #5299, a regression, is still outstanding. > It prevents Windows users from using `M-x report-emacs-bug' to file bugs. I don't know what to fix there. Email never worked for me on Windows without some setup. I use smtpmail, but it will not work without setting it up for your ISP's mail server. So, for me, there's no regression: it never worked in previous versions of Emacs, and it does not work now. Lennart seems to know what kind of solution worked for you in the past, so perhaps Lennart could try fixing that, or at least describing what changed in Emacs that broke that solution, whatever it is. I don't have Outlook set up to even try what you describe. > Do you really want bug reports from Windows users? Yes, and you know that. ^ permalink raw reply [flat|nested] 48+ messages in thread
* RE: Next pretest, and branching plans 2010-02-20 19:45 ` Eli Zaretskii @ 2010-02-20 20:39 ` Drew Adams 2010-02-20 20:53 ` Lennart Borgman 2010-02-21 0:11 ` Lennart Borgman 1 sibling, 1 reply; 48+ messages in thread From: Drew Adams @ 2010-02-20 20:39 UTC (permalink / raw To: 'Eli Zaretskii'; +Cc: emacs-devel > > Related to this is the fact that bug #5299, a regression, > > is still outstanding. It prevents Windows users from > > using `M-x report-emacs-bug' to file bugs. > > I don't know what to fix there. Email never worked for me on Windows > without some setup. I use smtpmail, but it will not work without > setting it up for your ISP's mail server. > > So, for me, there's no regression: it never worked in previous > versions of Emacs, and it does not work now. > > Lennart seems to know what kind of solution worked for you in the > past, so perhaps Lennart could try fixing that, or at least describing > what changed in Emacs that broke that solution, whatever it is. I > don't have Outlook set up to even try what you describe. (Perhaps this really belongs in the bug #5299 thread?) I have no idea what problems you had previously, or what caused the recent problem. But I can (and do) use `M-x report-emacs-bug' fine with Emacs releases 22 and 23 (and with pretests, before I reported the bug). It works fine in those releases (still). My mail client is Outlook, but I don't know if your mail client has anything to do with your problems using `M-x report-emacs-bug'. Something was changed since the Emacs 23.1 release, so that this became broken. It _is_ a regression, at least for my use case with an external mail client (Outlook). If it never worked for you, that's unfortunate, but that does not mean that it never worked. I don't think (but I don't know) that whatever enabled `report-emacs-bug' to work previously was Outlook-specific. It might have been something Windows-specific (dunno). It might have been something specific for use with an external mail client (any external client) - dunno. But I doubt that it was something Outlook-specific. ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: Next pretest, and branching plans 2010-02-20 20:39 ` Drew Adams @ 2010-02-20 20:53 ` Lennart Borgman 0 siblings, 0 replies; 48+ messages in thread From: Lennart Borgman @ 2010-02-20 20:53 UTC (permalink / raw To: Drew Adams; +Cc: Eli Zaretskii, emacs-devel On Sat, Feb 20, 2010 at 9:39 PM, Drew Adams <drew.adams@oracle.com> wrote: >> >> Lennart seems to know what kind of solution worked for you in the >> past, so perhaps Lennart could try fixing that, or at least describing >> what changed in Emacs that broke that solution, whatever it is. I >> don't have Outlook set up to even try what you describe. > > (Perhaps this really belongs in the bug #5299 thread?) > > I have no idea what problems you had previously, or what caused the recent > problem. > > But I can (and do) use `M-x report-emacs-bug' fine with Emacs releases 22 and 23 > (and with pretests, before I reported the bug). It works fine in those releases > (still). > > My mail client is Outlook, but I don't know if your mail client has anything to > do with your problems using `M-x report-emacs-bug'. > > Something was changed since the Emacs 23.1 release, so that this became broken. > It _is_ a regression, at least for my use case with an external mail client > (Outlook). If it never worked for you, that's unfortunate, but that does not > mean that it never worked. Yes, it is a regression. I spent quite a lot of time finding a simple useful solution before (the one that is broken now). It was a w32 only solution so I guess it has been broken by someone who does not understand the general nature of the OS interface. > I don't think (but I don't know) that whatever enabled `report-emacs-bug' to > work previously was Outlook-specific. It might have been something > Windows-specific (dunno). It might have been something specific for use with an > external mail client (any external client) - dunno. But I doubt that it was > something Outlook-specific. No, the mail client has nothing to do with it. The solution was general enough to use any mail client on w32. ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: Next pretest, and branching plans 2010-02-20 19:45 ` Eli Zaretskii 2010-02-20 20:39 ` Drew Adams @ 2010-02-21 0:11 ` Lennart Borgman 2010-02-21 4:11 ` Eli Zaretskii 1 sibling, 1 reply; 48+ messages in thread From: Lennart Borgman @ 2010-02-21 0:11 UTC (permalink / raw To: Eli Zaretskii; +Cc: Drew Adams, emacs-devel On Sat, Feb 20, 2010 at 8:45 PM, Eli Zaretskii <eliz@gnu.org> wrote: > >> Do you really want bug reports from Windows users? > > Yes, and you know that. I just uploaded new unpatched binaries as I told. However I wonder if I was uploading the right thing from a pretest point of view. If I already have Emacs sources checked out (which I have of course) is there a way to build pretest binaries from what I have? I have no idea about how the branches and bazaar works for this. ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: Next pretest, and branching plans 2010-02-21 0:11 ` Lennart Borgman @ 2010-02-21 4:11 ` Eli Zaretskii 0 siblings, 0 replies; 48+ messages in thread From: Eli Zaretskii @ 2010-02-21 4:11 UTC (permalink / raw To: Lennart Borgman; +Cc: emacs-devel > From: Lennart Borgman <lennart.borgman@gmail.com> > Date: Sun, 21 Feb 2010 01:11:22 +0100 > Cc: Drew Adams <drew.adams@oracle.com>, emacs-devel@gnu.org > > I just uploaded new unpatched binaries as I told. However I wonder if > I was uploading the right thing from a pretest point of view. > > If I already have Emacs sources checked out (which I have of course) > is there a way to build pretest binaries from what I have? I have no > idea about how the branches and bazaar works for this. The easiest way is to build the pretest sources downloaded from alpha.gnu.org. It is also possible to find out the revision number of the tree from which the pretest tarball was tarred, then "bzr revert" to that revert, and build it. But I don't see how this is easier. ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: Next pretest, and branching plans 2010-02-20 16:52 ` Drew Adams 2010-02-20 17:35 ` Drew Adams @ 2010-02-20 17:51 ` Eli Zaretskii 2010-02-20 18:35 ` Drew Adams ` (2 more replies) 1 sibling, 3 replies; 48+ messages in thread From: Eli Zaretskii @ 2010-02-20 17:51 UTC (permalink / raw To: Drew Adams; +Cc: sdl.web, emacs-devel > From: "Drew Adams" <drew.adams@oracle.com> > Date: Sat, 20 Feb 2010 08:52:50 -0800 > Cc: > > Perhaps more importantly, there will be fewer (far fewer, IMO) new bug reports > from Windows users for the latest code. Instead of a pretest, you will, in > effect, just wait until after the release to get such bug reports. The purpose > of the pretest will thus be defeated, except for those Windows pretesters who > are willing to build Emacs. It's not clear what statistics you have to back this up. I know for a fact that several users of the Windows port build Emacs themselves; what percentage that is of the overall number of people who use the pretest on Windows should be a subject of survey, not guesswork. FWIW, tools for such a build are readily available, and help for setting them up is offered here. So I could never understand why people who want to contribute refuse to install the necessary development environment. It's not that setting up such a development environment is hard or needs many hours. ^ permalink raw reply [flat|nested] 48+ messages in thread
* RE: Next pretest, and branching plans 2010-02-20 17:51 ` Eli Zaretskii @ 2010-02-20 18:35 ` Drew Adams 2010-02-20 19:49 ` Eli Zaretskii 2010-02-20 18:36 ` Chong Yidong 2010-02-20 19:08 ` Lennart Borgman 2 siblings, 1 reply; 48+ messages in thread From: Drew Adams @ 2010-02-20 18:35 UTC (permalink / raw To: 'Eli Zaretskii'; +Cc: sdl.web, emacs-devel > > Perhaps more importantly, there will be fewer (far fewer, > > IMO) new bug reports from Windows users for the latest code. > > > > Instead of a pretest, you will, in effect, just wait until > > after the release to get such bug reports. The purpose > > of the pretest will thus be defeated, except for those > > Windows pretesters who are willing to build Emacs. > > It's not clear what statistics you have to back this up. To back what up? I cited _myself_ as an example. And I have reported a _lot_ of bugs, many of which have been fixed. There will therefore be absolutely fewer (IMO far fewer) bug reports, just counting my own. QED. > I know for a fact that several users of the Windows port > build Emacs themselves; I know that for a fact also. So what? > what percentage that is of the overall number of people who use the > pretest on Windows should be a subject of survey, not guesswork. So go ahead, make such a survey. But check the overall number of Windows pretest _bug reports_ (and the number of such bugs that get fixed, and the number of such bugs that you deem important), not just the number of people who _use_ the Windows pretest. If you limit your check to those who use the Windows pretest, and if no Windows binary is posted, then you've obviously limited your check to those who build Emacs themselves. You will not notice a diminution in _their_ bug reports, obviously. 'Round and 'round you go... [French govt official in the 90s: "Since we stopped listening to the New Caledonian independentists, we no longer hear anything from them."] But even if you do an accurate survey, and you fairly survey the bugs _reported_, not just the number of Windows _users_ of a pretest, and you consider both the number of bug reports and the importance of the bugs reported, a percentage will only give you part of the story. That will indicate a relative loss but not the absolute loss of user feedback. Taking only myself as an example: Even if my bug reports represent a negligible percentage of the total number of Windows bug reports (which I doubt, but which might be the case), they nevertheless represent info that could be useful to Emacs development (that has proven to be the case, in the past). The question is, do you want that info or not? The question still is, "Do you really want bug reports from Windows users?" > FWIW, tools for such a build are readily available, and help for > setting them up is offered here. So I could never understand why > people who want to contribute refuse to install the necessary > development environment. It's not that setting up such a development > environment is hard or needs many hours. There can be many reasons why someone cannot or does not wish to build Emacs. And if building it is so simple, and you have already built the pretest, then why not post your binary of it? Certainly it is at least as easy to post it as to build it, no? What holds you back? "Tools for such a posting are readily available". The purpose of the pretest is only partly to test whether Emacs builds with no problem. And typically you don't need a zillion build reports for the same platform to identify bugs affecting building. You don't need every Emacs pretest tester to build Emacs. The greater purpose of the pretest is to test _Emacs_ itself, after it is built, to see what problems might have been introduced by the latest development changes, 99% of which do not affect building. (No, I don't have statistical evidence for claiming 99%. Sue me.) For that, there is no reason to limit the pretest to those who build Emacs themselves. Especially if you already have a binary available that you can post (which you apparently do have). ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: Next pretest, and branching plans 2010-02-20 18:35 ` Drew Adams @ 2010-02-20 19:49 ` Eli Zaretskii 0 siblings, 0 replies; 48+ messages in thread From: Eli Zaretskii @ 2010-02-20 19:49 UTC (permalink / raw To: Drew Adams; +Cc: sdl.web, emacs-devel > From: "Drew Adams" <drew.adams@oracle.com> > Cc: <sdl.web@gmail.com>, <emacs-devel@gnu.org> > Date: Sat, 20 Feb 2010 10:35:02 -0800 > > > > Perhaps more importantly, there will be fewer (far fewer, > > > IMO) new bug reports from Windows users for the latest code. > > > > > > Instead of a pretest, you will, in effect, just wait until > > > after the release to get such bug reports. The purpose > > > of the pretest will thus be defeated, except for those > > > Windows pretesters who are willing to build Emacs. > > > > It's not clear what statistics you have to back this up. > > To back what up? The claim that the purpose of the pretest will be defeated. > There can be many reasons why someone cannot or does not wish to build Emacs. We are here to help overcome whatever difficulties you have. > And if building it is so simple, and you have already built the pretest, then > why not post your binary of it? Building is simple, but packaging and uploading is not. ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: Next pretest, and branching plans 2010-02-20 17:51 ` Eli Zaretskii 2010-02-20 18:35 ` Drew Adams @ 2010-02-20 18:36 ` Chong Yidong 2010-02-20 18:40 ` Drew Adams 2010-02-20 18:54 ` Lennart Borgman 2010-02-20 19:08 ` Lennart Borgman 2 siblings, 2 replies; 48+ messages in thread From: Chong Yidong @ 2010-02-20 18:36 UTC (permalink / raw To: Eli Zaretskii; +Cc: sdl.web, Drew Adams, emacs-devel Eli Zaretskii <eliz@gnu.org> writes: > It's not clear what statistics you have to back this up. I know for a > fact that several users of the Windows port build Emacs themselves; > what percentage that is of the overall number of people who use the > pretest on Windows should be a subject of survey, not guesswork. > > FWIW, tools for such a build are readily available, and help for > setting them up is offered here. So I could never understand why > people who want to contribute refuse to install the necessary > development environment. It's not that setting up such a development > environment is hard or needs many hours. Anyhow, if anyone would like to volunteer to make binaries for the pretests, please step forward. ^ permalink raw reply [flat|nested] 48+ messages in thread
* RE: Next pretest, and branching plans 2010-02-20 18:36 ` Chong Yidong @ 2010-02-20 18:40 ` Drew Adams 2010-02-20 18:54 ` Lennart Borgman 1 sibling, 0 replies; 48+ messages in thread From: Drew Adams @ 2010-02-20 18:40 UTC (permalink / raw To: 'Chong Yidong', 'Eli Zaretskii'; +Cc: sdl.web, emacs-devel > > It's not clear what statistics you have to back this up. I > > know for a fact that several users of the Windows port build > > Emacs themselves; what percentage that is of the overall > > number of people who use the pretest on Windows should be a > > subject of survey, not guesswork. > > > > FWIW, tools for such a build are readily available, and help for > > setting them up is offered here. So I could never understand why > > people who want to contribute refuse to install the necessary > > development environment. It's not that setting up such a > > development environment is hard or needs many hours. > > Anyhow, if anyone would like to volunteer to make binaries for the > pretests, please step forward. It sounds like you already have lots of people making Windows pretest binaries - Eli knows it for a fact, and I don't doubt it. So what's needed is not a volunteer to make a binary, but a volunteer to post a binary that s?he has already made. ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: Next pretest, and branching plans 2010-02-20 18:36 ` Chong Yidong 2010-02-20 18:40 ` Drew Adams @ 2010-02-20 18:54 ` Lennart Borgman 2010-02-20 19:15 ` Drew Adams 1 sibling, 1 reply; 48+ messages in thread From: Lennart Borgman @ 2010-02-20 18:54 UTC (permalink / raw To: Chong Yidong; +Cc: Eli Zaretskii, sdl.web, Drew Adams, emacs-devel On Sat, Feb 20, 2010 at 7:36 PM, Chong Yidong <cyd@stupidchicken.com> wrote: > Eli Zaretskii <eliz@gnu.org> writes: > >> It's not clear what statistics you have to back this up. I know for a >> fact that several users of the Windows port build Emacs themselves; >> what percentage that is of the overall number of people who use the >> pretest on Windows should be a subject of survey, not guesswork. >> >> FWIW, tools for such a build are readily available, and help for >> setting them up is offered here. So I could never understand why >> people who want to contribute refuse to install the necessary >> development environment. It's not that setting up such a development >> environment is hard or needs many hours. > > Anyhow, if anyone would like to volunteer to make binaries for the > pretests, please step forward. I have not made binaries for the pretest, but since I noticed the request for newer (unpatched) binaries I have uploaded this today to http://ourcomments.org/cgi-bin/emacsw32-dl-latest.pl ^ permalink raw reply [flat|nested] 48+ messages in thread
* RE: Next pretest, and branching plans 2010-02-20 18:54 ` Lennart Borgman @ 2010-02-20 19:15 ` Drew Adams 0 siblings, 0 replies; 48+ messages in thread From: Drew Adams @ 2010-02-20 19:15 UTC (permalink / raw To: 'Lennart Borgman', 'Chong Yidong' Cc: 'Eli Zaretskii', sdl.web, emacs-devel > I have not made binaries for the pretest, but since I noticed the > request for newer (unpatched) binaries I have uploaded this today to > > http://ourcomments.org/cgi-bin/emacsw32-dl-latest.pl Thank you, Lennart. ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: Next pretest, and branching plans 2010-02-20 17:51 ` Eli Zaretskii 2010-02-20 18:35 ` Drew Adams 2010-02-20 18:36 ` Chong Yidong @ 2010-02-20 19:08 ` Lennart Borgman 2 siblings, 0 replies; 48+ messages in thread From: Lennart Borgman @ 2010-02-20 19:08 UTC (permalink / raw To: Eli Zaretskii; +Cc: sdl.web, Drew Adams, emacs-devel On Sat, Feb 20, 2010 at 6:51 PM, Eli Zaretskii <eliz@gnu.org> wrote: > > It's not clear what statistics you have to back this up. I know for a > fact that several users of the Windows port build Emacs themselves; > what percentage that is of the overall number of people who use the > pretest on Windows should be a subject of survey, not guesswork. There actually use to be many people downloading prebuilt binaries from my site (most people prefer my patched version then). But I have not checked how many downloads there are for a very long time. ^ permalink raw reply [flat|nested] 48+ messages in thread
* Emacs Manuals 2010-02-18 11:02 Next pretest, and branching plans Chong Yidong 2010-02-18 15:29 ` Drew Adams @ 2010-02-18 23:57 ` Richard Stallman 2010-02-20 2:46 ` smc 1 sibling, 1 reply; 48+ messages in thread From: Richard Stallman @ 2010-02-18 23:57 UTC (permalink / raw To: Chong Yidong; +Cc: emacs-devel How is progress on updating the Emacs manuals? ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: Emacs Manuals 2010-02-18 23:57 ` Emacs Manuals Richard Stallman @ 2010-02-20 2:46 ` smc 0 siblings, 0 replies; 48+ messages in thread From: smc @ 2010-02-20 2:46 UTC (permalink / raw To: rms; +Cc: Chong Yidong, emacs-devel [-- Attachment #1: Type: text/plain, Size: 552 bytes --] 2010/2/18 Richard Stallman <rms@gnu.org> > How is progress on updating the Emacs manuals? > > > At least, the Spanish versions of the Emacs manuals are very advanced. I want to do a request when updating the original English Emacs manuals: If you change very small pieces of text only for stylistic reasons, don't forget that this means some troubles for us the translators to compare the versions, since many of theses differences are not relevant in our languages. Please, do it only if really really necessary. -- Suso http://gnu.manticore.es [-- Attachment #2: Type: text/html, Size: 911 bytes --] ^ permalink raw reply [flat|nested] 48+ messages in thread
[parent not found: <4B8147A9.7030504@gmail.com>]
[parent not found: <87ljemdzxo.fsf@stupidchicken.com>]
* Re: Next pretest, and branching plans [not found] ` <87ljemdzxo.fsf@stupidchicken.com> @ 2010-02-23 5:31 ` Jason Rumney 2010-02-23 18:29 ` Eli Zaretskii ` (2 more replies) 0 siblings, 3 replies; 48+ messages in thread From: Jason Rumney @ 2010-02-23 5:31 UTC (permalink / raw To: Chong Yidong; +Cc: Christoph, eliz, emacs-devel On 22/02/2010 05:46, Chong Yidong wrote: > Jason, do you think you could down write some instructions? You could > put it at the end of admin/make-tarball.txt, or as its own file in the > admin/ directory. > I don't have access to bzr at the moment, but here are the steps required: 1. Download the source tarball, check signature and unpack. 2. Make sure you have an up to date bzr source tree to use for the admin directory. 3. "make install" to create the bin subdirectory with the appropriate files. 4. Copy libxpm.dll from a previous tarball into the bin directory. 5. Check the file admin/nt/README.W32 (from bzr tree) for necessary changes. 6. Make sure 7z.exe is in your PATH, or modify admin/nt/makedist.bat to use your preferred zip utility (I found that InfoZip zip.exe does not work well, which is why I changed to use 7z.exe) 7. Run admin/nt/makedist.bat. With no args it will give you help on usage. 8. Test the resulting zip files. Then the process of signing and uploading begins. This is documented in the GNU maintainers manual, and is probably the more difficult part of the process, particularly if your internet connection is not fast and stable and uploads get interrupted. ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: Next pretest, and branching plans 2010-02-23 5:31 ` Next pretest, and branching plans Jason Rumney @ 2010-02-23 18:29 ` Eli Zaretskii 2010-02-23 21:12 ` Jason Rumney 2010-02-24 6:04 ` Richard Stallman 2010-03-13 3:10 ` Christoph 2 siblings, 1 reply; 48+ messages in thread From: Eli Zaretskii @ 2010-02-23 18:29 UTC (permalink / raw To: Jason Rumney; +Cc: emacs-devel > Date: Tue, 23 Feb 2010 13:31:25 +0800 > From: Jason Rumney <jasonr@gnu.org> > CC: Christoph <cschol2112@googlemail.com>, eliz@gnu.org, > emacs-devel@gnu.org > > 6. Make sure 7z.exe is in your PATH, or modify admin/nt/makedist.bat to > use your preferred zip utility (I found that InfoZip zip.exe does not > work well, which is why I changed to use 7z.exe) What didn't work well with zip.exe? > 8. Test the resulting zip files. What tests did you usually run? > Then the process of signing and uploading begins. This is documented in > the GNU maintainers manual, and is probably the more difficult part of > the process, particularly if your internet connection is not fast and > stable and uploads get interrupted. It also requires to register a GPG signature, doesn't it? ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: Next pretest, and branching plans 2010-02-23 18:29 ` Eli Zaretskii @ 2010-02-23 21:12 ` Jason Rumney 0 siblings, 0 replies; 48+ messages in thread From: Jason Rumney @ 2010-02-23 21:12 UTC (permalink / raw To: Eli Zaretskii; +Cc: emacs-devel On 24/02/2010 02:29, Eli Zaretskii wrote: >> 6. Make sure 7z.exe is in your PATH, or modify admin/nt/makedist.bat to >> use your preferred zip utility (I found that InfoZip zip.exe does not >> work well, which is why I changed to use 7z.exe) >> > What didn't work well with zip.exe > rem Info-ZIP zip seems to be broken on Windows. rem It always writes to zip.zip and treats the zipfile argument as one rem of the files to go in it. rem zip -9 -r %2-bin-i386 emacs-%1/BUGS emacs-%1/COPYING emacs-%1/README emacs-%1/README.W32 emacs-%1/INSTALL emacs-%1/bin emacs-%1/etc emacs-%1/info emacs-%1/lisp emacs-%1/leim -x emacs.mdp *.pdb *.opt *~ CVS >> 8. Test the resulting zip files. >> > What tests did you usually run? > Test that the unpacked Emacs runs, along with the other exes in the bin directory, and check that the number of files in the zip file is in the same ballpark as the previous version. > It also requires to register a GPG signature, doesn't it? > Yes, your public key needs to be in the GNU keyring to upload to the FTP server. ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: Next pretest, and branching plans 2010-02-23 5:31 ` Next pretest, and branching plans Jason Rumney 2010-02-23 18:29 ` Eli Zaretskii @ 2010-02-24 6:04 ` Richard Stallman 2010-02-24 13:34 ` Sean Sieger 2010-02-24 14:05 ` Chong Yidong 2010-03-13 3:10 ` Christoph 2 siblings, 2 replies; 48+ messages in thread From: Richard Stallman @ 2010-02-24 6:04 UTC (permalink / raw To: Jason Rumney; +Cc: cschol2112, cyd, eliz, emacs-devel Have the manuals been updated? In a release, the manuals should always be up to date. ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: Next pretest, and branching plans 2010-02-24 6:04 ` Richard Stallman @ 2010-02-24 13:34 ` Sean Sieger 2010-02-24 15:05 ` Davis Herring 2010-02-24 14:05 ` Chong Yidong 1 sibling, 1 reply; 48+ messages in thread From: Sean Sieger @ 2010-02-24 13:34 UTC (permalink / raw To: emacs-devel [-- Attachment #1: Type: text/plain, Size: 231 bytes --] Richard Stallman <rms@gnu.org> writes: Have the manuals been updated? In a release, the manuals should always be up to date. I did emacs -Q --eval "(setq Info-default-directory-list '(\".\"))" \ -f info-xref-check-all [-- Attachment #2: manual xrefs --] [-- Type: application/octet-stream, Size: 2217 bytes --] In file /usr/local/texlive/2009/texmf/doc/info/dvips.info: No such node: (kpathsea)Bugs No such node: (kpathsea)unixtex No such node: (kpathsea)Bugs No such node: (kpathsea)Bugs No such node: (kpathsea)Path specifications No such node: (kpathsea)MakeTeX script arguments No such node: (kpathsea)unixtex No such node: (kpathsea)unixtex No such node: (kpathsea)unixtex No such node: (kpathsea)unixtex In file /usr/local/texlive/2009/texmf/doc/info/fontname.info: No such node: (dvips)psfonts In file /usr/local/texlive/2009/texmf/doc/info/kpathsea.info: Not available to check: (fontu) Not available to check: (bash) Not available to check: (autoconf) Not available to check: (coreutils) No such node: (web2c)inimf invocation Not available to check: (gcc) No such node: (web2c)dmp invocation No such node: (web2c)DMP invocation In file /usr/local/texlive/2009/texmf/doc/info/web2c.info: No such node: (kpathsea)unixtex No such node: (kpathsea)Copying No such node: (kpathsea)unixtex No such node: (kpathsea)Bugs Not available to check: (autoconf) Not available to check: (libc) No such node: (kpathsea)unixtex No such node: (dvips)psfonts No such node: (kpathsea)unixtex No such node: (kpathsea)unixtex No such node: (kpathsea)unixtex In file /home/sean/trunk/info/ccmode: Not available to check: (indent) In file /home/sean/trunk/info/eintr: Not available to check: (texinfo) In file /home/sean/trunk/info/elisp: Not available to check: (coreutils) Not available to check: (libc) In file /home/sean/trunk/info/emacs: Not available to check: (aspell) Not available to check: (diff) Not available to check: (make) Not available to check: (gdb) Not available to check: (mailutils) In file /home/sean/trunk/info/epa: Not available to check: (gnupg) In file /home/sean/trunk/info/eudc: Not available to check: (bbdb) In file /home/sean/trunk/info/info: Not available to check: (info-stnd) Not available to check: (texinfo) In file /home/sean/trunk/info/message: Not available to check: (gnupg) In file /home/sean/trunk/info/pgg: Not available to check: (gnupg) In file /home/sean/trunk/info/reftex: Not available to check: (auctex) In file /home/sean/trunk/info/tramp: Not available to check: (bbdb) done, 563 good, 23 bad [-- Attachment #3: Type: text/plain, Size: 50 bytes --] And I'm trying to figure out what to do next ... ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: Next pretest, and branching plans 2010-02-24 13:34 ` Sean Sieger @ 2010-02-24 15:05 ` Davis Herring 2010-02-24 15:18 ` Sean Sieger 0 siblings, 1 reply; 48+ messages in thread From: Davis Herring @ 2010-02-24 15:05 UTC (permalink / raw To: Sean Sieger; +Cc: emacs-devel > And I'm trying to figure out what to do next ... The first 34 lines are unrelated to Emacs. All the error messages that are for Emacs are saying you're missing other Info files (like, say, those for `make') and so it can't check that the cross-references in the Emacs manual point to extant pages in those other manuals. In short, you've not found anything wrong, but there were lots of things you couldn't verify. Davis -- This product is sold by volume, not by mass. If it appears too dense or too sparse, it is because mass-energy conversion has occurred during shipping. ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: Next pretest, and branching plans 2010-02-24 15:05 ` Davis Herring @ 2010-02-24 15:18 ` Sean Sieger 0 siblings, 0 replies; 48+ messages in thread From: Sean Sieger @ 2010-02-24 15:18 UTC (permalink / raw To: emacs-devel The first 34 lines are unrelated to Emacs. All the error messages that are for Emacs are saying you're missing other Info files (like, say, those for `make') and so it can't check that the cross-references in the Emacs manual point to extant pages in those other manuals. In short, you've not found anything wrong, but there were lots of things you couldn't verify. Davis Thank you for your time and thought, Davis. ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: Next pretest, and branching plans 2010-02-24 6:04 ` Richard Stallman 2010-02-24 13:34 ` Sean Sieger @ 2010-02-24 14:05 ` Chong Yidong 2010-02-25 14:26 ` Richard Stallman 2010-02-27 16:52 ` Johan Bockgård 1 sibling, 2 replies; 48+ messages in thread From: Chong Yidong @ 2010-02-24 14:05 UTC (permalink / raw To: rms; +Cc: cschol2112, eliz, emacs-devel, Jason Rumney Richard Stallman <rms@gnu.org> writes: > Have the manuals been updated? In a release, the manuals should always > be up to date. There are still a few items in NEWS that have not yet been documented, but we are mostly there. ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: Next pretest, and branching plans 2010-02-24 14:05 ` Chong Yidong @ 2010-02-25 14:26 ` Richard Stallman 2010-02-27 16:52 ` Johan Bockgård 1 sibling, 0 replies; 48+ messages in thread From: Richard Stallman @ 2010-02-25 14:26 UTC (permalink / raw To: Chong Yidong; +Cc: cschol2112, eliz, emacs-devel, jasonr There are still a few items in NEWS that have not yet been documented, but we are mostly there. To properly update the manuals calls for more than just to document the new features. That is the first step. The next step is to reread the whole text looking for statements that have become outdated or incorrect, and fix them. The next step is to ask other people to do likewise, looking for double coverage. ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: Next pretest, and branching plans 2010-02-24 14:05 ` Chong Yidong 2010-02-25 14:26 ` Richard Stallman @ 2010-02-27 16:52 ` Johan Bockgård 2010-03-03 3:52 ` Glenn Morris 1 sibling, 1 reply; 48+ messages in thread From: Johan Bockgård @ 2010-02-27 16:52 UTC (permalink / raw To: emacs-devel Chong Yidong <cyd@stupidchicken.com> writes: > Richard Stallman <rms@gnu.org> writes: > >> Have the manuals been updated? In a release, the manuals should always >> be up to date. > > There are still a few items in NEWS that have not yet been documented, > but we are mostly there. The Emacs Lisp manual hasn't been updated with 30-bit integers (only the Emacs manual has (max buffer size)). 2.3.1 Integer Type 3.1 Integer Basics 3.8 Bitwise Operations on Integers ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: Next pretest, and branching plans 2010-02-27 16:52 ` Johan Bockgård @ 2010-03-03 3:52 ` Glenn Morris 2010-03-05 0:31 ` Johan Bockgård 0 siblings, 1 reply; 48+ messages in thread From: Glenn Morris @ 2010-03-03 3:52 UTC (permalink / raw To: Johan Bockgård; +Cc: emacs-devel Johan Bockgård wrote: > The Emacs Lisp manual hasn't been updated with 30-bit integers (only the > Emacs manual has (max buffer size)). > > 2.3.1 Integer Type > 3.1 Integer Basics > 3.8 Bitwise Operations on Integers Thanks, I tried to update this. It would be great if you could check it. (Please make a bug report for anything else that is incorrectly marked as having being updated.) ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: Next pretest, and branching plans 2010-03-03 3:52 ` Glenn Morris @ 2010-03-05 0:31 ` Johan Bockgård 0 siblings, 0 replies; 48+ messages in thread From: Johan Bockgård @ 2010-03-05 0:31 UTC (permalink / raw To: emacs-devel Glenn Morris <rgm@gnu.org> writes: > Johan Bockgård wrote: > >> The Emacs Lisp manual hasn't been updated with 30-bit integers (only the >> Emacs manual has (max buffer size)). >> >> 2.3.1 Integer Type >> 3.1 Integer Basics >> 3.8 Bitwise Operations on Integers > > Thanks, I tried to update this. It would be great if you could check it. Looks fine. However, there is another small complication. In 2.3.1 Integer Type: > 1073741825 ; Also the integer 1 on a 30-bit implementation. In 3.1 Integer Basics: > 1073741825 ; Also the integer 1, due to overflow. When in fact (type-of 1073741825) => float! Is this even documented? ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: Next pretest, and branching plans 2010-02-23 5:31 ` Next pretest, and branching plans Jason Rumney 2010-02-23 18:29 ` Eli Zaretskii 2010-02-24 6:04 ` Richard Stallman @ 2010-03-13 3:10 ` Christoph 2010-03-13 7:42 ` Eli Zaretskii 2010-03-13 18:30 ` Stefan Monnier 2 siblings, 2 replies; 48+ messages in thread From: Christoph @ 2010-03-13 3:10 UTC (permalink / raw To: emacs-devel On 2/22/2010 10:31 PM, Jason Rumney wrote: > On 22/02/2010 05:46, Chong Yidong wrote: > >> Jason, do you think you could down write some instructions? You could >> put it at the end of admin/make-tarball.txt, or as its own file in the >> admin/ directory. > > I don't have access to bzr at the moment, but here are the steps > required: > > 3. "make install" to create the bin subdirectory with the appropriate > files. I am trying to package the Windows binaries per Jason's instructions and I was wondering about the make install command on Windows: without specifying a prefix it installs in the current directory but it also does other stuff, for example adding a shortcut to the start menu (by calling addpm.exe). Would it make sense to create a 'make package-install' target that omits these things (if there is other stuff besides the shortcut, that is more intended for a real installation rather than packaging)? When I am packaging I don't want the shortcut created. Or maybe I am just overlooking an obvious way to do this? Thanks, Christoph ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: Next pretest, and branching plans 2010-03-13 3:10 ` Christoph @ 2010-03-13 7:42 ` Eli Zaretskii 2010-03-13 14:54 ` Christoph 2010-03-13 18:30 ` Stefan Monnier 1 sibling, 1 reply; 48+ messages in thread From: Eli Zaretskii @ 2010-03-13 7:42 UTC (permalink / raw To: Christoph; +Cc: emacs-devel > Date: Fri, 12 Mar 2010 20:10:09 -0700 > From: Christoph <cschol2112@googlemail.com> > > I am trying to package the Windows binaries per Jason's instructions and > I was wondering about the make install command on Windows: without > specifying a prefix it installs in the current directory but it also > does other stuff, for example adding a shortcut to the start menu (by > calling addpm.exe). I think "make install" does that even if you do specify the directory to install in. > Would it make sense to create a 'make package-install' target that omits > these things (if there is other stuff besides the shortcut, that is more > intended for a real installation rather than packaging)? When I am > packaging I don't want the shortcut created. Patches are welcome. While at that, perhaps have that package-install target run the admin/nt/makedist.bat automatically. ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: Next pretest, and branching plans 2010-03-13 7:42 ` Eli Zaretskii @ 2010-03-13 14:54 ` Christoph 0 siblings, 0 replies; 48+ messages in thread From: Christoph @ 2010-03-13 14:54 UTC (permalink / raw To: Eli Zaretskii; +Cc: emacs-devel On 3/13/2010 12:42 AM, Eli Zaretskii wrote: >> Would it make sense to create a 'make package-install' target that omits >> these things (if there is other stuff besides the shortcut, that is more >> intended for a real installation rather than packaging)? When I am >> packaging I don't want the shortcut created. >> > Patches are welcome. While at that, perhaps have that package-install > target run the admin/nt/makedist.bat automatically. > Sounds good, I will take a stab at that. Thanks, Christoph ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: Next pretest, and branching plans 2010-03-13 3:10 ` Christoph 2010-03-13 7:42 ` Eli Zaretskii @ 2010-03-13 18:30 ` Stefan Monnier 2010-03-13 19:06 ` Eli Zaretskii 2010-03-14 2:38 ` Jason Rumney 1 sibling, 2 replies; 48+ messages in thread From: Stefan Monnier @ 2010-03-13 18:30 UTC (permalink / raw To: Christoph; +Cc: emacs-devel > Would it make sense to create a 'make package-install' target that omits > these things (if there is other stuff besides the shortcut, that is more > intended for a real installation rather than packaging)? When I am packaging > I don't want the shortcut created. To me at least, the name "package-install" would not be helpful. Something like "install_files_only" would sound more meaningful (or "install_for_packaging", or ...). Stefan ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: Next pretest, and branching plans 2010-03-13 18:30 ` Stefan Monnier @ 2010-03-13 19:06 ` Eli Zaretskii 2010-03-14 2:38 ` Jason Rumney 1 sibling, 0 replies; 48+ messages in thread From: Eli Zaretskii @ 2010-03-13 19:06 UTC (permalink / raw To: Stefan Monnier; +Cc: cschol2112, emacs-devel > From: Stefan Monnier <monnier@iro.umontreal.ca> > Date: Sat, 13 Mar 2010 13:30:28 -0500 > Cc: emacs-devel@gnu.org > > > Would it make sense to create a 'make package-install' target that omits > > these things (if there is other stuff besides the shortcut, that is more > > intended for a real installation rather than packaging)? When I am packaging > > I don't want the shortcut created. > > To me at least, the name "package-install" would not be helpful. > Something like "install_files_only" would sound more meaningful (or > "install_for_packaging", or ...). I suggest "dist", like in the top-level Makefile.in. There's no need for this target without actually producing the binary zip file, so it should run the makedist.bat script as part of its job. ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: Next pretest, and branching plans 2010-03-13 18:30 ` Stefan Monnier 2010-03-13 19:06 ` Eli Zaretskii @ 2010-03-14 2:38 ` Jason Rumney 2010-03-14 2:50 ` Christoph 1 sibling, 1 reply; 48+ messages in thread From: Jason Rumney @ 2010-03-14 2:38 UTC (permalink / raw To: Stefan Monnier; +Cc: Christoph, emacs-devel Stefan Monnier <monnier@iro.umontreal.ca> writes: >> Would it make sense to create a 'make package-install' target that omits >> these things (if there is other stuff besides the shortcut, that is more >> intended for a real installation rather than packaging)? When I am packaging >> I don't want the shortcut created. > > To me at least, the name "package-install" would not be helpful. > Something like "install_files_only" would sound more meaningful (or > "install_for_packaging", or ...). My preference would be for make install to install the files only, and a new rule for making shortcuts (install_icons). Most people who build from source on Windows are probably building in the same location all the time, so they don't always need to replace the shortcut. And if they have multiple versions installed, they will want to maintain the shortcut icons manually to avoid having all the versions overwrite each other. ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: Next pretest, and branching plans 2010-03-14 2:38 ` Jason Rumney @ 2010-03-14 2:50 ` Christoph 2010-03-14 3:07 ` Jason Rumney 2010-03-14 17:55 ` Eli Zaretskii 0 siblings, 2 replies; 48+ messages in thread From: Christoph @ 2010-03-14 2:50 UTC (permalink / raw To: Jason Rumney; +Cc: Stefan Monnier, emacs-devel On 3/13/2010 7:38 PM, Jason Rumney wrote: > Stefan Monnier<monnier@iro.umontreal.ca> writes: > >>> Would it make sense to create a 'make package-install' target that omits >>> these things (if there is other stuff besides the shortcut, that is more >>> intended for a real installation rather than packaging)? When I am packaging >>> I don't want the shortcut created. >>> >> To me at least, the name "package-install" would not be helpful. >> Something like "install_files_only" would sound more meaningful (or >> "install_for_packaging", or ...). >> > My preference would be for make install to install the files only, and a > new rule for making shortcuts (install_icons). > > Most people who build from source on Windows are probably building in > the same location all the time, so they don't always need to replace the > shortcut. And if they have multiple versions installed, they will want > to maintain the shortcut icons manually to avoid having all the versions > overwrite each other. > For packaging, a make dist rule would also need to copy the dist files (libXpm.dll for example) before invoking makedist.bat to really automate the entire process. I agree with you, Jason, that installing shortcuts should be a separate step and not the included in the normal make install (for pretty much the same reasons you pointed out). But that to me, is a separate issue from packaging. I went ahead and implemented the following so far in my local branch: - added an option "--distfiles [path to file, for example libXpm.dll]" to configure.bat. Adding those external binaries was the only manual step left in the process and can also be automated now. - added build target 'dist' to makefile.w32-in. It basically does a 'make install' without creating shortcuts, copies the distfiles, i.e. the libXpm.dll to the bin directory and then calls 'makedist.bat' to create the zip file for distribution. One problem is that calling makedist.bat means a dependency on the trunk, since it is not available in the source tarball. Can we add the /admin/nt directory and its contents to the source tarball? Or move the files to ../nt? Then, the 'make dist' target would be able to create a zip from just the tarball, without having to have the trunk available. But since the directory structure is the same, running 'make dist' would also work in the trunk itself to easily create binary snapshots of the trunk. The makedist.bat needs to be changed a little because it expects the files to be in a folder emacs-xx.x.xx as they are in the tarball, but that is a trivial change change to make it more generic and automated. Also, is there any way to get the version number from a file contained in the source tar ball? Then make dist would always output a zip file properly named according to the current version. Any thoughts? Christoph ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: Next pretest, and branching plans 2010-03-14 2:50 ` Christoph @ 2010-03-14 3:07 ` Jason Rumney 2010-03-14 17:55 ` Eli Zaretskii 1 sibling, 0 replies; 48+ messages in thread From: Jason Rumney @ 2010-03-14 3:07 UTC (permalink / raw To: Christoph; +Cc: Stefan Monnier, emacs-devel Christoph <cschol2112@googlemail.com> writes: > One problem is that calling makedist.bat means a dependency on the > trunk, since it is not available in the source tarball. Can we add the > /admin/nt directory and its contents to the source tarball? Or move > the files to ../nt? Then, the 'make dist' target would be able to > create a zip from just the tarball, without having to have the trunk > available. But since the directory structure is the same, running > make dist' would also work in the trunk itself to easily create binary > snapshots of the trunk. Moving the files to the top level nt subdirectory would be OK. > Also, is there any way to get the version number from a file contained > in the source tar ball? Then make dist would always output a zip file > properly named according to the current version. The lib-src makefile contains the version number on Windows. You could update admin/admin.el if you want to move this to nt/makefile. ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: Next pretest, and branching plans 2010-03-14 2:50 ` Christoph 2010-03-14 3:07 ` Jason Rumney @ 2010-03-14 17:55 ` Eli Zaretskii 2010-03-17 0:29 ` Christoph 1 sibling, 1 reply; 48+ messages in thread From: Eli Zaretskii @ 2010-03-14 17:55 UTC (permalink / raw To: Christoph; +Cc: emacs-devel, monnier, jasonr > Date: Sat, 13 Mar 2010 19:50:30 -0700 > From: Christoph <cschol2112@googlemail.com> > Cc: Stefan Monnier <monnier@iro.umontreal.ca>, emacs-devel@gnu.org > > - added an option "--distfiles [path to file, for example libXpm.dll]" > to configure.bat. That's gratuitous, I think: modern Windows shells are powerful enough to let you write a FOR loop looking for libXpm.dll along PATH. > Also, is there any way to get the version number from a file contained > in the source tar ball? Then make dist would always output a zip file > properly named according to the current version. Again, one of the variants of the FOR command should do the trick. ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: Next pretest, and branching plans 2010-03-14 17:55 ` Eli Zaretskii @ 2010-03-17 0:29 ` Christoph 2010-03-17 4:14 ` Eli Zaretskii 0 siblings, 1 reply; 48+ messages in thread From: Christoph @ 2010-03-17 0:29 UTC (permalink / raw To: Eli Zaretskii; +Cc: emacs-devel, monnier, jasonr On 3/14/2010 11:55 AM, Eli Zaretskii wrote: >> Date: Sat, 13 Mar 2010 19:50:30 -0700 >> From: Christoph<cschol2112@googlemail.com> >> Cc: Stefan Monnier<monnier@iro.umontreal.ca>, emacs-devel@gnu.org >> >> - added an option "--distfiles [path to file, for example libXpm.dll]" >> to configure.bat. >> > That's gratuitous, I think: modern Windows shells are powerful enough > to let you write a FOR loop looking for libXpm.dll along PATH. > This assumes that libXpm.dll is actually somwhere on the PATH, which it might or might not be (and I might not put it on the path). I think the command line option for configure.bat is way more flexible for one's individual build environment, plus who knows, maybe I want to also package libSvg.dll or libWhatever.dll. Now I can do this without having to change the code. >> Also, is there any way to get the version number from a file contained >> in the source tar ball? Then make dist would always output a zip file >> properly named according to the current version. >> > Again, one of the variants of the FOR command should do the trick. > Could you elaborate on this solution? Thanks! Christoph PS: As for the "powerful Windows shells"...not before Windows 7 (or Vista?) with Powershell did Windows ever have a powerful shell... ;) ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: Next pretest, and branching plans 2010-03-17 0:29 ` Christoph @ 2010-03-17 4:14 ` Eli Zaretskii 2010-03-17 12:44 ` Jason Rumney 0 siblings, 1 reply; 48+ messages in thread From: Eli Zaretskii @ 2010-03-17 4:14 UTC (permalink / raw To: Christoph; +Cc: jasonr, monnier, emacs-devel > Date: Tue, 16 Mar 2010 18:29:17 -0600 > From: Christoph <cschol2112@googlemail.com> > Cc: emacs-devel@gnu.org, monnier@iro.umontreal.ca, jasonr@gnu.org > > >> - added an option "--distfiles [path to file, for example libXpm.dll]" > >> to configure.bat. > >> > > That's gratuitous, I think: modern Windows shells are powerful enough > > to let you write a FOR loop looking for libXpm.dll along PATH. > > > This assumes that libXpm.dll is actually somwhere on the PATH, which it > might or might not be (and I might not put it on the path). If it's not on PATH, it's in the directory where you have the Emacs binary. > I think the > command line option for configure.bat is way more flexible for one's > individual build environment Yes, but flexibility comes at a price: one needs _always_ to type that argument. Why impose this inconvenience on the user? > >> Also, is there any way to get the version number from a file contained > >> in the source tar ball? Then make dist would always output a zip file > >> properly named according to the current version. > >> > > Again, one of the variants of the FOR command should do the trick. > > > Could you elaborate on this solution? Thanks! Type "for /?" from the cmd prompt, and read there, especially about "for /f". It's too long to post that info here. > PS: As for the "powerful Windows shells"...not before Windows 7 (or > Vista?) with Powershell did Windows ever have a powerful shell... ;) I was talking about cmd, not about Powershell. ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: Next pretest, and branching plans 2010-03-17 4:14 ` Eli Zaretskii @ 2010-03-17 12:44 ` Jason Rumney 0 siblings, 0 replies; 48+ messages in thread From: Jason Rumney @ 2010-03-17 12:44 UTC (permalink / raw To: Eli Zaretskii; +Cc: Christoph, monnier, emacs-devel Eli Zaretskii <eliz@gnu.org> writes: > If it's not on PATH, it's in the directory where you have the Emacs > binary. Well, no. The directory where he has the Emacs binary has just been created via make install, so it doesn't contain any files that are not part of Emacs. > Yes, but flexibility comes at a price: one needs _always_ to type that > argument. Why impose this inconvenience on the user? The make target Christoph is creating is for packaging Emacs. Most users will have no need to use it. ^ permalink raw reply [flat|nested] 48+ messages in thread
end of thread, other threads:[~2010-03-17 12:44 UTC | newest] Thread overview: 48+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2010-02-18 11:02 Next pretest, and branching plans Chong Yidong 2010-02-18 15:29 ` Drew Adams 2010-02-20 12:25 ` Leo 2010-02-20 13:05 ` Sean Sieger 2010-02-20 17:02 ` Drew Adams 2010-02-28 12:36 ` Sean Sieger 2010-02-28 15:13 ` Lennart Borgman 2010-02-20 16:52 ` Drew Adams 2010-02-20 17:35 ` Drew Adams 2010-02-20 19:45 ` Eli Zaretskii 2010-02-20 20:39 ` Drew Adams 2010-02-20 20:53 ` Lennart Borgman 2010-02-21 0:11 ` Lennart Borgman 2010-02-21 4:11 ` Eli Zaretskii 2010-02-20 17:51 ` Eli Zaretskii 2010-02-20 18:35 ` Drew Adams 2010-02-20 19:49 ` Eli Zaretskii 2010-02-20 18:36 ` Chong Yidong 2010-02-20 18:40 ` Drew Adams 2010-02-20 18:54 ` Lennart Borgman 2010-02-20 19:15 ` Drew Adams 2010-02-20 19:08 ` Lennart Borgman 2010-02-18 23:57 ` Emacs Manuals Richard Stallman 2010-02-20 2:46 ` smc [not found] <4B8147A9.7030504@gmail.com> [not found] ` <87ljemdzxo.fsf@stupidchicken.com> 2010-02-23 5:31 ` Next pretest, and branching plans Jason Rumney 2010-02-23 18:29 ` Eli Zaretskii 2010-02-23 21:12 ` Jason Rumney 2010-02-24 6:04 ` Richard Stallman 2010-02-24 13:34 ` Sean Sieger 2010-02-24 15:05 ` Davis Herring 2010-02-24 15:18 ` Sean Sieger 2010-02-24 14:05 ` Chong Yidong 2010-02-25 14:26 ` Richard Stallman 2010-02-27 16:52 ` Johan Bockgård 2010-03-03 3:52 ` Glenn Morris 2010-03-05 0:31 ` Johan Bockgård 2010-03-13 3:10 ` Christoph 2010-03-13 7:42 ` Eli Zaretskii 2010-03-13 14:54 ` Christoph 2010-03-13 18:30 ` Stefan Monnier 2010-03-13 19:06 ` Eli Zaretskii 2010-03-14 2:38 ` Jason Rumney 2010-03-14 2:50 ` Christoph 2010-03-14 3:07 ` Jason Rumney 2010-03-14 17:55 ` Eli Zaretskii 2010-03-17 0:29 ` Christoph 2010-03-17 4:14 ` Eli Zaretskii 2010-03-17 12:44 ` Jason Rumney
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.