On Tue, 26 Jun 2012 21:21:57 +0100 Nick Treleaven nick.treleaven@btinternet.com wrote:
I can now apply the -b version, but I had to add 'src/' to the second file in the diff - are you manually concatenating diffs?
Yes; the 2nd file lacked 'src/', sorry.
Wouldn't it be better to use 'git diff'?
My Win~1 tools are very limited, git is not among them, and I didn't dare to run a linux 'git diff' on an NTFS path.
I still don't think separate targets is acceptable though. I can at least apply the rest of the patch though.
BTW you missed data/templates/files. Wouldn't using a single xcopy be more sensible to reduce bugs and maintenance?
Probably. I wanted to stick with a single CP for copying, but ended up with something stupid.
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.
Please test.
I will. While unlikely, I'll check if 'xcopy /y plugins/*.dll ...' works.
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.
--
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.
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.