Hi,
Now that 1.22 is out, how about removing the MSYS build dependency under Win~1? I tried to compile Geany with the default MinGW make, without any MSYS, and there were some easily fixable problems:
cd foo && $(MAKE) -f makefile.win32 && cd ....
does not work, probably requires some sh. But if we depend on GNU make (which seems to be the case, since we're using ifdef/else/endif), it's easier and shorter to:
$(MAKE) -C foo -f makefile.win32
Linking does not work, because the stock make supports \ only for variables, not commands. But that's even easier to fix:
STLIBS = ../scintilla/scintilla.a ../tagmanager/tagmanager.a ../tagmanager/mio/mio.a
$(TARGET): $(OBJS) $(RES) $(STLIBS) $(CXX) $(OBJS) $(RES) -o $(TARGET) $(STLIBS) $(ALL_GTK_LIBS) $(WIN_LIBS)
with the added benefit that static library names are not repeated literally.
There is also some inconsistency: CP = copy, but "cp -r" and "cp" at the end of makefile. The install target can be rewritten as several -$(MD) and non-recursive $(CP) commands, and no MSYS will be required.
RFC. If we consider this worthy, I can make the required changes.
On 12-06-19 10:12 AM, Dimitar Zhekov wrote:
Hi,
Now that 1.22 is out, how about removing the MSYS build dependency under Win~1? I tried to compile Geany with the default MinGW make, without any MSYS, and there were some easily fixable problems:
cd foo&& $(MAKE) -f makefile.win32&& cd ....
does not work, probably requires some sh. But if we depend on GNU make (which seems to be the case, since we're using ifdef/else/endif), it's easier and shorter to:
$(MAKE) -C foo -f makefile.win32
Linking does not work, because the stock make supports \ only for variables, not commands. But that's even easier to fix:
STLIBS = ../scintilla/scintilla.a ../tagmanager/tagmanager.a ../tagmanager/mio/mio.a
$(TARGET): $(OBJS) $(RES) $(STLIBS) $(CXX) $(OBJS) $(RES) -o $(TARGET) $(STLIBS) $(ALL_GTK_LIBS) $(WIN_LIBS)
with the added benefit that static library names are not repeated literally.
There is also some inconsistency: CP = copy, but "cp -r" and "cp" at the end of makefile. The install target can be rewritten as several -$(MD) and non-recursive $(CP) commands, and no MSYS will be required.
RFC. If we consider this worthy, I can make the required changes.
I have started working on this before: https://gist.github.com/1494603
It builds but isn't perfect, like it doesn't do the icon/resource stuff, and doesn't use win32-conf.h properly, but it might be useful for a starting point. It's what I use for testing Geany on Windows.
Cheers, Matthew Brush
On Tue, 19 Jun 2012 14:25:11 -0700 Matthew Brush mbrush@codebrainz.ca wrote:
On 12-06-19 10:12 AM, Dimitar Zhekov wrote:
Hi,
Now that 1.22 is out, how about removing the MSYS build dependency under Win~1? I tried to compile Geany with the default MinGW make, without any MSYS, and there were some easily fixable problems: [...]
I have started working on this before: https://gist.github.com/1494603
It builds but isn't perfect, like it doesn't do the icon/resource stuff, and doesn't use win32-conf.h properly, but it might be useful for a starting point. It's what I use for testing Geany on Windows.
That looks like an entirely new makefile. I was able to compile Geany with small (msys compatible) changes in the existing makefiles, and setting MAKE to mingw32-make in localwin32.mk...
On 19/06/2012 22:25, Matthew Brush wrote:
On 12-06-19 10:12 AM, Dimitar Zhekov wrote:
Hi,
Now that 1.22 is out, how about removing the MSYS build dependency under Win~1? I tried to compile Geany with the default MinGW make, without any MSYS, and there were some easily fixable problems:
cd foo&& $(MAKE) -f makefile.win32&& cd ....
does not work, probably requires some sh. But if we depend on GNU make (which seems to be the case, since we're using ifdef/else/endif), it's easier and shorter to:
$(MAKE) -C foo -f makefile.win32
OK.
Linking does not work, because the stock make supports \ only for variables, not commands. But that's even easier to fix:
OK.
There is also some inconsistency: CP = copy, but "cp -r" and "cp" at the end of makefile. The install target can be rewritten as several -$(MD) and non-recursive $(CP) commands, and no MSYS will be required.
Sigh. Is there no equivalent of 'cp -r' on Windows?
RFC. If we consider this worthy, I can make the required changes.
Sounds good.
I have started working on this before: https://gist.github.com/1494603
It builds but isn't perfect, like it doesn't do the icon/resource stuff, and doesn't use win32-conf.h properly, but it might be useful for a starting point. It's what I use for testing Geany on Windows.
I did respond to this before (maybe with a laundry list of suggestions), but off the top of my head, the main ones for me are:
* it doesn't show the commands, so devs won't notice e.g if CFLAGS aren't correctly set * no support for building from MSYS
I haven't actually tested the makefile, but the idea of a single file is appealing, e.g. we can avoid duplication for GTK_CFLAGS, etc.
On 20/06/2012 19:04, Dimitar Zhekov wrote:
That looks like an entirely new makefile. I was able to compile Geany with small (msys compatible) changes in the existing makefiles, and setting MAKE to mingw32-make in localwin32.mk...
Yes, probably we should set MAKE=mingw32-make instead of 'make'.
On Fri, 22 Jun 2012 17:23:26 +0100 Nick Treleaven nick.treleaven@btinternet.com wrote:
$(MAKE) -C foo -f makefile.win32
OK.
Linking does not work, because the stock make supports \ only for variables, not commands. But that's even easier to fix: [...]
OK.
There is also some inconsistency: CP = copy, but "cp -r" and "cp" at the end of makefile. The install target can be rewritten as several -$(MD) and non-recursive $(CP) commands, and no MSYS will be required.
Sigh. Is there no equivalent of 'cp -r' on Windows?
XCOPY can be used. But since we only have the data/ directory with two subdirectories, a COPY is fine too.
RFC. If we consider this worthy, I can make the required changes.
Sounds good.
I'll probably make the changes in Monday.
On 20/06/2012 19:04, Dimitar Zhekov wrote:
That looks like an entirely new makefile. I was able to compile Geany with small (msys compatible) changes in the existing makefiles, and setting MAKE to mingw32-make in localwin32.mk...
Yes, probably we should set MAKE=mingw32-make instead of 'make'.
If we don't need MSYS, and there aren't any advantages in using it for compiling and installing Geany, mingw32-make should be the default.
On 12-06-22 09:23 AM, Nick Treleaven wrote:
On 19/06/2012 22:25, Matthew Brush wrote:
On 12-06-19 10:12 AM, Dimitar Zhekov wrote:
Hi,
Now that 1.22 is out, how about removing the MSYS build dependency under Win~1? I tried to compile Geany with the default MinGW make, without any MSYS, and there were some easily fixable problems:
cd foo&& $(MAKE) -f makefile.win32&& cd ....
does not work, probably requires some sh. But if we depend on GNU make (which seems to be the case, since we're using ifdef/else/endif), it's easier and shorter to:
$(MAKE) -C foo -f makefile.win32
OK.
Linking does not work, because the stock make supports \ only for variables, not commands. But that's even easier to fix:
OK.
There is also some inconsistency: CP = copy, but "cp -r" and "cp" at the end of makefile. The install target can be rewritten as several -$(MD) and non-recursive $(CP) commands, and no MSYS will be required.
Sigh. Is there no equivalent of 'cp -r' on Windows?
RFC. If we consider this worthy, I can make the required changes.
Sounds good.
I have started working on this before: https://gist.github.com/1494603
It builds but isn't perfect, like it doesn't do the icon/resource stuff, and doesn't use win32-conf.h properly, but it might be useful for a starting point. It's what I use for testing Geany on Windows.
I did respond to this before (maybe with a laundry list of suggestions), but off the top of my head, the main ones for me are:
- it doesn't show the commands, so devs won't notice e.g if CFLAGS
aren't correctly set
- no support for building from MSYS
I haven't actually tested the makefile, but the idea of a single file is appealing, e.g. we can avoid duplication for GTK_CFLAGS, etc.
I guess for those GTK_CFLAGS and friends, we could put them into a separate make file that gets included in the others, either in localvars thing or a separate common-win32.mk or something.
Also, on the topic of improving the win32 makefiles, we should make sure that all paths are quoted because IIRC last time I tried to use them, stuff like this[1] made it blow up when my PREFIX was (for example), `C:/Documents and Settings/...` (ie. spaces in the filename).
Cheers, Matthew Brush
[1] https://github.com/geany/geany/blob/master/src/makefile.win32#L23
On Fri, 22 Jun 2012 13:08:22 -0700 Matthew Brush mbrush@codebrainz.ca wrote:
Hi. Here is a small diff (for makefile.win32 and src/makefile.win32 only) that makes Geany 1.22 Win~1 compilation and installation independent of MSYS. Usage:
C> mingw32-make -f makefile.win32 C> mingw32-make -f makefile.win32 install
Tested with mingw, cmd/tcc. Should work with MSYS make too... but I had to use backslashes in the install: target, and am not sure if/how MSYS make escapes them. Win~1 fully supports forward slashes internally, but the command interpreters have only partial support.
Also, on the topic of improving the win32 makefiles, we should make sure that all paths are quoted because IIRC last time I tried to use them, stuff like this[1] made it blow up when my PREFIX was (for example), `C:/Documents and Settings/...` (ie. spaces in the filename).
All install: destination paths, yes. About the others - will anyone put gtk+ under "C:\Documents and Settings", or something like that?
The truth to be said, all paths should be quoted under all OS-es, but nobody does that unless a path with spaces is really likely.
On 12-06-25 12:33 PM, Dimitar Zhekov wrote:
On Fri, 22 Jun 2012 13:08:22 -0700 Matthew Brush mbrush@codebrainz.ca wrote:
Hi. Here is a small diff (for makefile.win32 and src/makefile.win32 only) that makes Geany 1.22 Win~1 compilation and installation independent of MSYS. Usage:
C> mingw32-make -f makefile.win32 C> mingw32-make -f makefile.win32 install
Tested with mingw, cmd/tcc. Should work with MSYS make too... but I had to use backslashes in the install: target, and am not sure if/how MSYS make escapes them. Win~1 fully supports forward slashes internally, but the command interpreters have only partial support.
Which command interpreters? AFAIK `cmd.exe` supports it fine, no?
Also, on the topic of improving the win32 makefiles, we should make sure that all paths are quoted because IIRC last time I tried to use them, stuff like this[1] made it blow up when my PREFIX was (for example), `C:/Documents and Settings/...` (ie. spaces in the filename).
All install: destination paths, yes. About the others - will anyone put gtk+ under "C:\Documents and Settings", or something like that?
IIRC mine was:
%HOMEPATH%/gtk = C:/Documents and Settings/Matthew Brush/gtk
But I could even imagine:
C:/Program Files/GTK
Or even:
G:/GTK Stuff
The truth to be said, all paths should be quoted under all OS-es, but nobody does that unless a path with spaces is really likely.
For anything on Windows, spaces in filenames is *really* likely :)
Out of curiosity/boredom I tried on Linux for Autotools to use
./configure --prefix=/tmp/Geany\ Stuff
And it almost went all the way though, except for I needed to add pair of unescaped quotes here: https://github.com/geany/geany/blob/master/plugins/Makefile.am#L106
And the final step of installing the geany binary failed with:
test -z "/tmp/Geany Stuff/bin" || /bin/mkdir -p "/tmp/Geany Stuff/bin" /bin/bash ../libtool --silent --mode=install /usr/bin/install -c geany '/tmp/Geany Stuff/bin' /usr/bin/install: target `Stuff/bin/geany' is not a directory make[2]: *** [install-binPROGRAMS] Error 1
Which seems strange since `/usr/bin/install -c geany '/tmp/Geany Stuff/bin'` on its own works just fine.
Anyway, that's the extent of how much I care about it, and I haven't used Windows in many months, so it doesn't really matter anyway to me. I just figured that it's not often we can fix bugs with 2 characters ("") so it might be worthwhile :)
Cheers, Matthew Brush
On Mon, 25 Jun 2012 13:52:12 -0700 Matthew Brush mbrush@codebrainz.ca wrote:
C> mingw32-make -f makefile.win32 C> mingw32-make -f makefile.win32 install
Tested with mingw, cmd/tcc. Should work with MSYS make too... but I had to use backslashes in the install: target, and am not sure if/how MSYS make escapes them. Win~1 fully supports forward slashes internally, but the command interpreters have only partial support.
Which command interpreters? AFAIK `cmd.exe` supports it fine, no?
Yes, cmd/tcc = cmd.exe or tcc.exe (the free take-command light).
For anything on Windows, spaces in filenames is *really* likely :)
Well, the purpuse of this patch is to phase out MSYS. We can quote the gtk+ path later...
MSYS does treat backslashes as escapes, and I think that is a worse problem than cmd.exe interpreting forward slashes as command options, as it can occur in more situations. I think we should use forward slashes throughout.
I expected something like that. OK, the "-b" version uses forward slashes only. It's stupid and less efficient - not that it matters on novadays machines. The command interpreters seem to tolerate forward slashes for an exact-match path.
Unfortunately I can't get your patch to apply against current Git, but I'm not sure why (see attached file for errors). Can you/someone test if it applies (maybe there's something weird happening on my Windows setup)?
The original patch had CR+LF line endings, the attached "-a" version uses LF. But we should try "-b" anyway.
--
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". :)
On 26/06/2012 20:06, Dimitar Zhekov wrote:
MSYS does treat backslashes as escapes, and I think that is a worse problem than cmd.exe interpreting forward slashes as command options, as it can occur in more situations. I think we should use forward slashes throughout.
I expected something like that. OK, the "-b" version uses forward slashes only. It's stupid and less efficient - not that it matters on novadays machines. The command interpreters seem to tolerate forward slashes for an exact-match path.
I don't understand why you made these changes with a separate target for each data subdirectory. This is not clean enough IMO.
BTW you missed data/templates/files. Wouldn't using a single xcopy be more sensible to reduce bugs and maintenance?
Unfortunately I can't get your patch to apply against current Git, but I'm not sure why (see attached file for errors). Can you/someone test if it applies (maybe there's something weird happening on my Windows setup)?
The original patch had CR+LF line endings, the attached "-a" version uses LF. But we should try "-b" anyway.
The problem turns out not to be line endings, that was just git warning noise. The problem was something else, still don't know why.
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? Wouldn't it be better to use 'git diff'?
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. ... Unlike most variables, the variable SHELL is never set from the environment. This is because the SHELL environment variable is used to specify your personal choice of shell program for interactive use. It would be very bad for personal choices like this to affect the functioning of makefiles."
from http://www.gnu.org/software/make/manual/html_node/Choosing-the-Shell.html#Ch...
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
On 26/06/2012 21:21, Nick Treleaven wrote:
MSYS does treat backslashes as escapes, and I think that is a worse problem than cmd.exe interpreting forward slashes as command options, as it can occur in more situations. I think we should use forward slashes throughout.
I expected something like that. OK, the "-b" version uses forward slashes only. It's stupid and less efficient - not that it matters on novadays machines. The command interpreters seem to tolerate forward slashes for an exact-match path.
I don't understand why you made these changes with a separate target for each data subdirectory. This is not clean enough IMO.
OK, I just got it:
copy src/* dest
The syntax of the command is incorrect.
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?
On 26/06/2012 21:31, Nick Treleaven wrote:
On 26/06/2012 21:21, Nick Treleaven wrote:
MSYS does treat backslashes as escapes, and I think that is a worse problem than cmd.exe interpreting forward slashes as command options, as it can occur in more situations. I think we should use forward slashes throughout.
I expected something like that. OK, the "-b" version uses forward slashes only. It's stupid and less efficient - not that it matters on novadays machines. The command interpreters seem to tolerate forward slashes for an exact-match path.
I don't understand why you made these changes with a separate target for each data subdirectory. This is not clean enough IMO.
OK, I just got it:
copy src/* dest
The syntax of the command is incorrect.
I still don't think separate targets is acceptable though. I can at least apply the rest of the patch though.
Now applied without the install changes; thanks for the patch.
BTW you missed data/templates/files. Wouldn't using a single xcopy be more sensible to reduce bugs and maintenance?
On 26/06/2012 21:46, Nick Treleaven wrote:
On 26/06/2012 21:31, Nick Treleaven wrote:
On 26/06/2012 21:21, Nick Treleaven wrote:
MSYS does treat backslashes as escapes, and I think that is a worse problem than cmd.exe interpreting forward slashes as command options, as it can occur in more situations. I think we should use forward slashes throughout.
I expected something like that. OK, the "-b" version uses forward slashes only. It's stupid and less efficient - not that it matters on novadays machines. The command interpreters seem to tolerate forward slashes for an exact-match path.
I don't understand why you made these changes with a separate target for each data subdirectory. This is not clean enough IMO.
OK, I just got it:
copy src/* dest
The syntax of the command is incorrect.
I still don't think separate targets is acceptable though. I can at least apply the rest of the patch though.
Now applied without the install changes; thanks for the patch.
BTW you missed data/templates/files. Wouldn't using a single xcopy be more sensible to reduce bugs and maintenance?
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"
I think because 'copy' takes /y switches the first path it sees must not use forward slashes. They are OK in the destination though.
Please test.
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.
On 27/06/2012 21:32, Dimitar Zhekov wrote:
On Tue, 26 Jun 2012 21:21:57 +0100 Nick Treleavennick.treleaven@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
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
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.
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
On Thu, 28 Jun 2012 16:28:50 +0200 Thomas Martitz thomas.martitz@student.htw-berlin.de 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.
On Thu, 28 Jun 2012 14:41:25 +0100 Nick Treleaven nick.treleaven@btinternet.com 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.
On 28/06/2012 18:55, Dimitar Zhekov wrote:
On Thu, 28 Jun 2012 14:41:25 +0100 Nick Treleavennick.treleaven@btinternet.com 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.
Well that removes DIRSEP, but adds MKDIR_P and adds defines to the plugins makefile.
BTW if you think plugins$(DIRSEP)*.dll looks ugly, we can use: plugins$/*.dll
This is what I intend to do.
BTW (not included in the .diff):
'CP = copy' in doc/Makefile.win32 should be 'copy /Y'.
OK, I'll fix it.
'MAKE =' seems unneeded, any GNU make defines is automatically.
I already made that change last week.
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.
Then the user would have to keep merging it with their local one if we change/add definitions.
In all cases, -include localwin32.mk should be the last, to allow overriding.
Yes.
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...
Yes, I realized after sending the email.
That means I will need to use 'ifdef MSYS' in any sub-makefiles that need it. This is the cleanest way to provide MSYS support. The user can even type MSYS=1 on the command-line quite easily.
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.
Did you read the link? I'm talking about a backslash as the last character on the line.
Nick
On Wed, 04 Jul 2012 12:59:11 +0100 Nick Treleaven nick.treleaven@btinternet.com wrote:
On 28/06/2012 18:55, Dimitar Zhekov wrote:
BTW if you think plugins$(DIRSEP)*.dll looks ugly, we can use: plugins$/*.dll
Nice. :) Though what I find a bit unpleasant is using the specific separator for a single install command, not the particular syntax.
This is what I intend to do.
Then why not put it for all install commands? We'll not depend on the (undocumented AFAIK) behaviour of win~1 mkdir/copy/del to treat slash as a directory separator in some cases, but not in others.
'MAKE =' seems unneeded, any GNU make defines is automatically.
Sorry. Missed that.
http://www.gnu.org/software/make/manual/html_node/Splitting-Lines.html
(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.
Did you read the link? I'm talking about a backslash as the last character on the line.
Yes. What I failed to read is:
http://www.gnu.org/software/make/manual/html_node/Wildcard-Pitfall.html#Wild...
which seems to be the only mention that \ can be used for directory separator. So I assumed that mingw32-make deviates from make.info, and that may apply to trailing backslashes too.
On 07/07/2012 13:16, Dimitar Zhekov wrote:
On Wed, 04 Jul 2012 12:59:11 +0100 Nick Treleavennick.treleaven@btinternet.com wrote:
On 28/06/2012 18:55, Dimitar Zhekov wrote:
BTW if you think plugins$(DIRSEP)*.dll looks ugly, we can use: plugins$/*.dll
Nice. :) Though what I find a bit unpleasant is using the specific separator for a single install command, not the particular syntax.
It may turn out to be needed elsewhere.
This is what I intend to do.
Then why not put it for all install commands? We'll not depend on the (undocumented AFAIK) behaviour of win~1 mkdir/copy/del to treat slash as a directory separator in some cases, but not in others.
OK.
BTW I've run into 2 problems with the install target:
1. cp -r and xcopy treat the destination path differently. Currently MSYS install is broken and will install data files as $DESTDIR/data/data/* - I've replaced xcopy with separate copy targets locally. Unfortunately that causes errors with subdirectories so I had to ignore them, which I'd prefer not to do. See attached diff.
2. A weird problem. Installing from cmd.exe doesn't overwrite geany.glade (and maybe some other files) even though it appears to succeed. I only noticed this because I'm missing the View->Editor->Color Schemes menu which was added about a month ago (I tend to test in place rather than install each time).
Regards, Nick
On Sun, 08 Jul 2012 13:04:54 +0100 Nick Treleaven nick.treleaven@btinternet.com wrote:
BTW I've run into 2 problems with the install target:
- cp -r and xcopy treat the destination path differently. Currently
MSYS install is broken and will install data files as $DESTDIR/data/data/* - I've replaced xcopy with separate copy targets locally. Unfortunately that causes errors with subdirectories so I had to ignore them, which I'd prefer not to do. See attached diff.
"cp: omitting directory 'foo'" errors on any subdirectories with GNU cp. Wait... the _only_ 'cp' we have under Win~1 GNU cp, right? Instead of the patch, we can define CP_R as 'cp -r --remove-destination'. This non-POSIX option exists since at least fileutils-4.1 from 2001. Well, it'll remove $(DESTDIR)/data before copying, which I would prefer not to do, but there shoudn't be any user files anyway.
- A weird problem. Installing from cmd.exe doesn't overwrite
geany.glade (and maybe some other files) even though it appears to succeed. I only noticed this because I'm missing the View->Editor->Color Schemes menu which was added about a month ago (I tend to test in place rather than install each time).
OMG... Then we must choose between copy and xcopy depending on which one works. Or we can define:
for cmd: 'CP_R = xcopy /s /y /i' and 'RM_R = del /s' for MSYS: 'CP_R = cp -r' and 'RM_R = rm -r'
and replace the '-$(MKDIR) "$(DESTDIR)/data"' with '-$(RM_R) "$(DESTDIR)/data"'.
That will (a) nullify the differences between 'cp -r' and 'xcopy /s', (b) be a bit shorter than the individual MKDIR/CP commands from the patch, and (c) fix the overriding problem, since the target files will not exist - or maybe reveal something about the reason why it fails.
Well, we haven't run out of options yet. I'll test the patch tomorrow.
On 09/07/2012 19:13, Dimitar Zhekov wrote:
On Sun, 08 Jul 2012 13:04:54 +0100 Nick Treleavennick.treleaven@btinternet.com wrote:
BTW I've run into 2 problems with the install target:
- cp -r and xcopy treat the destination path differently. Currently
MSYS install is broken and will install data files as $DESTDIR/data/data/* - I've replaced xcopy with separate copy targets locally. Unfortunately that causes errors with subdirectories so I had to ignore them, which I'd prefer not to do. See attached diff.
"cp: omitting directory 'foo'" errors on any subdirectories with GNU cp. Wait... the _only_ 'cp' we have under Win~1 GNU cp, right? Instead of the patch, we can define CP_R as 'cp -r --remove-destination'. This non-POSIX option exists since at least fileutils-4.1 from 2001. Well, it'll remove $(DESTDIR)/data before copying, which I would prefer not to do, but there shoudn't be any user files anyway.
No, the subdir errors are with windows 'copy'.
It's not good to remove *all* destination files, it is valid to add files to the system config directory, understanding that they may get overwritten on upgrade /if/ a file with the same name is installed. This allows users to share some of the same config files.
But this problem can be resolved either with separate copy commands as I attached previously, or maybe by having different install-data targets depending on whether MSYS is defined.
- A weird problem. Installing from cmd.exe doesn't overwrite
geany.glade (and maybe some other files) even though it appears to succeed. I only noticed this because I'm missing the View->Editor->Color Schemes menu which was added about a month ago (I tend to test in place rather than install each time).
OMG... Then we must choose between copy and xcopy depending on which one works. Or we can define:
Neither one works here ;-) But maybe it's something weird about my system or because I previously installed using MSYS cp.
for cmd: 'CP_R = xcopy /s /y /i' and 'RM_R = del /s'
xcopy /i doesn't seem to help here if the destination already exists (I don't think we should remove $DESTDIR).
for MSYS: 'CP_R = cp -r' and 'RM_R = rm -r'
and replace the '-$(MKDIR) "$(DESTDIR)/data"' with '-$(RM_R) "$(DESTDIR)/data"'.
That will (a) nullify the differences between 'cp -r' and 'xcopy /s', (b) be a bit shorter than the individual MKDIR/CP commands from the patch, and (c) fix the overriding problem, since the target files will not exist - or maybe reveal something about the reason why it fails.
Well, we haven't run out of options yet. I'll test the patch tomorrow.
On Tue, 10 Jul 2012 12:55:58 +0100 Nick Treleaven nick.treleaven@btinternet.com wrote:
I've replaced xcopy with separate copy targets locally. Unfortunately that causes errors with subdirectories so I had to ignore them, which I'd prefer not to do. See attached diff.
"cp: omitting directory 'foo'" errors on any subdirectories with GNU cp. [...]
No, the subdir errors are with windows 'copy'.
Strange. Under Linux:
$ md /tmp/gx $ cp doc/* /tmp/gx $ cp doc/* ~/gx || echo some error cp: omitting directory `doc/images' some error
But the patch ignores any copy errors anyway, so it woudn't matter.
for cmd: 'CP_R = xcopy /s /y /i' and 'RM_R = del /s'
xcopy /i doesn't seem to help here if the destination already exists (I don't think we should remove $DESTDIR).
Yes, it works only for non-existing target directory.
I tested the patch with cmd.exe and tcc.exe, install and re-install. All work fine, no copy error messages. On re-install, there are mkdir error messages about existing directories, geany.glade is replaced normally. That's with XP SP2 32-bit, MSYS was never installed.
On 10/07/2012 12:55, Nick Treleaven wrote:
- A weird problem. Installing from cmd.exe doesn't overwrite
geany.glade (and maybe some other files) even though it appears to succeed. I only noticed this because I'm missing the View->Editor->Color Schemes menu which was added about a month ago (I tend to test in place rather than install each time).
OMG... Then we must choose between copy and xcopy depending on which one works. Or we can define:
Neither one works here ;-) But maybe it's something weird about my system or because I previously installed using MSYS cp.
OK, I think I finally found out whats happening here (or at least a related problem). Perhaps it will help someone else with the same problem.
I was reluctant to delete the installed data files in case the problem was specific to them, but today I did, then reinstalled. The installed files all got the latest versions, but when I ran Geany the old data files were still being loaded (glade symbol errors, filetypes.common debug error message).
So, I did a search for geany.glade and discovered it in: c:\Users\Nick\AppData\Local\VirtualStore\Program Files\Geany\data
reading up on the VirtualStore path, I found it gets created when an application tries to write to a system path like Program Files, without the correct privileges. The application then silently receives the VirtualStore versions of files instead. I must have once tried to install geany without admin privileges, or manually copy over the data dir or something like that.
This behaviour is really confusing if you're not aware of it. I think there is a way to tell Windows not to use VirtualStore for an specific application though, I'll have to look into it. In the meantime I just deleted the Geany dir under VirtualStore, all is now working correctly.
On Tue, 11 Dec 2012 17:44:20 +0000 Nick Treleaven nick.treleaven@btinternet.com wrote:
On 10/07/2012 12:55, Nick Treleaven wrote:
- A weird problem. Installing from cmd.exe doesn't overwrite
geany.glade (and maybe some other files) even though it appears to succeed. [...]
So, I did a search for geany.glade and discovered it in: c:\Users\Nick\AppData\Local\VirtualStore\Program Files\Geany\data
reading up on the VirtualStore path, I found it gets created when an application tries to write to a system path like Program Files, without the correct privileges. The application then silently receives the VirtualStore versions of files instead. [...]
Now that's a... a system designed without security, attempting to provide "compatibility" with weird tricks.
What's the situation with geany.exe in this case - doesn't it create even more problems? The newest win~1 versions are very sinsitive about replacing executables.
On 11/12/2012 19:20, Dimitar Zhekov wrote:
On Tue, 11 Dec 2012 17:44:20 +0000 Nick Treleaven nick.treleaven@btinternet.com wrote:
On 10/07/2012 12:55, Nick Treleaven wrote:
- A weird problem. Installing from cmd.exe doesn't overwrite
geany.glade (and maybe some other files) even though it appears to succeed. [...]
So, I did a search for geany.glade and discovered it in: c:\Users\Nick\AppData\Local\VirtualStore\Program Files\Geany\data
reading up on the VirtualStore path, I found it gets created when an application tries to write to a system path like Program Files, without the correct privileges. The application then silently receives the VirtualStore versions of files instead. [...]
Now that's a... a system designed without security, attempting to provide "compatibility" with weird tricks.
What's the situation with geany.exe in this case - doesn't it create even more problems? The newest win~1 versions are very sinsitive about replacing executables.
To be honest I don't understand exactly when the VirtualStore path gets written to, but for Geany I think we probably want to just disable it altogether. I think this requires a 'manifest' XML file, referenced in the .rc file:
http://msdn.microsoft.com/en-us/library/bb756929.aspx
Yet another Windows build file with a version and metadata to update on release :-/
On 12-12-12 05:25 AM, Nick Treleaven wrote:
On 11/12/2012 19:20, Dimitar Zhekov wrote:
On Tue, 11 Dec 2012 17:44:20 +0000 Nick Treleaven nick.treleaven@btinternet.com wrote:
On 10/07/2012 12:55, Nick Treleaven wrote:
- A weird problem. Installing from cmd.exe doesn't overwrite
geany.glade (and maybe some other files) even though it appears to succeed. [...]
So, I did a search for geany.glade and discovered it in: c:\Users\Nick\AppData\Local\VirtualStore\Program Files\Geany\data
reading up on the VirtualStore path, I found it gets created when an application tries to write to a system path like Program Files, without the correct privileges. The application then silently receives the VirtualStore versions of files instead. [...]
Now that's a... a system designed without security, attempting to provide "compatibility" with weird tricks.
What's the situation with geany.exe in this case - doesn't it create even more problems? The newest win~1 versions are very sinsitive about replacing executables.
To be honest I don't understand exactly when the VirtualStore path gets written to, but for Geany I think we probably want to just disable it
IIUC it's whenever Geany writes out to files in %PROGRAM_FILES% et al. So if you open C:\Program Files\Geany\data\filetypes.foo, edit it, and save it, it'll go into that phony directory.
altogether. I think this requires a 'manifest' XML file, referenced in the .rc file:
http://msdn.microsoft.com/en-us/library/bb756929.aspx
Yet another Windows build file with a version and metadata to update on release :-/
I actually have a patch sitting on my Win7 laptop that adds an XML manifest file to the resource. I made it because it allows the native dialogs to look more "native" and less win95-ish by using the current Windows theme. If you want I can dig up that patch and commit it and then we can just add whatever else to it.
Cheers, Matthew Brush
On 12/12/2012 15:24, Matthew Brush wrote:
altogether. I think this requires a 'manifest' XML file, referenced in the .rc file:
http://msdn.microsoft.com/en-us/library/bb756929.aspx
Yet another Windows build file with a version and metadata to update on release :-/
I actually have a patch sitting on my Win7 laptop that adds an XML manifest file to the resource. I made it because it allows the native dialogs to look more "native" and less win95-ish by using the current Windows theme. If you want I can dig up that patch and commit it and then we can just add whatever else to it.
Yes please.
On 12-12-11 09:44 AM, Nick Treleaven wrote:
On 10/07/2012 12:55, Nick Treleaven wrote:
- A weird problem. Installing from cmd.exe doesn't overwrite
geany.glade (and maybe some other files) even though it appears to succeed. I only noticed this because I'm missing the View->Editor->Color Schemes menu which was added about a month ago (I tend to test in place rather than install each time).
OMG... Then we must choose between copy and xcopy depending on which one works. Or we can define:
Neither one works here ;-) But maybe it's something weird about my system or because I previously installed using MSYS cp.
OK, I think I finally found out whats happening here (or at least a related problem). Perhaps it will help someone else with the same problem.
I was reluctant to delete the installed data files in case the problem was specific to them, but today I did, then reinstalled. The installed files all got the latest versions, but when I ran Geany the old data files were still being loaded (glade symbol errors, filetypes.common debug error message).
So, I did a search for geany.glade and discovered it in: c:\Users\Nick\AppData\Local\VirtualStore\Program Files\Geany\data
reading up on the VirtualStore path, I found it gets created when an application tries to write to a system path like Program Files, without the correct privileges. The application then silently receives the VirtualStore versions of files instead. I must have once tried to install geany without admin privileges, or manually copy over the data dir or something like that.
This behaviour is really confusing if you're not aware of it. I think there is a way to tell Windows not to use VirtualStore for an specific application though, I'll have to look into it. In the meantime I just deleted the Geany dir under VirtualStore, all is now working correctly.
FYI, there was a related bug a while back about this: https://sourceforge.net/tracker/index.php?func=detail&aid=3566329&gr...
Cheers, Matthew Brush
On 11/12/2012 23:13, Matthew Brush wrote:
So, I did a search for geany.glade and discovered it in: c:\Users\Nick\AppData\Local\VirtualStore\Program Files\Geany\data
reading up on the VirtualStore path, I found it gets created when an application tries to write to a system path like Program Files, without the correct privileges. The application then silently receives the VirtualStore versions of files instead. I must have once tried to install geany without admin privileges, or manually copy over the data dir or something like that.
This behaviour is really confusing if you're not aware of it. I think there is a way to tell Windows not to use VirtualStore for an specific application though, I'll have to look into it. In the meantime I just deleted the Geany dir under VirtualStore, all is now working correctly.
FYI, there was a related bug a while back about this: https://sourceforge.net/tracker/index.php?func=detail&aid=3566329&gr...
OK, thanks for the info. Hopefully we can disable VirtualStore for Geany executables sometime.
On 08/07/2012 13:04, Nick Treleaven wrote:
BTW I've run into 2 problems with the install target:
- cp -r and xcopy treat the destination path differently. Currently
MSYS install is broken and will install data files as $DESTDIR/data/data/* - I've replaced xcopy with separate copy targets locally. Unfortunately that causes errors with subdirectories so I had to ignore them, which I'd prefer not to do. See attached diff.
Now fixed using ifdef MSYS.
On 25/06/2012 20:33, Dimitar Zhekov wrote:
Hi. Here is a small diff (for makefile.win32 and src/makefile.win32 only) that makes Geany 1.22 Win~1 compilation and installation independent of MSYS. Usage:
C> mingw32-make -f makefile.win32 C> mingw32-make -f makefile.win32 install
Tested with mingw, cmd/tcc. Should work with MSYS make too... but I had to use backslashes in the install: target, and am not sure if/how MSYS make escapes them. Win~1 fully supports forward slashes internally, but the command interpreters have only partial support.
MSYS does treat backslashes as escapes, and I think that is a worse problem than cmd.exe interpreting forward slashes as command options, as it can occur in more situations. I think we should use forward slashes throughout.
Unfortunately I can't get your patch to apply against current Git, but I'm not sure why (see attached file for errors). Can you/someone test if it applies (maybe there's something weird happening on my Windows setup)?
Le 26/06/2012 18:11, Nick Treleaven a écrit :
On 25/06/2012 20:33, Dimitar Zhekov wrote:
Hi. Here is a small diff (for makefile.win32 and src/makefile.win32 only) that makes Geany 1.22 Win~1 compilation and installation independent of MSYS. Usage:
C> mingw32-make -f makefile.win32 C> mingw32-make -f makefile.win32 install
Tested with mingw, cmd/tcc. Should work with MSYS make too... but I had to use backslashes in the install: target, and am not sure if/how MSYS make escapes them. Win~1 fully supports forward slashes internally, but the command interpreters have only partial support.
MSYS does treat backslashes as escapes, and I think that is a worse problem than cmd.exe interpreting forward slashes as command options, as it can occur in more situations. I think we should use forward slashes throughout.
Unfortunately I can't get your patch to apply against current Git, but I'm not sure why (see attached file for errors). Can you/someone test if it applies (maybe there's something weird happening on my Windows setup)?
It applies fine here. I join the diff from Git after I applied the patch in case it helps, maybe your `git apply` will like it better?
OT: Nick, could you now merge the tagmanager/ tree rearrangement?
Regards, Colomban
Le 26/06/2012 19:02, Colomban Wendling a écrit :
Le 26/06/2012 18:11, Nick Treleaven a écrit :
On 25/06/2012 20:33, Dimitar Zhekov wrote:
Hi. Here is a small diff (for makefile.win32 and src/makefile.win32 only) that makes Geany 1.22 Win~1 compilation and installation independent of MSYS. Usage:
C> mingw32-make -f makefile.win32 C> mingw32-make -f makefile.win32 install
Tested with mingw, cmd/tcc. Should work with MSYS make too... but I had to use backslashes in the install: target, and am not sure if/how MSYS make escapes them. Win~1 fully supports forward slashes internally, but the command interpreters have only partial support.
MSYS does treat backslashes as escapes, and I think that is a worse problem than cmd.exe interpreting forward slashes as command options, as it can occur in more situations. I think we should use forward slashes throughout.
Unfortunately I can't get your patch to apply against current Git, but I'm not sure why (see attached file for errors). Can you/someone test if it applies (maybe there's something weird happening on my Windows setup)?
It applies fine here. I join the diff from Git after I applied the patch in case it helps, maybe your `git apply` will like it better?
... and here's the attachment.
OT: Nick, could you now merge the tagmanager/ tree rearrangement?
Regards, Colomban _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On 26/06/2012 18:02, Colomban Wendling wrote:
Unfortunately I can't get your patch to apply against current Git, but I'm not sure why (see attached file for errors). Can you/someone test if it applies (maybe there's something weird happening on my Windows setup)?
It applies fine here. I join the diff from Git after I applied the patch in case it helps, maybe your `git apply` will like it better?
Thanks. Unfortunately that didn't work either.
OT: Nick, could you now merge the tagmanager/ tree rearrangement?
Will do soon.