Re: [build_w32.bat] feature request: add optional command line argument for executable name

[Paul Smith]

On Fri, 2019-11-15 at 15:52 +0200, Eli Zaretskii wrote:
> Ping!  Paul, did you have a chance to look at this issue?

Sorry, I'm quite underwater.  I hope to be able to do a bit of make work
over the next few weeks: get out a final RC and a release.

For this, I don't really understand the issue :).  What is the import
library used for?  Make is an executable, right?  Are we talking about
creating loadable objects here?

I have no preferences for filenames whatsoever: I used whatever was there
before.  I admit I find it a bit annoying that the .bat file creates a
differently-named executable in a subdirectory, because I always forget and
have to re-remember it when running tests, but I leave these decisions up
to the folks who actually use Windows.

The extent of my usage is just making sure that it compiles and runs on
Windows with MSVC since that's what I have access to.

So upshot is: whatever you guys feel is right is just fine with me :).


> > Date: Thu, 07 Nov 2019 17:29:48 +0200
> > From: Eli Zaretskii <address@hidden>
> > Cc: address@hidden
> > 
> > > From: "Jannick" <address@hidden>
> > > Cc: <address@hidden>
> > > Date: Thu, 7 Nov 2019 12:32:23 +0100
> > > 
> > > Subject: [PATCH 03/13] Windows build: add optional cmd line flag --
> > > exe-name to build_w32.bat
> > > 
> > > This commit helps the user choose a name for the GNUMake executable
> > > different from the default 'gnumake.exe' used at link time.
> > 
> > This patches only the GCC part of the script.  Does that mean the MSVC
> > part already caters to your use case in some way?
> > 
> > Paul, I think we have a situation here, most probably my fault.
> > Currently, we produce the executable named gnumake.exe, but we install
> > it as something else, like make.exe, which means the importy library
> > will not work, because the name gnumake.exe is hard-coded in the
> > import library when we build it.  I think I failed to consider this
> > aspect when I implemented the Windows support of shared object
> > loading.
> > 
> > Does the same problem exist with the MSVC builds?  If not, how this
> > issue is resolved in that case?
> > 
> > One solution of this would be to also build a DEF file, and tell users
> > to edit the name of the executable in that file and then create an
> > import library from the DEF file using dlltool, if they rename the
> > executable.
> > 
> > Another solution is the 3rd patch sent by Jannick, but I like his
> > solution less because it doesn't allow to rename the executable after
> > it is built.
> > 
> > WDYT?