From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Christoph Newsgroups: gmane.emacs.devel Subject: Re: Next pretest, and branching plans Date: Sat, 13 Mar 2010 19:50:30 -0700 Message-ID: <4B9C4EF6.3010006@gmail.com> References: <4B8147A9.7030504@gmail.com> <87ljemdzxo.fsf@stupidchicken.com> <4B83682D.5010804@gnu.org> <4B9B0211.9070308@gmail.com> <87pr37y6de.fsf@home.jasonrumney.net> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1268538812 4943 80.91.229.12 (14 Mar 2010 03:53:32 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 14 Mar 2010 03:53:32 +0000 (UTC) Cc: Stefan Monnier , emacs-devel@gnu.org To: Jason Rumney Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Mar 14 04:53:28 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1NqetL-0002xO-Cs for ged-emacs-devel@m.gmane.org; Sun, 14 Mar 2010 04:53:27 +0100 Original-Received: from localhost ([127.0.0.1]:47637 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NqetL-0004uD-2x for ged-emacs-devel@m.gmane.org; Sat, 13 Mar 2010 22:53:27 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Nqduc-0002f2-5a for emacs-devel@gnu.org; Sat, 13 Mar 2010 21:50:42 -0500 Original-Received: from [140.186.70.92] (port=56244 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NqduZ-0002ek-PD for emacs-devel@gnu.org; Sat, 13 Mar 2010 21:50:40 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1NqduX-0004m6-Fc for emacs-devel@gnu.org; Sat, 13 Mar 2010 21:50:39 -0500 Original-Received: from mail-px0-f204.google.com ([209.85.216.204]:55614) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NqduV-0004ls-KN; Sat, 13 Mar 2010 21:50:35 -0500 Original-Received: by pxi42 with SMTP id 42so857709pxi.26 for ; Sat, 13 Mar 2010 18:50:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=dxfTd7fIVg4i3vxi5LD17vx/DSgfFoDyBGyqDvBcEPI=; b=OLji3wpXl4ABsnB4TdRWuaBuMxKcsf/eDMBgV/8CCqkGS2AoOKt3D0G/jG+UJFI8UU /b/AyfsM+e/NDrauipYhWrh8jmUQcMR9HPUw/SYgVyePgZd6G1GbzM9CKrVdW9wzsmSR /73kPP+WqOLuObvm52qbM1/qaeQN0F0Hwbplg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=LqAmH83N/naStTT0CbBOIuCqg0iQOKn3KmYpywIHcnk93kiBKs6hlHyJzgruR0i4xl GdYGYmOptRWLyKe6G26vcDcyOCFw6duMQd84VTwcl5P/QrI1Qzv4Y6CHwqpCw2p5RzW+ 9JHmSNoPmS0DUcwgl5IvbvUlyW2Vg40O5vB64= Original-Received: by 10.141.90.5 with SMTP id s5mr4508514rvl.81.1268535034428; Sat, 13 Mar 2010 18:50:34 -0800 (PST) Original-Received: from [192.168.1.2] (67-41-153-183.hlrn.qwest.net [67.41.153.183]) by mx.google.com with ESMTPS id 20sm3624787pzk.11.2010.03.13.18.50.32 (version=SSLv3 cipher=RC4-MD5); Sat, 13 Mar 2010 18:50:33 -0800 (PST) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 In-Reply-To: <87pr37y6de.fsf@home.jasonrumney.net> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Mailman-Approved-At: Sat, 13 Mar 2010 22:50:29 -0500 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:121935 Archived-At: On 3/13/2010 7:38 PM, Jason Rumney wrote: > Stefan Monnier 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