Re: Next pretest, and branching plans

[Christoph]

On 3/13/2010 7:38 PM, Jason Rumney wrote:
> Stefan Monnier<address@hidden>  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