Re: [Geany-devel] Remove MSYS dependency of Geany on Win~1
On Thu, 28 Jun 2012 14:41:25 +0100 Nick Treleaven wrote: > Yes, using a target for plugins only would be OK. What if we put the an install: target in plugins/makefile.win32? That works, needs no DIRSEP, and is very similar to the *nix installation. To avoid 'C:/Program Files/Geany already exists' on the first install, we will have to use mkdir -p, but that's the default behaviour of the cmd/tcc mkdir anyway. Attached, and the patch is git-ified this time. BTW (not included in the .diff): 'CP = copy' in doc/Makefile.win32 should be 'copy /Y'. 'MAKE =' seems unneeded, any GNU make defines is automatically. >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 I thought of providing a sample localwin32.msys with the standard MSYS definitions. In all cases, -include localwin32.mk should be the last, to allow overriding. > 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. Then all clean: targets will fail when run from a subdirectory (and the above install: when run from plugins/). So 'make all' in src/ will work, but not 'make clean'. Hmmm... > > I will. While unlikely, I'll check if 'xcopy /y plugins/*.dll ...' > > works. > > I tried that here and it failed. Same here. > >> 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). Same here. Gee. > > But it doesn't really run the SHELL, just attempts to CreateProcess > > (copy, ...) because a SHELL is defined. [...] > > 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... Well, there are 2 standard ways to run an executable-or-interpreter- command under Win~1, and both are not very good. GNU make attempts to do that "better", going as far as supporting a list of the internal CMD/4NT/TCC commands, and tries to support *nix shells at the same time. The old GNU make version from UnxUtils.zip is the same, so it's not exactly MinGW - more likely the 'stock' (non-MSYS, non-Cygwin) GNU Make for Win~1. > >> 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. (GNU)mingw32-make-3.82-5. Obviously treats \ different, since it's not an escape in C:\foo\bar. Anyway, STLIBS is a safe bet. -- E-gards: Jimmy diff --git a/makefile.win32 b/makefile.win32 index 1add16c..4f701c9 100644 --- a/makefile.win32 +++ b/makefile.win32 @@ -10,7 +10,7 @@ # Use localwin32.mk instead of editing variables as it is included in sub # makefiles. # E.g. use localwin32.mk to set PREFIX=C:/libs instead of the default C:\libs -# For MSYS use localwin32.mk to set CP, CP_R, RM, DIRSEP. +# For MSYS use localwin32.mk to set CP, CP_R, RM and MKDIR_P. # By default this should work in a Windows command prompt (cmd.exe). WINDRES = windres.exe @@ -19,9 +19,7 @@ CXX = g++ CP = copy /Y CP_R = xcopy /S /Y RM = del -MKDIR = mkdir -# strip is used to prevent line wrap -DIRSEP := $(strip \) +MKDIR_P = mkdir DESTDIR = C:/Program Files/Geany -include localwin32.mk @@ -55,10 +53,8 @@ clean: deps # mkdir output is ignored in case dir exists # 'copy' seems to only accept / in the destination install: - -$(MKDIR) "$(DESTDIR)" - -$(MKDIR) "$(DESTDIR)/bin" + -$(MKDIR_P) "$(DESTDIR)/bin" $(CP) geany.exe "$(DESTDIR)/bin" - -$(MKDIR) "$(DESTDIR)/lib" - $(CP) plugins$(DIRSEP)*.dll "$(DESTDIR)/lib" - -$(MKDIR) "$(DESTDIR)/data" + make -C plugins -f makefile.win32 install + -$(MKDIR_P) "$(DESTDIR)/data" $(CP_R) data "$(DESTDIR)/data" diff --git a/plugins/makefile.win32 b/plugins/makefile.win32 index 4f2e5da..435f6ae 100644 --- a/plugins/makefile.win32 +++ b/plugins/makefile.win32 @@ -3,7 +3,10 @@ CC = gcc CXX = g++ PREFIX = C:\libs +CP = copy /Y RM = del +MKDIR_P = mkdir +DESTDIR = C:/Program Files/Geany -include ../localwin32.mk .SUFFIXES: .SUFFIXES: .c .o .dll @@ -43,7 +46,7 @@ ifndef GTK210 ALL_GTK_LIBS += -liconv endif -.PHONY: all clean plugins +.PHONY: all clean plugins install all: plugins @@ -66,6
Re: [Geany-devel] Remove MSYS dependency of Geany on Win~1
On Thu, 28 Jun 2012 16:28:50 +0200 Thomas Martitz wrote: > Am 28.06.2012 15:41, schrieb Nick Treleaven: > > > > 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. > > Make variables are survive recursive invocations don't they? Not that I know of. Do a ./configure or ./autoges, and look at ./Makefile and src/Makefile. -- E-gards: Jimmy ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Remove MSYS dependency of Geany on Win~1
Am 28.06.2012 16:30, schrieb Nick Treleaven: On 28/06/2012 15:28, Thomas Martitz wrote: Am 28.06.2012 15:41, schrieb Nick Treleaven: -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. Make variables are survive recursive invocations don't they? Not sure what you mean. Passing CP="$(CP)" is reduntant because the sub-makefile inherits the value of CP. Best regards ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Remove MSYS dependency of Geany on Win~1
On 28/06/2012 15:28, Thomas Martitz wrote: Am 28.06.2012 15:41, schrieb Nick Treleaven: -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. Make variables are survive recursive invocations don't they? Not sure what you mean. ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Remove MSYS dependency of Geany on Win~1
Am 28.06.2012 15:41, schrieb Nick Treleaven: -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. Make variables are survive recursive invocations don't they? Best regards ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Remove MSYS dependency of Geany on Win~1
On 27/06/2012 21:32, Dimitar Zhekov wrote: On Tue, 26 Jun 2012 21:21:57 +0100 Nick Treleaven 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 ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
