On Tue, 26 Jun 2012 21:21:57 +0100 Nick Treleaven <[email protected]> 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. -- E-gards: Jimmy _______________________________________________ Geany-devel mailing list [email protected] https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
