[Geany-devel] Remove MSYS dependency of Geany on Win~1

[Nick Treleaven]

On 27/06/2012 21:32, Dimitar Zhekov wrote:
> On Tue, 26 Jun 2012 21:21:57 +0100
> Nick Treleaven<nick.treleaven at btinternet.com>  wrote:
>> I've now committed to master an install target similar to your first
>> patch, but using xcopy for data. I used a DIRSEP variable:
>>
>> $(CP) plugins$(DIRSEP)*.dll "$(DESTDIR)/lib"
>
> A make -C install-plugins will work without DIRSEP. Not ellegant, I'll
> be the first to admit - but supporting a directory separator variable
> specifically for a single command, when we can easily do without it,
> doesn't seem very pretty to me either.

Yes, using a target for plugins only would be OK. But I'm thinking of 
adding a MSYS variable now to make it easier:

-include localwin32.mk
ifdef MSYS
CP = cp
CP_R = cp -r
RM = rm
DIRSEP = /
endif

And then perhaps use $(MAKE) CP="$(CP)" RM="$(RM)" to pass these 
variables to the sub-makefiles so they don't need to have copies of the 
ifdef. They only need CP and RM.

>> Please test.
>
> I will. While unlikely, I'll check if 'xcopy /y plugins/*.dll ...'
> works.

I tried that here and it failed.

>> I think because 'copy' takes /y switches the first path it sees must not
>> use forward slashes. They are OK in the destination though.
>
> Or maybe the forward slashes work with copy if the argument matches an
> existing path exactly, without find first/next file involved. Not that
> knowing the reason will help us.

No, even full paths with forward slash do not work (at least for the 
first of the file arguments).

>>> Note that using a cmd-style shell with SHELL defined to a *nix style
>>> shell fails, no matter if makefile.win32 is patched or not. That's a
>>> problem of GNU make under Win~1 trying to be too smart, and ending up
>>> with things like "CreateProcess (copy, ...) error 2". :)
>>
>> I don't get the last part above, but I think this is by design:
>>
>> "The program used as the shell is taken from the variable SHELL. If this
>> variable is not set in your makefile, the program /bin/sh is used as the
>> shell. [...]
>
> But it doesn't really run the SHELL, just attempts to CreateProcess
> (copy, ...) because a SHELL is defined. Anyway, I only wanted to make
> it clear than in such (rare) configuration, mingw32-make is unlikely to
> work at all: any cmd command (mkdir, del) will be started directly as
> executable, and of course fail. xcopy should work though.

It is weird that (without overriding on the command line) SHELL always 
is sh.exe, even when cmd.exe is obviously being used. Maybe a MinGW 
issue. It is as described in the manual, but why use cmd.exe then...

>> Also, I think you /can/ join command lines with a trailing backslash
>> (but your patch change is still better to have STLIBS anyway):
>> http://www.gnu.org/software/make/manual/html_node/Splitting-Lines.html
>
> It failed on my mingw32-make, I wound't have bothered if it worked.

It seemed to work for me, and the manual seems to say that GNU make 
interprets the trailing backslash, it doesn't pass it to the shell.

I have GNU Make 3.82. YMMV.

Regards,
Nick