[Geany-devel] Remove MSYS dependency of Geany on Win~1
Dimitar Zhekov
dimitar.zhekov at xxxxx
Wed Jun 27 20:32:47 UTC 2012
On Tue, 26 Jun 2012 21:21:57 +0100
Nick Treleaven <nick.treleaven at 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.
--
E-gards: Jimmy
More information about the Devel
mailing list