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

[Dimitar Zhekov]

On Thu, 28 Jun 2012 14:41:25 +0100
Nick Treleaven <nick.treleaven at 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.

-- 
E-gards: Jimmy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: no-MSYS-2012-06-28.diff
Type: text/x-diff
Size: 1923 bytes
Desc: not available
URL: <http://lists.geany.org/pipermail/devel/attachments/20120628/eada6f99/attachment.diff>